Ubiquity XForms doesn't load correctly in Internet Explorer 8 standards mode

[GoogleCodeExporter]

I've noticed, when running the W3C acceptance test suite in IE, that certain 
forms simply don't load correctly in XHTML mode. The same forms are fine in 
Firefox and Safari. One example of this is in test case 4.3.6.a, but there 
are plenty of others. I'll add details of more as I notice them.

Original issue reported on code.google.com by phil.boo...@gtempaccount.com on 21 Oct 2009 at 9:34

[GoogleCodeExporter]

I noticed a few more examples of this:

4.3.6.a; 4.4.2.a; 4.4.14.a.

Original comment by phil.boo...@gtempaccount.com on 21 Oct 2009 at 4:19

[GoogleCodeExporter]

On the mailing list, Fraser Hore reports that this is a problem with all forms 
that 
he's tried. I've also now witnessed it in HTML-mode forms, so I'm removing the 
XHTML 
specificity from the issue title.

Original comment by phil.boo...@gtempaccount.com on 23 Oct 2009 at 2:42

• Changed title: Some forms don't load correctly in Internet Explorer

[GoogleCodeExporter]

Also bumping up the priority. This seems like a pretty enormous showstopper for 
0.8 
(imho).

Original comment by phil.boo...@gtempaccount.com on 23 Oct 2009 at 2:43

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Additional forms that demonstrate this problem are the W3C test cases 10.5.a 
and 10.6.a 
and the regression tests for issues 229 and 284.

Original comment by phil.boo...@gtempaccount.com on 23 Oct 2009 at 2:44

[GoogleCodeExporter]

Original comment by phil.boo...@gtempaccount.com on 26 Oct 2009 at 8:49

• Changed state: Started
• Added labels: Iteration-20091023

[GoogleCodeExporter]

Well this is damned weird. I did a bit of experimenting with a couple of forms 
that 
were failing, trying out things that were different between them and forms that 
work 
correctly. What I've noticed is that, if the failing form contained either an 
XML 
processing instruction or an HTML doctype declaration as the first element, 
inserting 
an HTML comment at the start of the document 'fixes' the problem.

Original comment by phil.boo...@gtempaccount.com on 26 Oct 2009 at 10:46

[GoogleCodeExporter]

My observation from the preceding comment holds true for all forms mentioned in 
this 
issue.

Original comment by phil.boo...@gtempaccount.com on 26 Oct 2009 at 10:54

[GoogleCodeExporter]

Equally, removing the processing instruction and/or doctype declaration can 
also be 
seen to 'fix' the issue. I'm wondering if this might be a known Internet 
Explorer bug 
at all...

Original comment by phil.boo...@gtempaccount.com on 26 Oct 2009 at 10:59

[GoogleCodeExporter]

So I've done some reading around and, apparently, inserting an HTML comment 
before the 
doctype declaration has the effect of putting IE into quirks mode. I am 
therefore 
wondering if this problem is actually that Ubiquity XForms only loads in IE if 
it is in 
quirks mode, not if it is in standards mode. That would certainly fit with the 
observations so far.

Original comment by phil.boo...@gtempaccount.com on 26 Oct 2009 at 11:15

[GoogleCodeExporter]

Okay, after some trial-and-error debugging, I've discovered that, in the 
failing 
scenarios (standards mode), DECORATOR.onAllBindingsAttached() does not get 
entered. 
This means that none of the documentready handlers get called, which would 
clearly 
explain the symptoms described in this bug. DECORATOR.onAllBindingsAttached() 
is itself 
called from src/behaviours/onload.css, so my hypothesis is that this CSS file, 
especially the `behavior` rule, is only working in quirks mode in IE.

Original comment by phil.boo...@gtempaccount.com on 27 Oct 2009 at 10:31

[GoogleCodeExporter]

Okay, so one part of this problem is that IE8 in standards mode does not 
support CSS 
expressions [1].

I have applied a local fix to the two cases where we had been using 
behavior:expression(), replacing them with -ms-behavior:url() and creating 
equivalent 
HTC files to execute the expression. However, this doesn't fix the bug, 
although in 
both cases it does mean code that wasn't being executed now is.

I'm continuing to investigate other things that might be up.

[1] http://blogs.msdn.com/ie/archive/2008/10/16/ending-expressions.aspx

Original comment by phil.boo...@gtempaccount.com on 27 Oct 2009 at 11:45

[GoogleCodeExporter]

Updating the issue title as I am now more certain of the precise cause, and it 
also 
suggests to sufferers the workaround.

Original comment by phil.boo...@gtempaccount.com on 27 Oct 2009 at 11:48

• Changed title: Ubiquity XForms doesn't load correctly in Internet Explorer 8 standards mode

[GoogleCodeExporter]

This issue is going on to the back-burner temporarily. See r3123 for backed-up 
investigations.

Original comment by phil.boo...@gtempaccount.com on 27 Oct 2009 at 2:36

• Changed state: Accepted
• Removed labels: Iteration-20091023

[GoogleCodeExporter]

Having seen the recent discussion pop up around issue 601, I'm just adding a 
note 
here to remind myself to investigate whether DOM-walking decoration works in 
IE8 
standards mode, or does it suffer from whatever the same problems are that 
cause the 
HTC loading to fail.

Original comment by phil.boo...@gtempaccount.com on 28 Oct 2009 at 4:44

[GoogleCodeExporter]

The DOM-walking approach mentioned above doesn't make any difference.

Original comment by phil.boo...@gtempaccount.com on 6 Nov 2009 at 1:30

[GoogleCodeExporter]

Using the in-progress changes from r3123, I've noticed that the loop in 
callDocumentReadyHandlers (decorate.js, line 175ish) only iterates once, 
compared to 
many times in quirks mode. So it looks like g_arrHandlersToCallOnLoad may not 
be 
getting populated correctly.

Original comment by phil.boo...@gtempaccount.com on 6 Nov 2009 at 4:07

[GoogleCodeExporter]

Another work around for this issue is to force IE8 to emulate IE7 standards 
mode, by 
inserting the following tag before any other elements in the document's head, 
except 
for <title> and other <meta> elements:

    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

This will still use standards mode, so the CSS box model won't be completely 
ruined, 
but crucially it will emulate the standards mode of IE7, which doesn't suffer 
from 
whatever it is that causes this issue.

Original comment by phil.boo...@gtempaccount.com on 9 Nov 2009 at 4:19

[GoogleCodeExporter]

I finally found a detailed post about exactly what has changed in IE8, which I 
hope to 
use to finally sort this issue out properly:

http://blogs.msdn.com/ie/archive/2009/03/12/site-compatibility-and-ie8.aspx

Original comment by phil.boo...@gtempaccount.com on 9 Nov 2009 at 5:55

[GoogleCodeExporter]

After running through and making changes based on the link in the preceding 
comment, 
I am still suffering problems, although I believe some progress has been made 
in the 
changes (certainly some things that were wrong are no longer). I've not 
committed the 
changes to a branch in svn yet, but may do if I don't get further soon.

Anyway, with these changes, it seems that the key problem is that decoration is 
only 
occurring for the instance element in my test form, not for any of the form 
controls. 
This is despite all of the CSS rules apparently being added to ensure that 
decoration 
is invoked for everything.

Original comment by phil.boo...@gtempaccount.com on 11 Nov 2009 at 4:19

[GoogleCodeExporter]

Finally, I've managed to fix this issue locally.

The missing piece of the jigsaw, apart from the other changes discussed in 
earlier 
comments, was ensuring that the call to decorate() is spawned, otherwise only 
the first 
XForms element in the form was being decorated.

A fix should appear in the trunk some time in the next couple of weeks.

Original comment by phil.boo...@gtempaccount.com on 12 Nov 2009 at 3:55

[GoogleCodeExporter]

Original comment by phil.boo...@gtempaccount.com on 16 Nov 2009 at 12:33

• Changed state: Started
• Added labels: Iteration-20091113

[GoogleCodeExporter]

There is a fix awaiting review at r3168.

Original comment by phil.boo...@gtempaccount.com on 16 Nov 2009 at 2:52

• Changed state: InReview

[GoogleCodeExporter]

Fixed at r3174.

Original comment by phil.boo...@gtempaccount.com on 17 Nov 2009 at 1:46

• Changed state: Fixed