Don't miss out Virtual Happy Hour this Friday (April 26).
Try our conversational search powered by Generative AI!
AI OnAI Off
XForms editor doesn't work in IE10
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?
Edited,
Aug 13, 2013 13:48
Nay, but I will post a ticket now and see what'll happen. Will keep this thread updated.
Aug 13, 2013 14:07
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.
Aug 13, 2013 14:43
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?
Jan 14, 2014 16:41
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?
Jan 14, 2014 16:44
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.
Jan 14, 2014 17:01
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.
Jan 15, 2014 9:18
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:
http://www.somedomain.com/(F(dfasdfl3asderwa))/cmsi/cms/edit
Jan 15, 2014 11:07
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 [9] System.Web.UI.Control.InitRecursive - 1.1.3 Page initialized
2014-01-15 11:15:13,984 DEBUG [9] EPiServer.Web.PageExtensions.AntiForgeryValidation.AddHiddenField - Adding hidden anti-forgery field to response
2014-01-15 11:15:14,484 DEBUG [8] EPiServer.Web.PageExtensions.AntiForgeryValidation.PreInit - User already has anti-forgery cookie set
2014-01-15 11:15:14,484 INFO [8] System.Web.UI.Control.InitRecursive - 1.1.3 Page initialized
...
2014-01-15 11:15:14,530 DEBUG [14] EPiServer.Web.PageExtensions.AntiForgeryValidation.AddHiddenField - Adding hidden anti-forgery field to response
2014-01-15 11:15:14,562 DEBUG [30] EPiServer.Web.UrlRewriteModuleBase.BeginRequestEventHandler - Starting request with Url http://somedomain/cmsui/cms/edit/
2014-01-15 11:15:14,562 DEBUG [30] 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 [30] EPiServer.Web.UrlRewriteModuleBase.BeginRequestEventHandler - Exiting with no rewrite, Url is http://somedomain/cmsui/cms/edit/
2014-01-15 11:15:14,562 DEBUG [30] EPiServer.Web.PageExtensions.AntiForgeryValidation.PageSetup - Attaching anti-forgery to request
2014-01-15 11:15:14,562 DEBUG [30] EPiServer.Web.PageExtensions.AntiForgeryValidation.PreInit - User already has anti-forgery cookie set
2014-01-15 11:15:14,562 INFO [30] EPiServer.UI.Edit.DefaultPage.OnInit - 1.1.3 Page initialized
Jan 15, 2014 11:18
Added:
<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.
Jan 15, 2014 11:30
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.
Jan 15, 2014 12:41
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.
Jan 15, 2014 13:03
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
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.