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 whether javascript: navigation aborts fetches in earlier navigation #9501

Merged
merged 2 commits into from Feb 19, 2018

Conversation

Projects
None yet
5 participants
@zcorpan
Copy link
Contributor

zcorpan commented Feb 13, 2018

See whatwg/html#2590. Tentative tests for now.

@zcorpan zcorpan requested review from bzbarsky and annevk Feb 13, 2018

@wpt-pr-bot wpt-pr-bot added the html label Feb 13, 2018

@wpt-pr-bot wpt-pr-bot requested review from jdm, jgraham and zqzhang Feb 13, 2018

@w3c-bots

This comment has been minimized.

Copy link

w3c-bots commented Feb 13, 2018

Build PASSED

Started: 2018-02-19 15:42:49
Finished: 2018-02-19 15:47:34

View more information about this build on:

@zcorpan

This comment has been minimized.

Copy link
Contributor Author

zcorpan commented Feb 13, 2018

Test result analysis for Firefox/Chrome/Safari/Edge. (Edit: have now also tested Edge.)

The javascript:undefined case appears interoperable. The previous ongoing fetch/navigation is not aborted. So the spec needs to be fixed here.

I see different behavior for the javascript:string case:

  • Firefox and Edge abort the slow fetch when the javascript:string navigation happens.
  • Chrome ignores (?) the target attribute for the javascript:string link, so that navigation replaces the link's document (this is why iframe-and-links.html is in an iframe, otherwise it wipes out the testharness.js and the test wouldn't complete). This seems like a bug in Chrome.
  • Safari does not abort the slow fetch when the javascript:string navigation happens. Or at least it ends up with set-child-loaded.html in the nested iframe.

Bugs about ignoring target:
https://bugs.webkit.org/show_bug.cgi?id=13543
https://bugs.chromium.org/p/chromium/issues/detail?id=749492

<!doctype html>

<iframe name="iframe"></iframe>
<a target="iframe" href="set-child-loaded.html?pipe=trickle(d1)" id="slowLink">slow link</a>

This comment has been minimized.

Copy link
@annevk

annevk Feb 19, 2018

Member

Maybe add a comment what trickle(d1) does?

child.document.querySelector("#slowLink").click();
// The step below is in a timeout. The framed page can't communicate back mid-parse because that
// would involve running script, which makes that navigation "mature", and we need to do this
// before it matures.

This comment has been minimized.

Copy link
@annevk

annevk Feb 19, 2018

Member

Isn't it already mature though if it has a tree you have access to?

This comment has been minimized.

Copy link
@zcorpan

zcorpan Feb 19, 2018

Author Contributor

iframe-and-links.html is fully loaded, but the further nested iframe should be loading and not mature when the next link is followed.

This comment has been minimized.

Copy link
@annevk

annevk Feb 19, 2018

Member

Ah right, because the first load takes longer than 100ms. Okay, this setup seems reasonable then.

This comment has been minimized.

Copy link
@bzbarsky

bzbarsky Feb 21, 2018

Contributor

@zcorpan @annevk What guarantees that this timeout will fire before the navigation matures? The 1s timer on the trickle is in a different process (the server). Depending on OS scheduling, it can in fact end up replying before this timer fires.

This comment has been minimized.

Copy link
@annevk

annevk Feb 21, 2018

Member

I think we rely on that assumption in a lot of tests. If we cannot rely on that, we basically cannot write these kind of tests...

This comment has been minimized.

Copy link
@bzbarsky

bzbarsky Feb 21, 2018

Contributor

Sure you could. For example, you could kick off two separate loads, to one of which the server responds after 100ms and to one of which it responds after 1000ms, and do your stuff when the 100ms load comes in.... That would ensure that you're using a single clock to time things.

Anyway, as written this test will randomly fail in testing infrastructure.

@annevk

annevk approved these changes Feb 19, 2018

@zcorpan zcorpan merged commit be7c5e5 into master Feb 19, 2018

1 check passed

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

@zcorpan zcorpan deleted the zcorpan/whatwg-html-issue-2590 branch Feb 19, 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.