Closed
Bug 539896
Opened 15 years ago
Closed 14 years ago
[HTML5][Patch] layout/base/test/chrome/test_bug533845.xul fails
Categories
(Core :: DOM: HTML Parser, defect, P1)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
People
(Reporter: hsivonen, Assigned: hsivonen)
References
Details
Attachments
(1 file)
1.11 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•14 years ago
|
||
No data so far about this being a Web compat issue, so I'm going for a test case change.
Assignee | ||
Comment 2•14 years ago
|
||
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
Comment 3•14 years ago
|
||
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.
Assignee | ||
Comment 4•14 years ago
|
||
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.
Assignee | ||
Comment 5•14 years ago
|
||
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.
Assignee | ||
Comment 6•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 years ago
|
||
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.
Assignee | ||
Comment 8•14 years ago
|
||
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
Assignee | ||
Comment 9•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Summary: [HTML5] layout/base/test/chrome/test_bug533845.xul fails → [HTML5] Event dispatch: layout/base/test/chrome/test_bug533845.xul fails
Assignee | ||
Comment 10•14 years ago
|
||
This turned out to be a typo in the data: URL.
Assignee | ||
Updated•14 years ago
|
Summary: [HTML5] Event dispatch: layout/base/test/chrome/test_bug533845.xul fails → [HTML5][Patch] layout/base/test/chrome/test_bug533845.xul fails
Comment 11•14 years ago
|
||
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+
Assignee | ||
Comment 12•14 years ago
|
||
Thanks. Landed: http://hg.mozilla.org/mozilla-central/rev/53ad4c696951
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•