Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test document.write() on image and text documents #10209

Merged
merged 4 commits into from May 14, 2018

Conversation

Projects
None yet
5 participants
@annevk
Copy link
Member

annevk commented Mar 28, 2018

@wpt-pr-bot wpt-pr-bot added the html label Mar 28, 2018

@wpt-pr-bot wpt-pr-bot requested review from ayg, jdm, jgraham and zqzhang Mar 28, 2018

@w3c-bots

This comment has been minimized.

Copy link

w3c-bots commented Mar 28, 2018

Build PASSED

Started: 2018-03-28 11:08:20
Finished: 2018-03-28 11:18:29

View more information about this build on:

@bzbarsky

This comment has been minimized.

Copy link
Contributor

bzbarsky commented Mar 28, 2018

@annevk You should call document.close() on those documents you open. Otherwise the page never fires its load event, because it has still-loading iframes.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Mar 28, 2018

I see, I wonder why it does pass in Chrome and Safari.

@bzbarsky

This comment has been minimized.

Copy link
Contributor

bzbarsky commented Mar 28, 2018

Because they don't treat opened-but-not-closed documents as "still loading". Which arguably is a spec violation.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Mar 28, 2018

Hmm, but since I do write() during the load event, why should the parent document wait for the subsequent load as well? Isn't the load event only delayed by the first load?

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Mar 28, 2018

HTML does have this note:

If, during the handling of the load event, the browsing context in the iframe is again navigated, that will further delay the load event.

But the "document open steps" also say nothing of them delaying the load event, so dunno. I'd say this is undefined or a bug in Firefox...

@bzbarsky

This comment has been minimized.

Copy link
Contributor

bzbarsky commented Mar 28, 2018

Isn't the load event only delayed by the first load?

The load event for the parent is delayed by any activity in the child, I would think.

But the "document open steps" also say nothing of them delaying the load event

They do say to set the document readiness to "loading". It's a bit weird to have that and not be considered as blocking onload.

It's not super-clear to me whether close() fires load or not; I bet browsers differ....

More generally, this is a symptom of Firefox treating open() as "more like navigation" and Safari/Chrome treating it more as "mess with this existing thing" and the spec not having any idea what it wants to treat it as.

annevk added some commits May 3, 2018

@annevk annevk requested a review from bzbarsky May 3, 2018

@annevk annevk requested a review from foolip May 14, 2018

@foolip

foolip approved these changes May 14, 2018

Copy link
Contributor

foolip left a comment

LGTM % link nit

assert_equals(frame.contentDocument.body.firstChild.textContent, "Heya");
assert_equals(frame.contentDocument.contentType, val[1]);

// Make sure a load event is fired across browsers

This comment has been minimized.

Copy link
@foolip

foolip May 14, 2018

Contributor

Can you link to either spec or browser bugs here?

// Make sure a load event is fired across browsers
frame.contentDocument.close();
});
}, "document.write(): " + val[1] + " document");

This comment has been minimized.

Copy link
@foolip

foolip May 14, 2018

Contributor

For the video, this will result in a different test name on different browsers. It'd be extra work to not have that be the case, so leaving it alone until we figure out a "rule" and how to enforce it seems right.

@annevk annevk merged commit 1fdae86 into master May 14, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@annevk annevk deleted the annevk/document-write branch May 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.