I have reached the same conclusion. "Multiple option form elements" property area is blank below the heading. Changing to some Standards modes solves it.
Did you contact support?
Nay, but I will post a ticket now and see what'll happen. Will keep this thread updated.
A bug has been created by Shahid Nawaz from EPiServer. Keep watching the Bug List (http://world.episerver.com/Support/Bug-list-beta/) for bug #104317 - I'm guessing it should appear within a few days if it's accepted or whatever.
Can't find it in the buglist.
Hey guys, we are in the process of fixing some issues with EPiServer CMS 6R2 when using IE10 or IE11. Bug #104317 is on our list, however I've not been able to reproduce it. I'm able to create all XForm elements in both IE10 and IE11 without issue.
Are any of you able to provide me with some reproduction steps?
Nothing apart from what's in the bug report, I guess. If I remember correctly, it's all about the Radio buttons and dropdown lists. You can add the elements themselves, but not any options.
You can do that perfectly fine in IE10?
Unfortunetly there is very little information in the bug report. I can add, remove, and reorder options for both the dropdown, checkbox, and radio elements perfectly fine in both IE10 and IE11.
The only thing that I can think of that would affect this would be if the development tools are open and a custom browser mode or document mode are selected. In which case most of edit mode probably wouldn't work I imagine sicne it is very dependent on the mode set in the X-UA-Compatible metadata.
Let me know if you think of anything.
I asked our client to hit F12 in his IE 10 and report the document+standards mode when he has the error:
Document Mode: IE7-standarder
Browser Mode: IE10
I'm confident he didn't know how to to open dev tools before this.
Come to think of it now; document+standards mode can be dependent upon if the site get's added to IE's Intranet Sites, this could be something to investigate as well.
A conflicting X-UA-Compatible HTTP header could be sent "globally" for all requests from web.config, I checked that this was not the case for this site.
We have a customer who experience problems with IE 11 when login into edit mode. When the page occurs no css works and the page is refreshing all the time. On top in the adress field there are a lot of letters and numbers after uri and then the path to edit mode like this:
I guess the error is related to X-UA-Compatible HTTP header problem that Johan referes to in the previous post, but log4net has gone into a loop:
2014-01-15 11:15:13,984 INFO  System.Web.UI.Control.InitRecursive - 1.1.3 Page initialized
2014-01-15 11:15:13,984 DEBUG  EPiServer.Web.PageExtensions.AntiForgeryValidation.AddHiddenField - Adding hidden anti-forgery field to response
2014-01-15 11:15:14,484 DEBUG  EPiServer.Web.PageExtensions.AntiForgeryValidation.PreInit - User already has anti-forgery cookie set
2014-01-15 11:15:14,484 INFO  System.Web.UI.Control.InitRecursive - 1.1.3 Page initialized
2014-01-15 11:15:14,530 DEBUG  EPiServer.Web.PageExtensions.AntiForgeryValidation.AddHiddenField - Adding hidden anti-forgery field to response
2014-01-15 11:15:14,562 DEBUG  EPiServer.Web.UrlRewriteModuleBase.BeginRequestEventHandler - Starting request with Url http://somedomain/cmsui/cms/edit/
2014-01-15 11:15:14,562 DEBUG  EPiServer.Web.UrlRewriteModule.HttpUrlRewriteToInternal - Url is not valid for rewrite. Returning URL http://somedomain/cmsui/cms/edit/
2014-01-15 11:15:14,562 DEBUG  EPiServer.Web.UrlRewriteModuleBase.BeginRequestEventHandler - Exiting with no rewrite, Url is http://somedomain/cmsui/cms/edit/
2014-01-15 11:15:14,562 DEBUG  EPiServer.Web.PageExtensions.AntiForgeryValidation.PageSetup - Attaching anti-forgery to request
2014-01-15 11:15:14,562 DEBUG  EPiServer.Web.PageExtensions.AntiForgeryValidation.PreInit - User already has anti-forgery cookie set
2014-01-15 11:15:14,562 INFO  EPiServer.UI.Edit.DefaultPage.OnInit - 1.1.3 Page initialized
<configuration> <system.webServer> <httpProtocol> <customHeaders> <add name="X-UA-Compatible" value="IE=EmulateIE7" /> </customHeaders> </httpProtocol> </system.webServer> </configuration>
but there was no change in edit mode in IE11 for the customer.
Hm, when testing now, I am actually not able to reproduce it. I've asked the customer experiencing this if they are able to reproduce it still. Tested in a few other environments too, and all seems fine there.
So it might have been some weird issues with that speciifc solution. I'll post here as soon as I hear anything.
Could be something specific to the solution. I'm also wondering if it was IE that was causing the issue and that it is fixed with the latest IE update.
Check http://support.microsoft.com/kb/2836939/en-us for the IE11 issue.
Updating windows help our customer!
Creating new XForms in IE10 in CMS6 R2 desn't seem like it's working at all. There are certain combinations of document mode+browser mode that makes it work, but that's not really a viable solution.
Anyone seen solutions to this, or might there even come a hotfix from EPiServer on this? There are still a bunch of solutions out there running CMS6 - and many will probably be running for some more years. IE10 might not be officially supported by CMS 6, the editors out there really do not care. They just experience a buggy product.