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

Issue 701435 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 832234
Owner: ----
Closed: Sep 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

we should reduce the amount of time we give beforeunload/unload handlers to run

Project Member Reported by ojan@chromium.org, Mar 14 2017

Issue description

Today we have a 1 second timeout. That is too much time given that this is on the critical path of a user closing a tab. We should reduce that to something like 500ms or less.

See also related  issue 701434 .
 

Comment 1 by dcheng@chromium.org, Mar 27 2017

Cc: dcheng@chromium.org
Do we know how often this is blocking on a subframe beforeunload vs a main frame beforeunload? It's possible that  issue 692224  will mitigate this somewhat (by simply not running them as much)

Comment 2 by ojan@chromium.org, Mar 27 2017

I don't know of any tracking of whether it's subframes or parent pages. As per the latest discussion in  issue 692224 , it won't help here because we're still running the code. We're just not allowing for showing the dialog.

Comment 3 by creis@chromium.org, Aug 25 2017

Cc: a...@chromium.org nasko@chromium.org clamy@chromium.org creis@chromium.org
Components: UI>Browser>Navigation
Issue 365039 should help with this, where we won't try to run the beforeunload handler if there isn't one registered.

As I mentioned on  issue 701434 , I'd be concerned about slow machines not having enough time to tell the user that they're going to lose data if we lower the timeout too much.  Maybe some UMA stats could give us a sense for how often this happens?
Components: Blink>PageLifecycle
Mergedinto: 832234
Status: Duplicate (was: Untriaged)

Sign in to add a comment