Intent to implement and ship: disallow navigations in the unload handler

瀏覽次數:413 次
跳到第一則未讀訊息

Lucas Gadani

未讀,
2016年5月5日 下午3:50:232016/5/5
收件者:blink-dev、Daniel Cheng

Contact emails

l...@chromium.org


Spec


Summary

Disallow navigations in the unload handler.


Interoperability and Compatibility Risk

When navigating away, Firefox ignores the navigation in the unload handler. Edge adds the navigation to the history, but continues to commit original navigation. Safari aborts the navigation. Chrome currently aborts the navigation the first time the frame is navigating, but commits the second time.


With the proposed change, blink would have the same behavior as Firefox, and be closer to Edge. Overall I think the risk is very low.


Ongoing technical constraints

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

https://crbug.com/590054


Requesting approval to ship?

Yes.

Charlie Reis

未讀,
2016年5月5日 下午4:28:522016/5/5
收件者:Lucas Gadani、blink-dev、Daniel Cheng
I think it's worth clarifying Chrome's current behavior here, since I think only in-page navigations are allowed today.  Can you confirm if I'm correct about the cases below?

1) Cross-document navigations during unload.
I think these are always blocked in Chrome, whether cross-origin or not, right?

2) In-page navigations (fragments, pushState, etc) during unload.
I think Chrome allows these to interrupt the user's attempted navigation, as long as the attempted navigation is same-process.  (Your comment about them not working a second time doesn't apply if you assign the unload handler again.)  If the attempted navigation is cross-process, we may have some internal bugs.

FWIW, I'd love to see in-page navigations blocked as well, but I'm not sure if that will have an impact on pages that try to do a pushState or replaceState as the user leaves.

Charlie

Domenic Denicola

未讀,
2016年5月5日 下午4:31:262016/5/5
收件者:Lucas Gadani、blink-dev、Daniel Cheng
From: Lucas Gadani [mailto:l...@chromium.org]

> The spec isn't clear on this issue (https://www.w3.org/TR/html5/browsers.html#unload-a-document).

This is the wrong section of the wrong spec. I think the spec is fairly clear that navigations should not be allowed during unload.

The relevant algorithm is https://html.spec.whatwg.org/multipage/browsers.html#navigate step 4.

Charlie Reis

未讀,
2016年5月5日 下午5:12:072016/5/5
收件者:Domenic Denicola、Lucas Gadani、blink-dev、Daniel Cheng
Are we sure what Firefox's behavior is here?  It looks like they prevented navigations during unload in https://bugzilla.mozilla.org/show_bug.cgi?id=371360, but then ran into problems with sites that used unload handlers to prevent form submissions from ending up in history (see comment 53, comment 65, and https://bugzilla.mozilla.org/show_bug.cgi?id=409888).

From some manual tests, it does look like Firefox allows unload handlers to navigate to pages that are same origin with the attempted navigation.   Today, Chrome only allows this if the attempted navigation is same origin with the current page and the unload navigation is in-page.  I think that already breaks the form case that was mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=371360 (but that repro case is no longer online, so I can't verify).

I'd still love to see us prevent all navigations during unload if possible.  Maybe the form case is not a concern since we already don't support cross-document navigations during unload?

Charlie

TAMURA, Kent

未讀,
2016年5月5日 下午11:38:422016/5/5
收件者:Lucas Gadani、blink-dev、Daniel Cheng
LGTM1.

--
TAMURA Kent
Software Engineer, Google


Lucas Gadani

未讀,
2016年5月6日 下午4:01:572016/5/6
收件者:Charlie Reis、blink-dev、Daniel Cheng
On Thu, May 5, 2016 at 4:28 PM Charlie Reis <cr...@chromium.org> wrote:
I think it's worth clarifying Chrome's current behavior here, since I think only in-page navigations are allowed today.  Can you confirm if I'm correct about the cases below?

1) Cross-document navigations during unload.
I think these are always blocked in Chrome, whether cross-origin or not, right?

That's correct, the proposed change will only affect in-page navigations, since scheduled navigations are already blocked in Chrome.

 
2) In-page navigations (fragments, pushState, etc) during unload.
I think Chrome allows these to interrupt the user's attempted navigation, as long as the attempted navigation is same-process.  (Your comment about them not working a second time doesn't apply if you assign the unload handler again.)  If the attempted navigation is cross-process, we may have some internal bugs.

Currently, pushState does not interrupt the user's attempted navigation, it only adds the state to the history and continues with the navigation. Fragment navigations are the only ones that should be affected.

 

Lucas Gadani

未讀,
2016年5月6日 下午4:02:482016/5/6
收件者:Domenic Denicola、blink-dev、Daniel Cheng
Thanks for the correction, I'm still not convinced that's what the spec says (and the behavior is different across browsers, but disallowing navigations is the behavior I think is most sensible.

Lucas Gadani

未讀,
2016年5月6日 下午4:10:192016/5/6
收件者:Charlie Reis、Domenic Denicola、blink-dev、Daniel Cheng
Thanks for pointing this out, I've noticed that Firefox actually behaves differently if the navigation that triggers the unload handler is a cross-origin navigation or not. I've tested 8 different scenarios (javascript navigation, regular navigations, inpage navigations and pushState, between the same origin and cross origin). Here are the test cases if anyone wants to reproduce:


The only case where Firefox interrupts the navigation is for same-origin in-page navigations. Chrome interrupts for all in-page navigations, regardless if it's same origin or cross origin (however, when retrying the navigation Chrome will ignore the navigation in the unload handler). Firefox also ignores pushState in the unload handler, but Chrome adds the entry to the history.

Edge is an interesting case, where it'll never interrupt the navigation, but it will also execute navigations in the unload handler even for regular navigations (where all other browsers will block it).

Overall, I'd argue that blocking all navigations in the unload handler is the most sensible thing to do.

Charlie Reis

未讀,
2016年5月6日 下午4:52:052016/5/6
收件者:Lucas Gadani、Domenic Denicola、blink-dev、Daniel Cheng
One clarification regarding same vs cross origin: there's actually 3 URLs involved: the current URL, the attempted navigation's URL, and the unload handler's URL.  Firefox doesn't care about the current URL-- I think it just checks whether the attempted navigation's URL and the unload handler's URL are same-origin.

Anyway, non-owner LGTM for blocking all navigations during unload.  Trying to do something like Firefox's behavior seems problematic in Chrome, since the attempted navigation is often cross-process and may have already committed by the time we run the unload handler in the old process.

Charlie

Rick Byers

未讀,
2016年5月7日 上午9:43:262016/5/7
收件者:Charlie Reis、Daniel Cheng、Domenic Denicola、Lucas Gadani、blink-dev

Thanks for the detailed discussion.  Sounds low risk to me, but to help quantify it (and mitigate the risk some developer is actually relying on this) perhaps it makes sense to add a use counter with deprecation message for one milestone?  WDYT?

Lucas Gadani

未讀,
2016年5月9日 下午3:41:282016/5/9
收件者:Rick Byers、Charlie Reis、Daniel Cheng、Domenic Denicola、blink-dev
That sounds reasonable, I'll work on a patch to add a counter and a message.

Lucas Gadani

未讀,
2016年8月2日 下午2:38:552016/8/2
收件者:Rick Byers、Charlie Reis、Daniel Cheng、Domenic Denicola、blink-dev
Now that this has been in beta for a few weeks, chromestatus is showing usage to be <=0.0001%, I'd like to go ahead and ask approval to ship this on M54.

I'll keep monitoring the usage as it goes into stable, but unless there's a significant change I think it should be safe to ship this in M54.

Rick Byers

未讀,
2016年8月2日 下午2:50:152016/8/2
收件者:Lucas Gadani、Charlie Reis、Daniel Cheng、Domenic Denicola、blink-dev
I double checked the internal M53-specific use counter values for UnloadHandler_Navigation and they're at 0.00001% of M53 PageVisits.  Note that since Android Beta is still M52, we don't really have any Android data yet, but I did a quick check of Android dev data and it's consistent with this very low usage.

So LGTM2 to remove (I consider tkent@'s LGTM1 to be still standing, since we have only strictly better information).

Chris Harrelson

未讀,
2016年8月2日 下午3:00:372016/8/2
收件者:Rick Byers、Lucas Gadani、Charlie Reis、Daniel Cheng、Domenic Denicola、blink-dev
LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Joe Medley

未讀,
2016年8月3日 上午11:20:282016/8/3
收件者:Lucas Gadani、Rick Byers、Chris Harrelson、Charlie Reis、Daniel Cheng、Domenic Denicola、blink-dev
Lucas,

Can you please create a status entry now.



Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Joe Medley

未讀,
2016年9月14日 下午7:02:162016/9/14
收件者:blink-dev、dch...@chromium.org
Every cycle, Chrome DevRel (specifically, me) publishes a post on deprecations and removals like this one we did for Chrome 53. I was trying to add this feature to my draft for Chrome 54. I trying to make sure I understood it, I ran all test cases Lucas's zip file. My understanding of this is that in Chrome 54, all navigations in window.onunload are ignored.

Except that, I found this to be true in Chrome 52.

The only difference I observed the browser history.

Did I misunderstand? What am I missing? I could really use a push in the right direction here.

Thanks

Lucas Gadani

未讀,
2016年9月14日 下午10:14:372016/9/14
收件者:Joe Medley、blink-dev、dch...@chromium.org
That's right, for most things there should be no difference, since regular navigations were already blocked previously in Chrome. The only difference is that now we also block fragment navigations (i.e. navigating to window.location.hash = 'hashname' or navigating to #hashname).

You can also look at the layout test added that exercises this difference:

sexmo...@gmail.com

未讀,
2016年9月22日 上午4:45:142016/9/22
收件者:blink-dev、dch...@chromium.org
回覆所有人
回覆作者
轉寄
0 則新訊息