New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 154321 link

Starred by 13 users

Issue metadata

Status: WontFix
Owner:
Closed: Sep 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocked on:
issue 160585
issue 554834



Sign in to add a comment

Chrome on mobile should be consistent about firing or not firing beforeunload/unload handlers

Project Member Reported by ojan@chromium.org, Oct 5 2012

Issue description

Related discussion at crbug.com/142458.

Here's what we do with beforeunload/unload handlers as best I could tell:
-Chrome on Android fires unload events only if you do an in-process (e.g. same domain) navigation. It doesn't fire them if you do a cross-process navigation or if you close the tab.
-Chrome on iOS fires beforeunload/unload events, but does not show a beforeunload dialog.

I tested this by putting an <img> request in the handler and seeing if my server logged the request.

We should try to consistently fire or not fire these. I think we can get away with never firing these on mobile, so we should try to for that. It's difficult, for example, to see how we'd making Chrome on Android fire these events when you do a swipe to close navigation since beforeunload can prevent the close.

Do we have any control of this on iOS? Are WebCore settings exposed to webviews? If so, I can add a setting to WebCore to disable beforeunload/unload handlers. We'd probably want this for android anyways.

Not sure I CC'ed the right iOS/android folks. Please add CC's as appropriate.
 

Comment 1 by ojan@chromium.org, Oct 9 2012

Labels: OS-Android OS-iOS
> Do we have any control of this on iOS?

Not though any sane mechanism, but we might be able to manage something via JS.

> Are WebCore settings exposed to webviews?

No; essentially nothing is exposed from UIWebView :(

Comment 3 by vinodkr@google.com, Oct 9 2012

Status: Available

Comment 4 by ojan@chromium.org, Oct 19 2012

Cc: arv@chromium.org abarth@chromium.org
Arv, any ideas on how we could disable beforeunload/unload events from JS for iOS? I suppose we could hook addEventListener on the window and make it a noop if the event type is beforeunload/unload? It's super-hacky, but it should work the vast majority of the time.

Is there someone on the Android team that can look into this? I can add a WebCore setting if that's what we need.

Comment 5 by abarth@chromium.org, Oct 19 2012

We're never going to make Chrome on iOS be a consistent platform with the rest of Chrome.  I don't think we should even try.

Comment 6 by arv@chromium.org, Oct 19 2012

I'm with Adam here. Lets not even try.

To do this from JS, since EventTarget is not on the prototype chain, you would have to override 200+ methods.

Comment 7 by ojan@chromium.org, Nov 16 2012

Blockedon: chromium:160585
Project Member

Comment 8 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI Cr-UI

Comment 9 by Deleted ...@, Oct 11 2013

I'm curious why you would want to not support these events on Chrome on Android. After testing with most other browser/platform combinations, chrome+android is the only combination where these events do not fire. For consistency, it would be great if it worked the same as chrome+iOS, or chrome+Mac or Safari, Firefox, Android native browser etc. 

Comment 10 by ojan@chromium.org, Oct 11 2013

Android browser, Safari and Chrome+iOS also don't consistently fire beforeunload. I expect Firefox is the same.

The reason to not fire these events is because the present a poor user-experience. If we don't have unload events to fire, then we can force kill the process and give a much more responsive user experience.

Comment 11 by Deleted ...@, Oct 12 2013

I think removing the ability to use the event because it may slow down a close is not the consistent solution. Instead maybe the browser can kill the process if the unload handler is taking more than x milliseconds. 

I think developers expect not to rely on the event getting fired based on the nature of it. It's just considered to "mostly" work. In my experience, any clean close seems to fire the event fine across platforms and across browsers. It is tremendously useful to be able to send an Ajax request back to a server notifying it of events like video stop. Otherwise you need to send back Ajax requests every second to a server to gather video view statistics. 

Anyway, I would really like to request that the decision be reviewed again so that chrome on android behaves the same as it does on all other platforms.  If will also be consistent with all other modern browser behavior.  Thanks for your time on this!
I have noticed using the last version of Chrome on Android the unload is triggerred only if the tab has been opened from an existing tab. 
f I open a new tab and put my url and close the window, the unload action will not be triggered.

I hope this will be fixed soon.

Comment 13 by toml...@gmail.com, Nov 12 2014

The irony of justifying this on "user experience" grounds (whose user?) is that it tends to do the opposite. Web developers might *want* to clean up, or fire off a session-state update, or do other housecleaning in order to favour the end-to-end user experience. But because we can't do this reliably, we end up with localStorage leaks and tight polling loops etc. Compromising the user experience.

IMO the "user" in question here is in fact a user of web apps that happen to work well in Chrome. To the extent he's protected from the bad, the user may find the good is  better elsewhere. 
Cc: -erikkay@chromium.org
Labels: hotlist-ios-fixit
Labels: hotlist-ios-fixit-droger
Labels: -hotlist-ios-fixit-droger
Labels: ios-fixit-droger
Labels: ios-fixit-pkl
Labels: ios-fixit-rohitrao
Labels: ios-fixit-marq
Labels: hostlist-ios-fixit-droger
Labels: -ios-fixit-droger
Labels: -ios-fixit-pkl -ios-fixit-rohitrao
Labels: hotlist-ios-fixit-pkl
Labels: -hostlist-ios-fixit-droger
Labels: -hotlist-ios-fixit-pkl
Labels: hotlist-ios-fixit-rohitrao
Labels: -OS-iOS -Cr-UI -ios-fixit-marq Cr-Blink hotlist-ios-fixit-done
Per comment #5, it doesn't sound like we're planning to change iOS behavior at all, so removing the OS-iOS label.
Project Member

Comment 30 by sheriffbot@chromium.org, Jun 16 2016

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 31 by tkent@chromium.org, Jun 22 2016

Components: -Blink Blink>Loader
Any sign of movement on this?

Chrome 54.0.2840.85 on Android 4.4.4 and others doesn't receive either onbeforeunload or onunload when I close a tab or close Chrome via the OS.

The onbeforeunload I can understand since it's problematical to prevent the close.

The missing onunload is very disappointing. It's the first and last opportunity that the browser has to take an action before exit.  Not every web application is stateless, and while developers shouldn't rely on it, it's certainly helpful to be able to take an action there.

It's particularly jarring since Chrome on desktop receives both events and it's not unreasonable to assume that Chrome on Android would get at least the onunload.

Comment 33 by ojan@chromium.org, Dec 12 2016

Blockedon: 554834
Cc: gab@chromium.org kinuko@chromium.org
https://www.igvita.com/2015/11/20/dont-lose-user-and-app-state-use-page-visibility/ reflects the latest thinking on this.

unload/beforeunload/pagehide cannot be 100% reliably implemented on mobile platforms. Once  issue 554834  is fixed, visibilitychange will be the right thing to use.
Thanks for that info.  It's helpful, but disappointing, as it conflates temporary visibility with ending a session.  If it's what we've got to work with then we'll have to make the best of it though.
Owner: ojan@chromium.org
Status: Assigned (was: Untriaged)
Triager assining this to ojan@ for his thoughts on next possible actions.

As discussed above, making unload event happen reliably is hard on mobile OSs.
-> visibilityChange is suggested as a workaround
-> What can we do about flaky behavior? Should we always disable it if we can't dispatch it reliably?

Comment 36 by ojan@chromium.org, May 10 2017

Owner: panicker@chromium.org
panicker is looking into next steps fore beforeunload/unload.
Components: Blink>PageLifecycle
Status: WontFix (was: Assigned)
visibilitychange is the best bet here.

Sign in to add a comment