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

RESOLVED FIXED

Status

()

P1
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: hsivonen, Assigned: hsivonen)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
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)

Updated

9 years ago
See Also: → bug 533381
(Assignee)

Comment 1

9 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

9 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
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

9 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 6

9 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

9 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

9 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

9 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

9 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

9 years ago
Created attachment 424962 [details] [diff] [review]
Add a missing single quote

This turned out to be a typo in the data: URL.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Attachment #424962 - Flags: review?(Olli.Pettay)
(Assignee)

Updated

9 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 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

9 years ago
Thanks. Landed:
http://hg.mozilla.org/mozilla-central/rev/53ad4c696951
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.