539896 - [HTML5][Patch] layout/base/test/chrome/test_bug533845.xul fails

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P1)

Description

[Henri Sivonen (:hsivonen)]

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.

Comment 1

[Henri Sivonen (:hsivonen)]

No data so far about this being a Web compat issue, so I'm going for a test case change.

Comment 2

[Henri Sivonen (:hsivonen)]

Most likely I misdiagnosed this.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 4

[Henri Sivonen (:hsivonen)]

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.

Comment 5

[Henri Sivonen (:hsivonen)]

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.

Comment 6

[Henri Sivonen (:hsivonen)]

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.

Comment 7

[Henri Sivonen (:hsivonen)]

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.

Comment 8

[Henri Sivonen (:hsivonen)]

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.

Comment 9

[Henri Sivonen (:hsivonen)]

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.

Comment 10

[Henri Sivonen (:hsivonen)]

Attachment: Add a missing single quote

This turned out to be a typo in the data: URL.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 424962 [details] [diff] [review]
Add a missing single quote

But eventually we'll need parser tests for this kinds of things.

Comment 12

[Henri Sivonen (:hsivonen)]

Thanks. Landed:
http://hg.mozilla.org/mozilla-central/rev/53ad4c696951