Closed Bug 539896 Opened 10 years ago Closed 10 years ago
_bug533845 .xul fails
layout/base/tests/chrome/test_bug533845.xul fails. It appears the test case assumes data: URLs that don't block the parser to parse as a single event loop task.
No data so far about this being a Web compat issue, so I'm going for a test case change.
Most likely I misdiagnosed this.
Summary: [HTML5] data: URLs not parsed as one event queue task → [HTML5] layout/base/tests/chrome/test_bug533845.xul fails
Does html5 parser not block onload in the parent document when data: is parsed for an iframe? (That would be a bug.) Or what the problem could be.
It doesn't block onload on the parent explicitly. I thought nsDocument mechanisms too care of that automatically when blocking onload on the document itself. I'll check if that's the problem.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/358 suggests the load event of the parent waits. However, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/359 looks really suspicious as does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/360.
OK, so the cases I posted as suspicious aren't consistently so. What I saw was behavior that looked like the load event of the parent doc firing twice. Once too early and another time at the right point.
It's plausible that it's an oddity of how the Live DOM Viewer works. So that the bad onload is actually the onload a previous doc that got blown away immediately by another keystroke.
This looks very similar to bug 541050. When debugging that bug, I put a dump() call into the onpagehide attribute of the iframed document, and it didn't fire with the HTML5 parser. Now debugging this bug, I put a dump() in the onload attribute on body in the iframed document. It dumps with the old parser but not with the HTML5 parser. Yet, the experiments above with Hixie's Live DOM Viewer show that onload does fire in iframes in those cases.
Summary: [HTML5] layout/base/tests/chrome/test_bug533845.xul fails → [HTML5] layout/base/test/chrome/test_bug533845.xul fails
Just like debugging bug 541050 shows that the pagehide event firing process starts, debugging this one shows that the load group does get unblocked. I wonder if the HTML5 parser does something that makes a security check fail somewhere along the way when 'pagehide' (in bug 541050) or 'load' (here) is being fired on the iframed document. Something that fails in the test harness but not on Hixie Live DOM Viewer due to them having some difference in the security nature of the iframe boundary maybe? And whole lot of stuff happens when firing those events, so I'm not sure where exactly I should be looking to see why the event handlers aren't reached.
Summary: [HTML5] layout/base/test/chrome/test_bug533845.xul fails → [HTML5] Event dispatch: layout/base/test/chrome/test_bug533845.xul fails
This turned out to be a typo in the data: URL.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Attachment #424962 - Flags: review?(Olli.Pettay)
Summary: [HTML5] Event dispatch: layout/base/test/chrome/test_bug533845.xul fails → [HTML5][Patch] layout/base/test/chrome/test_bug533845.xul fails
Comment on attachment 424962 [details] [diff] [review] Add a missing single quote But eventually we'll need parser tests for this kinds of things.
Attachment #424962 - Flags: review?(Olli.Pettay) → review+
Thanks. Landed: http://hg.mozilla.org/mozilla-central/rev/53ad4c696951
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.