Intent to Implement & Ship: Disallow Sync XHR in Page Dismissal

2578 views
Skip to first unread message

Shubhie Panicker

unread,
Jun 18, 2018, 5:42:48 PM6/18/18
to blink-dev

Contact emails

pani...@chromium.org


Summary

Disallow Sync XHR during page dismissal when the page is being navigated away or closed by the user, this involves the following events (when fired on the path of page dismissal) i.e. beforeunload, unload, pagehide and visibilitychange.

We plan to ship this with Finch so that the experiment can be paused if any major issues are found.


Motivation

Sync XHR is on the deprecation path, it hurts the end user experience.

beforeunload and unload are used by third parties and first parties to send analytics data to servers. While this is reasonable, there are no good reasons to use Sync XHR, instead SendBeacon, Fetch keep-alive should be used (in addition to sending analytics periodically and on pagevisibility etc).

Page dismissal is also interesting scenario for the following reasons:

  1. It hurts the user experience when the user is trying to leave the page or navigate (up to a max timeout of 1s, which is 2s in practice in chrome)

  2. The intention of beforeunload handler is a mechanism for preventing data loss for users, however it is used by third parties as a way to reliably do a bunch of work (including sync xhr), up to the max timeout. Some relevant data in this slide deck. This hurts the end user experience.

  3. As part of Page Lifecycle API: we want to experiment with running the beforeunload handler at the time of freezing (to determine risk of data loss) to support proactive tab discarding. And Sync XHR (and large amount of work) is problematic here.

Note that there is a separate effort of changing the timeout for beforeunload & unload from 1s to 500ms. We think disallowing sync XHR together with updating the timeout to 500ms would improve the issues listed above.


Compatibility risk

Compat risk: medium

Could break third parties’ analytics that use Sync xhr. Rolling this out via Finch experiment helps mitigate the risk, as the experiment can be paused if major issues are found.

            

Interoperability risk: low

Sync XHR is already on the deprecation path.

Microsoft (Angelo Liao) has supported the plan for deprecation of Sync XHR, this was discussed at the last TPAC and notes say that there was vendor agreement at the meeting to "Announce deprecation for unload/beforeunload case".


Debuggability

We plan to generate deprecation warnings via Reporting API. (Console warning during page dismissal is not very helpful)


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

Yes.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4664843055398912



Chris Harrelson

unread,
Jun 18, 2018, 6:01:02 PM6/18/18
to Shubhie Panicker, blink-dev
Hi,

Is there any UseCounter of how often sync XHR is used in these cases?

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi--QbHmWAbBE0E2jyo6fHQNQgWs9zN_j8PTCCR_d6%3Dgag%40mail.gmail.com.

Shubhie Panicker

unread,
Jun 18, 2018, 7:06:07 PM6/18/18
to Chris Harrelson, blink-dev
We don't have a usecounter (I know we prefer usecounter over UMA) though we do have UMA for occurrence of sync xhr in beforeunload, unload etc ( UMA is XHR.Sync.PageDismissal) and count of beforeunload, unload etc. (via UMA: DocumentEventTiming.BeforeUnloadDuration etc)
Based on UMA counts from Windows 7-day stable:
frequency of sync xhr firing in beforeunload is 0.18% as a fraction of count of beforeunload firing.
Similarly for unload this is 0.074%.
Happy to slice the data in a different way if that's helpful.



To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_fMJqKfUTMuBq%2B0ad5uAW0nuo6-FwgTN53WOxQCPrbrQ%40mail.gmail.com.

Anne van Kesteren

unread,
Jun 19, 2018, 3:41:43 AM6/19/18
to Shubhie Panicker, blink-dev
On Mon, Jun 18, 2018 at 11:42 PM, Shubhie Panicker
<pani...@chromium.org> wrote:
> Disallow Sync XHR during page dismissal when the page is being navigated
> away or closed by the user, this involves the following events (when fired
> on the path of page dismissal) i.e. beforeunload, unload, pagehide and
> visibilitychange.
>
> We plan to ship this with Finch so that the experiment can be paused if any
> major issues are found.

What's the plan for standardization around this?


--
https://annevankesteren.nl/

Jochen Eisinger

unread,
Jun 19, 2018, 4:00:08 AM6/19/18
to Anne van Kesteren, Shubhie Panicker, blink-dev
lgtm1 as I think this is in general the right direction

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

PhistucK

unread,
Jun 19, 2018, 8:59:25 AM6/19/18
to Jochen Eisinger, Anne van Kesteren, Shubhie Panicker, blink-dev
The use counter was at around 1.4% up until several days ago (June 11th) and then suddenly dropped to 0.83% four days later. A day later, 0.79%. A day later, 0.78%.
Can we trust those numbers?
I guess large website(s) dropped some usage?

A synchronous XMLHttpRequest on page dismissal might also be used for unlocking documents (Google Docs and other file management facilities), which can severely break the user experience (a document/file is suddenly inexplicably locked with no way to unlock it in a timely manner), or data may not be saved.

The percentage is pretty high for a removal (it is a bit funny to call it "implement and ship" instead of "deprecate and remove", you are removing a highly used functionality here). What is the plan? Deprecated for how long? When will it be removed?

For debuggability -
Is the reporting API used by anyone (I cannot find a use counter)? I would not count on non-negligible usage, so the deprecation warnings will effectively be completely hidden and developers will be surprised.
Perhaps the Developer Tools can emit a console warning despite "persist log" being disabled. Keeping warnings from the previous navigation if they were emitted during page dismissals.


PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuic4z73JmjZ5pJHaSdWhqkcAcThujw5hyzVd3nvxN%2BREUw%40mail.gmail.com.

Shubhie Panicker

unread,
Jun 19, 2018, 12:53:34 PM6/19/18
to PhistucK, Jochen Eisinger, Anne van Kesteren, blink-dev, Jason Chase, Pavel Feldman
Apologies -- there is usecounter (SyncXHRInPageDismissal), I added that last year and only remembered the UMA (as I've used it a bunch).
According to usecounter this is 0.9% for 7-day stable and 0.7% for 1-day.

Regarding deprecation: My understanding is that Sync XHR has already been deprecated for years.
This Intent is to disallow it from page dismissal path.
I agree that doing some outreach to give a heads-up to developers using this would be good, if I can get some DevRel support.


On Tue, Jun 19, 2018 at 5:58 AM, PhistucK <phis...@gmail.com> wrote:
The use counter was at around 1.4% up until several days ago (June 11th) and then suddenly dropped to 0.83% four days later. A day later, 0.79%. A day later, 0.78%.
Can we trust those numbers?
I guess large website(s) dropped some usage?

A synchronous XMLHttpRequest on page dismissal might also be used for unlocking documents (Google Docs and other file management facilities), which can severely break the user experience (a document/file is suddenly inexplicably locked with no way to unlock it in a timely manner), or data may not be saved.
Google Docs is not using sync xhr (they use sendBeacon though), I verified.
Could you elaborate on the specific usecase you have in mind that can only be addressed with Sync XHR? 
(If we find such use-cases, I'm happy to abandon this work.)

The percentage is pretty high for a removal (it is a bit funny to call it "implement and ship" instead of "deprecate and remove", you are removing a highly used functionality here). What is the plan? Deprecated for how long? When will it be removed? 

For debuggability -
Is the reporting API used by anyone (I cannot find a use counter)? I would not count on non-negligible usage, so the deprecation warnings will effectively be completely hidden and developers will be surprised.
I believe this only just shipped (in M67?)
+Jason to confirm
 
Perhaps the Developer Tools can emit a console warning despite "persist log" being disabled. Keeping warnings from the previous navigation if they were emitted during page dismissals. 
+Pavel to comment if this makes sense. 



PhistucK


On Tue, Jun 19, 2018 at 11:00 AM Jochen Eisinger <joc...@chromium.org> wrote:
lgtm1 as I think this is in general the right direction

On Tue, Jun 19, 2018 at 9:41 AM Anne van Kesteren <ann...@annevk.nl> wrote:
On Mon, Jun 18, 2018 at 11:42 PM, Shubhie Panicker
<pani...@chromium.org> wrote:
> Disallow Sync XHR during page dismissal when the page is being navigated
> away or closed by the user, this involves the following events (when fired
> on the path of page dismissal) i.e. beforeunload, unload, pagehide and
> visibilitychange.
>
> We plan to ship this with Finch so that the experiment can be paused if any
> major issues are found.

What's the plan for standardization around this?


--
https://annevankesteren.nl/

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78jYb0YXCPDbWuTjOmVx0tH4vjnnqtJP8KTj7RNsEOG8JA%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
Jun 19, 2018, 1:01:26 PM6/19/18
to Shubhie Panicker, PhistucK, Jochen Eisinger, Anne van Kesteren, blink-dev, Jason Chase, Pavel Feldman
0.9% of pages is quite a lot. Could you do an HTTP archive search w/use counter to find out which are the top sites affected?




PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi-sZ1g90jYDt0ctgvek4AqNKSMzY0ERjoOTDc6h3-9hKQ%40mail.gmail.com.

PhistucK

unread,
Jun 19, 2018, 3:04:35 PM6/19/18
to Shubhie Panicker, Jochen Eisinger, Anne van Kesteren, blink-dev, Jason Chase, Pavel Feldman
See my comments inline.

PhistucK


On Tue, Jun 19, 2018 at 7:53 PM Shubhie Panicker <pani...@chromium.org> wrote:
Apologies -- there is usecounter (SyncXHRInPageDismissal), I added that last year and only remembered the UMA (as I've used it a bunch).
According to usecounter this is 0.9% for 7-day stable and 0.7% for 1-day.

Regarding deprecation: My understanding is that Sync XHR has already been deprecated for years.
This Intent is to disallow it from page dismissal path.
I agree that doing some outreach to give a heads-up to developers using this would be good, if I can get some DevRel support.


On Tue, Jun 19, 2018 at 5:58 AM, PhistucK <phis...@gmail.com> wrote:
The use counter was at around 1.4% up until several days ago (June 11th) and then suddenly dropped to 0.83% four days later. A day later, 0.79%. A day later, 0.78%.
Can we trust those numbers?
I guess large website(s) dropped some usage?

A synchronous XMLHttpRequest on page dismissal might also be used for unlocking documents (Google Docs and other file management facilities), which can severely break the user experience (a document/file is suddenly inexplicably locked with no way to unlock it in a timely manner), or data may not be saved.
Google Docs is not using sync xhr (they use sendBeacon though), I verified.
Could you elaborate on the specific usecase you have in mind that can only be addressed with Sync XHR? 
(If we find such use-cases, I'm happy to abandon this work.)

​I want to get rid of this feature altogether as well, believe me. I was not ​trying to come up with good use cases, I was trying to come up with current usage that might be badly broken by this without any real advance notice (it is nice to expect everyone to use the reporting API, but most developers are, unfortunately, not so proactive, especially when it requires an infrastructure for storing this data :().

 



PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Shubhie Panicker

unread,
Jun 19, 2018, 3:39:47 PM6/19/18
to Anne van Kesteren, blink-dev
I intend to update the spec and make this a standard once we are close to shipping, i.e. all goes well with finch experiment (and of course this Intent goes through etc)


--
https://annevankesteren.nl/

Jason Chase

unread,
Jun 19, 2018, 4:24:04 PM6/19/18
to blink-dev, phis...@gmail.com, joc...@chromium.org, ann...@annevk.nl, cha...@google.com, pfel...@google.com


On Tuesday, June 19, 2018 at 12:53:34 PM UTC-4, Shubhie Panicker wrote:
Apologies -- there is usecounter (SyncXHRInPageDismissal), I added that last year and only remembered the UMA (as I've used it a bunch).
According to usecounter this is 0.9% for 7-day stable and 0.7% for 1-day.

Regarding deprecation: My understanding is that Sync XHR has already been deprecated for years.
This Intent is to disallow it from page dismissal path.
I agree that doing some outreach to give a heads-up to developers using this would be good, if I can get some DevRel support.


On Tue, Jun 19, 2018 at 5:58 AM, PhistucK <phis...@gmail.com> wrote:
The use counter was at around 1.4% up until several days ago (June 11th) and then suddenly dropped to 0.83% four days later. A day later, 0.79%. A day later, 0.78%.
Can we trust those numbers?
I guess large website(s) dropped some usage?

A synchronous XMLHttpRequest on page dismissal might also be used for unlocking documents (Google Docs and other file management facilities), which can severely break the user experience (a document/file is suddenly inexplicably locked with no way to unlock it in a timely manner), or data may not be saved.
Google Docs is not using sync xhr (they use sendBeacon though), I verified.
Could you elaborate on the specific usecase you have in mind that can only be addressed with Sync XHR? 
(If we find such use-cases, I'm happy to abandon this work.)

The percentage is pretty high for a removal (it is a bit funny to call it "implement and ship" instead of "deprecate and remove", you are removing a highly used functionality here). What is the plan? Deprecated for how long? When will it be removed? 

For debuggability -
Is the reporting API used by anyone (I cannot find a use counter)? I would not count on non-negligible usage, so the deprecation warnings will effectively be completely hidden and developers will be surprised.
I believe this only just shipped (in M67?)
+Jason to confirm
The Reporting API has not yet shipped. It seems there's some concerns that need to be addressed. I'm not aware of when it is expected to ship. We also need to ship Deprecation reports on top of the reporting infrastructure. That is in the near-term plans, ideally by M70.

Mike West

unread,
Jun 20, 2018, 5:29:44 AM6/20/18
to blink-dev, PhistucK, Jochen Eisinger, Anne van Kesteren, Jason Chase, Pavel Feldman, cha...@chromium.org, pani...@chromium.org
Like Jochen, I very much support this direction. Like Chris, I'm surprised (and a little worried) about the usage numbers.

I think my opinion about shipping this behavior depends on the intent of the usage. If folks are sending metrics and measurement information up as a sync XHR when navigating, then there's zero user impact, and analytics packages will be incentivized to upgrade themselves to something like Beacon. If, on the other hand, folks are using sync XHR to save user data before navigating, then I could imagine bad user-visible outcomes to killing the feature. Do you have a feel for which is more common?

-mike

P.S. I agree with Anne's implicit suggestion that we should file a bug against the relevant specs (I suppose XHR would look at the relevant termination nesting level?) to more actively solicit vendors opinions. I was in the TPAC meeting, and my recollection is that folks were on board with this kind of deprecation, but actively poking them publicly seems like a good plan. :)




PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Shubhie Panicker

unread,
Jun 20, 2018, 3:11:56 PM6/20/18
to Mike West, Andy Davies, blink-dev, PhistucK, Jochen Eisinger, Anne van Kesteren, Jason Chase, Pavel Feldman, Jason Chase
On Wed, Jun 20, 2018 at 2:29 AM, Mike West <mk...@chromium.org> wrote:
Like Jochen, I very much support this direction. Like Chris, I'm surprised (and a little worried) about the usage numbers.

I think my opinion about shipping this behavior depends on the intent of the usage. If folks are sending metrics and measurement information up as a sync XHR when navigating, then there's zero user impact, and analytics packages will be incentivized to upgrade themselves to something like Beacon. If, on the other hand, folks are using sync XHR to save user data before navigating, then I could imagine bad user-visible outcomes to killing the feature. Do you have a feel for which is more common?
I do have a feel for this based on extensive research in google3 codebase when working on Lifecycle API (example use-cases for google3 in this doc - corp only) and data from 3P usage (such as this slide deck from Andy).   
My conclusion is that sync xhr is primarily used by analytics (popular analytics libraries are driving the usecount) and I haven't seen this used for saving user data (obviously this is biased towards Google apps and I didn't study every app :)).

I've also reached out to GSuite folks to double-check in their apps (Docs is not using sync xhr, as I mentioned), they will get early next week. Also did a sanity check with Ads and they weren't worried.

Isn't this the type of thing we could assess via Finch in canary, dev? Or is that not an effective way to find breakages in external analytics?




PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Yoav Weiss

unread,
Jun 21, 2018, 12:47:12 AM6/21/18
to Shubhie Panicker, Mike West, Andy Davies, blink-dev, PhistucK, Jochen Eisinger, Anne van Kesteren, Jason Chase, Pavel Feldman, Jason Chase
On Wed, Jun 20, 2018 at 8:11 PM Shubhie Panicker <pani...@chromium.org> wrote:
On Wed, Jun 20, 2018 at 2:29 AM, Mike West <mk...@chromium.org> wrote:
Like Jochen, I very much support this direction. Like Chris, I'm surprised (and a little worried) about the usage numbers.

Same
 

I think my opinion about shipping this behavior depends on the intent of the usage. If folks are sending metrics and measurement information up as a sync XHR when navigating, then there's zero user impact, and analytics packages will be incentivized to upgrade themselves to something like Beacon.

Indeed. Also, if this is the case, there is a relatively small number of analytics vendors/libraries which can be pressured to upgrade (or lose those beacons).
 
If, on the other hand, folks are using sync XHR to save user data before navigating, then I could imagine bad user-visible outcomes to killing the feature. Do you have a feel for which is more common?
I do have a feel for this based on extensive research in google3 codebase when working on Lifecycle API (example use-cases for google3 in this doc - corp only) and data from 3P usage (such as this slide deck from Andy).   
My conclusion is that sync xhr is primarily used by analytics (popular analytics libraries are driving the usecount) and I haven't seen this used for saving user data (obviously this is biased towards Google apps and I didn't study every app :)).

I wouldn't think Google apps represent the typical developer here, but at the same time, never heard of such a practice either.

I'm wondering if there's some HA search we can run on the response bodies which would enable us to have more certainty:
* Filter out the text inside of handlers for the affected events. Theoretically that requires JS parsing (which BQ doesn't have implemented AFAIK), but maybe we can fake it with regex magic?
* On that text, look for ".open()" calls where the third parameter is present and is "false".

Does that make sense?
 

I've also reached out to GSuite folks to double-check in their apps (Docs is not using sync xhr, as I mentioned), they will get early next week. Also did a sanity check with Ads and they weren't worried.

Isn't this the type of thing we could assess via Finch in canary, dev? Or is that not an effective way to find breakages in external analytics?

If there is breakage related to user data, I suspect canary and dev doesn't give us a wide-enough audience to discover that. Also, such issues may take time for users to figure out by their nature. (requires multiple sessions and paying attention to what should have been saved and wasn't)





PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi_qAZHsHgFaAKdT0rsYaPh4r%2B2qWawpf%2BeYkpmfiNr%3Dgw%40mail.gmail.com.

PhistucK

unread,
Jun 21, 2018, 1:12:15 AM6/21/18
to Yoav Weiss, Shubhie Panicker, Mike West, a...@andydavies.net, blink-dev, Jochen Eisinger, Anne van Kesteren, Jason Chase, Pavel Feldman, Jason Chase
Event handlers are rarely direct (addEventListener("beforeunload", () => { /* XMLHttpRequest code */ }), they usually go through some framework ($.on("beforeunload")) which means multiple layers of code are running before the actual handler is run, so the text will probably framework text, I assume.
Plus, the usage of synchronous XMLHttpRequest is also usually not direct (new XMLHttpRequest()), it also usually goes through some framework/micro-framework ($.ajax({..., async: false})).

So that query would probably not yield much...

PhistucK

Yoav Weiss

unread,
Jun 21, 2018, 1:25:18 AM6/21/18
to PhistucK, Anne van Kesteren, Jason Chase, Jason Chase, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net, blink-dev


On Thu, Jun 21, 2018, 06:12 PhistucK <phis...@gmail.com> wrote:
Event handlers are rarely direct (addEventListener("beforeunload", () => { /* XMLHttpRequest code */ }), they usually go through some framework ($.on("beforeunload")) which means multiple layers of code are running before the actual handler is run, so the text will probably framework text, I assume.
Plus, the usage of synchronous XMLHttpRequest is also usually not direct (new XMLHttpRequest()), it also usually goes through some framework/micro-framework ($.ajax({..., async: false})).

So that query would probably not yield much...

Good points about the levels of indirection that will obscure this. Alternatively, maybe HA has data regarding the use counters which were triggered on a page?

pme...@chromium.org

unread,
Jun 21, 2018, 9:52:33 AM6/21/18
to blink-dev, phis...@gmail.com, ann...@annevk.nl, cha...@google.com, cha...@chromium.org, joc...@chromium.org, mk...@chromium.org, pfel...@google.com, pani...@chromium.org, a...@andydavies.net
HA has use counter data but doesn't record the closing/unloading of pages, just the page load so they wouldn't trip over the feature.

Was use counter data added to UKM?  That would provide a candidate pool of URLs that trip the feature bit.  Otherwise, it should be relatively easy to throw something together using puppeteer that crawls an url list, closing each page and watching for the feature to trip (may take a week or two to run through the 4M urls in the CrUX list but hopefully would find a few urls relatively quickly).  I can take a crack at the puppeteer script if it would help.

Rick Byers

unread,
Jun 21, 2018, 1:45:11 PM6/21/18
to Patrick Meenan, blink-dev, PhistucK, Anne van Kesteren, Jason Chase, Jason Chase, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net
I'm also convinced we should deprecate and remove this. To me the main question is what is the right amount of developer outreach to do before pulling the trigger. One option is to add UKM support and try reaching out to the owners of the scripts most often hitting it. But it's hard to say if that would provide good return on investment or not.

What outreach has been done already to clearly explain to developers why sync XHR is bad, and what the reasonable alternatives are? From discussions like this I'm worried that people whose analytics are broken by this may not understand the justification or appreciate the availability of better alternatives. Perhaps there might be some issues with sendBeacon / keep-alive fetch which we don't fully understand also?

Shubhie, there's definitely nothing blocking trying this out in dev/canary (just make sure to do so either via finch, or with an RBS block indicating it must be disabled before beta) - feel free to do that if you like. Getting some bug reports would definitely be a valuable signal. Not getting any reports may not provide much signal though (will developers really notice/care if analytics reports go down by a tiny fraction?).

Rick

--
 
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Rick Byers

unread,
Jun 21, 2018, 1:50:34 PM6/21/18
to Patrick Meenan, blink-dev, PhistucK, Anne van Kesteren, Jason Chase, Jason Chase, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net
Sorry, I should add that the API owners discussed this today. We agree that this case is pretty special:
  • sync XHR has been deprecated and actively discouraged for years
  • Any breakage is likely to be almost entirely analytics.
  • Any other sorts of breakage (eg. user data loss) would already be a problem - eg. for tab discarding - especially on mobile and CrOS, renderer crashes, etc. 
The other thing we discussed about developer outreach is that sync-xhr has been one of those (no longer practiced) "hopeful deprecations" where we generated a warning without any clear plan to actually do the removal. In general in those cases we want to upgrade the warning to a real deprecation (which gets a higher severity in devtools IIRC) that includes a milestone and link for more specific details. But Yoav points out that in this case there's probably nobody who will notice the warning since it happens only at unload time, and devtools clears the console on navigation. So it's not clear how much value there is in having an unload-specific warning. Shubie, any thoughts? I guess developers will still want to be able to debug their newly broken pages - probably set a breakpoint on the XHR to see what's going on... 

Yoav Weiss

unread,
Jun 22, 2018, 3:36:08 AM6/22/18
to Rick Byers, igri...@google.com, n...@nicj.net, Patrick Meenan, blink-dev, PhistucK, Anne van Kesteren, Jason Chase, Jason Chase, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net
On Thu, Jun 21, 2018 at 7:50 PM Rick Byers <rby...@chromium.org> wrote:
Sorry, I should add that the API owners discussed this today. We agree that this case is pretty special:
  • sync XHR has been deprecated and actively discouraged for years
  • Any breakage is likely to be almost entirely analytics.
  • Any other sorts of breakage (eg. user data loss) would already be a problem - eg. for tab discarding - especially on mobile and CrOS, renderer crashes, etc. 
The other thing we discussed about developer outreach is that sync-xhr has been one of those (no longer practiced) "hopeful deprecations" where we generated a warning without any clear plan to actually do the removal. In general in those cases we want to upgrade the warning to a real deprecation (which gets a higher severity in devtools IIRC) that includes a milestone and link for more specific details. But Yoav points out that in this case there's probably nobody who will notice the warning since it happens only at unload time, and devtools clears the console on navigation. So it's not clear how much value there is in having an unload-specific warning.

Maybe there's a way for such warnings to survive navigations, and increase the chances of someone noticing them?
 
Shubie, any thoughts? I guess developers will still want to be able to debug their newly broken pages - probably set a breakpoint on the XHR to see what's going on... 

On Thu, Jun 21, 2018 at 1:44 PM Rick Byers <rby...@chromium.org> wrote:
I'm also convinced we should deprecate and remove this. To me the main question is what is the right amount of developer outreach to do before pulling the trigger. One option is to add UKM support and try reaching out to the owners of the scripts most often hitting it. But it's hard to say if that would provide good return on investment or not.

What outreach has been done already to clearly explain to developers why sync XHR is bad, and what the reasonable alternatives are?

I believe there was a fair bit of outreach over the years. There's this post from 2012. There's also this one from 2014. MDN has an entry on the subject, telling developers to move away from syncXHR and tackle those use-cases with Beacon. 

+Ilya Grigorik may know of more efforts on that front.

I think the general developer outreach in this case was done, for many years, and doubt more of it would make a dent. If we decide to be cautious, what we may need is to find the offenders and try to reach out to them specifically. As Pat suggested, that may require UKM or a dedicated crawler. OTOH, we could also experiment with removal on a larger scale (beyond dev/Canary) and see who notices and why.
 
From discussions like this I'm worried that people whose analytics are broken by this may not understand the justification or appreciate the availability of better alternatives. Perhaps there might be some issues with sendBeacon / keep-alive fetch which we don't fully understand also?

Looking through the open issues related to sendBeacon, the prominent ones seem to be:
https://crbug.com/611453 - Seems like beacons are classified as their own type, causing some extensions to unnecessarily block them.
https://crbug.com/522129 - There also seem to be some extension related accounting issues with beacon requests.
https://crbug.com/724929 - There seem to be some issues with using beacons with blob URLs.
https://crbug.com/468170 - beacons are not intercepted by Service Workers.

Adding +Nic Jansma to keep me honest, but it seems like none of these issues is a blocker to adoption. Also, none of them have a huge number of "stars" FWIW.

There were also some devtools issues related to sendBeacon, but think they got resolved. (e.g. https://crbug.com/520538)
A quota related issue (which I *know* was holding back adoption for some large third party vendors) was also resolved a few months ago.

Interestingly enough, it seems like OOPIF is not firing beforeunload events at all at the moment, which indeed breaks some sites, but at the same time, means that anyone which relies on beforeunload to save user data may already be broken at least when using cross-origin iframes with site isolation.



Shubhie, there's definitely nothing blocking trying this out in dev/canary (just make sure to do so either via finch, or with an RBS block indicating it must be disabled before beta) - feel free to do that if you like. Getting some bug reports would definitely be a valuable signal. Not getting any reports may not provide much signal though (will developers really notice/care if analytics reports go down by a tiny fraction?).

Rick

On Thu, Jun 21, 2018 at 9:52 AM <pme...@chromium.org> wrote:
HA has use counter data but doesn't record the closing/unloading of pages, just the page load so they wouldn't trip over the feature.

Was use counter data added to UKM?  That would provide a candidate pool of URLs that trip the feature bit.  Otherwise, it should be relatively easy to throw something together using puppeteer that crawls an url list, closing each page and watching for the feature to trip (may take a week or two to run through the 4M urls in the CrUX list but hopefully would find a few urls relatively quickly).  I can take a crack at the puppeteer script if it would help.

On Thursday, June 21, 2018 at 1:25:18 AM UTC-4, Yoav Weiss wrote:


Event handlers are rarely direct (addEventListener("beforeunload", () => { /* XMLHttpRequest code */ }), they usually go through some framework ($.on("beforeunload")) which means multiple layers of code are running before the actual handler is run, so the text will probably framework text, I assume.
Plus, the usage of synchronous XMLHttpRequest is also usually not direct (new XMLHttpRequest()), it also usually goes through some framework/micro-framework ($.ajax({..., async: false})).

So that query would probably not yield much...

Good points about the levels of indirection that will obscure this. Alternatively, maybe HA has data regarding the use counters which were triggered on a page?

--
 
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f1124f4f-96f0-46da-854c-02602514448a%40chromium.org.

--
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.

Yoav Weiss

unread,
Jun 22, 2018, 11:59:48 AM6/22/18
to Rick Byers, igri...@google.com, n...@nicj.net, Patrick Meenan, blink-dev, PhistucK, Anne van Kesteren, Jason Chase, Jason Chase, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net
On Fri, Jun 22, 2018 at 9:35 AM Yoav Weiss <yo...@yoav.ws> wrote:
On Thu, Jun 21, 2018 at 7:50 PM Rick Byers <rby...@chromium.org> wrote:
Sorry, I should add that the API owners discussed this today. We agree that this case is pretty special:
  • sync XHR has been deprecated and actively discouraged for years
  • Any breakage is likely to be almost entirely analytics.
  • Any other sorts of breakage (eg. user data loss) would already be a problem - eg. for tab discarding - especially on mobile and CrOS, renderer crashes, etc. 
The other thing we discussed about developer outreach is that sync-xhr has been one of those (no longer practiced) "hopeful deprecations" where we generated a warning without any clear plan to actually do the removal. In general in those cases we want to upgrade the warning to a real deprecation (which gets a higher severity in devtools IIRC) that includes a milestone and link for more specific details. But Yoav points out that in this case there's probably nobody who will notice the warning since it happens only at unload time, and devtools clears the console on navigation. So it's not clear how much value there is in having an unload-specific warning.

Maybe there's a way for such warnings to survive navigations, and increase the chances of someone noticing them?
 
Shubie, any thoughts? I guess developers will still want to be able to debug their newly broken pages - probably set a breakpoint on the XHR to see what's going on... 

On Thu, Jun 21, 2018 at 1:44 PM Rick Byers <rby...@chromium.org> wrote:
I'm also convinced we should deprecate and remove this. To me the main question is what is the right amount of developer outreach to do before pulling the trigger. One option is to add UKM support and try reaching out to the owners of the scripts most often hitting it. But it's hard to say if that would provide good return on investment or not.

What outreach has been done already to clearly explain to developers why sync XHR is bad, and what the reasonable alternatives are?

I believe there was a fair bit of outreach over the years. There's this post from 2012. There's also this one from 2014. MDN has an entry on the subject, telling developers to move away from syncXHR and tackle those use-cases with Beacon. 

+Ilya Grigorik may know of more efforts on that front.

I think the general developer outreach in this case was done, for many years, and doubt more of it would make a dent.

One point where there may be room for some outreach to be made is with regards to Fetch keep alive as a syncXHR replacement for GET requests. (explain what the feature is, how it works, and mostly how to feature detect support for it, as it's not yet universally supported)

Kinuko Yasuda

unread,
Jun 24, 2018, 10:11:39 PM6/24/18
to Yoav Weiss, Rick Byers, Ilya Grigorik, n...@nicj.net, Patrick Meenan, blink-dev, PhistucK, Anne van Kesteren, Jason Chase, cha...@chromium.org, Jochen Eisinger, Mike West, Pavel Feldman, Shubhie Panicker, a...@andydavies.net
Just wanted to say that I'm fully supportive of this as well (like many others already expressed), while the current usage is concerning (ditto).

On Sat, Jun 23, 2018 at 12:59 AM Yoav Weiss <yo...@yoav.ws> wrote:
On Fri, Jun 22, 2018 at 9:35 AM Yoav Weiss <yo...@yoav.ws> wrote:
On Thu, Jun 21, 2018 at 7:50 PM Rick Byers <rby...@chromium.org> wrote:
Sorry, I should add that the API owners discussed this today. We agree that this case is pretty special:
  • sync XHR has been deprecated and actively discouraged for years
  • Any breakage is likely to be almost entirely analytics.
  • Any other sorts of breakage (eg. user data loss) would already be a problem - eg. for tab discarding - especially on mobile and CrOS, renderer crashes, etc. 
The other thing we discussed about developer outreach is that sync-xhr has been one of those (no longer practiced) "hopeful deprecations" where we generated a warning without any clear plan to actually do the removal. In general in those cases we want to upgrade the warning to a real deprecation (which gets a higher severity in devtools IIRC) that includes a milestone and link for more specific details. But Yoav points out that in this case there's probably nobody who will notice the warning since it happens only at unload time, and devtools clears the console on navigation. So it's not clear how much value there is in having an unload-specific warning.

Maybe there's a way for such warnings to survive navigations, and increase the chances of someone noticing them?
 
Shubie, any thoughts? I guess developers will still want to be able to debug their newly broken pages - probably set a breakpoint on the XHR to see what's going on... 

On Thu, Jun 21, 2018 at 1:44 PM Rick Byers <rby...@chromium.org> wrote:
I'm also convinced we should deprecate and remove this. To me the main question is what is the right amount of developer outreach to do before pulling the trigger. One option is to add UKM support and try reaching out to the owners of the scripts most often hitting it. But it's hard to say if that would provide good return on investment or not.

What outreach has been done already to clearly explain to developers why sync XHR is bad, and what the reasonable alternatives are?

I believe there was a fair bit of outreach over the years. There's this post from 2012. There's also this one from 2014. MDN has an entry on the subject, telling developers to move away from syncXHR and tackle those use-cases with Beacon. 

+Ilya Grigorik may know of more efforts on that front.

I think the general developer outreach in this case was done, for many years, and doubt more of it would make a dent.

One point where there may be room for some outreach to be made is with regards to Fetch keep alive as a syncXHR replacement for GET requests. (explain what the feature is, how it works, and mostly how to feature detect support for it, as it's not yet universally supported)

​Fetch keepalive is still relatively new while it must be strictly better than other options (when universally supported), I agree that we may be able to do some more advocate ​this feature.

raja...@gmail.com

unread,
Jun 24, 2018, 11:34:20 PM6/24/18
to blink-dev
We use syncXHR in our Javascript streaming product at Instart.
See the overview of the product here https://www.instartlogic.com/products/cloud-application-performance/javascript-streaming .

syncXHR downloads function not present in optimized js and being called, this can happen at any time during the lifecycle of the page, including page dismissal events.

Can this be enabled by opt-in by top-level frame?.

Chris Harrelson

unread,
Jun 24, 2018, 11:51:54 PM6/24/18
to raja...@gmail.com, blink-dev
On Sun, Jun 24, 2018 at 8:34 PM <raja...@gmail.com> wrote:
We use syncXHR in our Javascript streaming product at Instart.

Hi,

Thank you for sharing your use-case! On reading it, I'm not sure I understand why sync XHR is necessary and async does not suffice. Could you explain further why this is?
 
--
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.

raja...@gmail.com

unread,
Jun 25, 2018, 12:46:28 AM6/25/18
to blink-dev, raja...@gmail.com, chri...@chromium.org
Answer inline 
Hi,

Thank you for sharing your use-case! On reading it, I'm not sure I understand why sync XHR is necessary and async does not suffice. Could you explain further why this is?
 
We profile large JS files and the large un-used code is replaced with much smaller "stubs".
Sometimes our prediction goes wrong and we have to download the code of the function and execute it synchronously, so that optimization made by us is transparent to the applications.
This is done by "stubs" I mentioned earlier.
 
We are not application aware and do these changes transparently.
But application knows that we are doing this and it will be great if they can opt-in for sync XHR.

Yoav Weiss

unread,
Jun 25, 2018, 2:09:13 AM6/25/18
to raja...@gmail.com, blink-dev, chri...@chromium.org
Thanks for detailing your use-case.
IIUC, your usage of syncXHR is not restricted to page dismissal events, and is not highly likely to occur during those events. Is that correct?
If that's the case, it might be better to spin-off the general syncXHR discussion (which is interesting!) to a separate thread.

raja...@gmail.com

unread,
Jun 25, 2018, 2:24:30 AM6/25/18
to blink-dev, raja...@gmail.com, chri...@chromium.org
On Sunday, June 24, 2018 at 11:09:13 PM UTC-7, Yoav Weiss wrote:
Thanks for detailing your use-case.
IIUC, your usage of syncXHR is not restricted to page dismissal events, and is not highly likely to occur during those events. Is that correct?
If that's the case, it might be better to spin-off the general syncXHR discussion (which is interesting!) to a separate thread.

Yes. We are not restricted to the page dismissal events.

Few pages handlers during page dismissal and our case do not happen always. That makes it less likely.
But we won't able to guarantee safety to our customers.
 

Yoav Weiss

unread,
Jun 25, 2018, 3:10:55 AM6/25/18
to raja...@gmail.com, blink-dev, chri...@chromium.org
OK, so if I understand you correctly, this intent would impact you in case your customer has page dismissal handlers that you choose not to initially load, and then need to load them afterwards (using syncXHR).

Would that actually happen? If the customer has page dismissal code, that code is bound to run, so it would make sense for you to load it from the start, no?

--
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.

raja...@gmail.com

unread,
Jun 25, 2018, 3:25:52 AM6/25/18
to blink-dev, raja...@gmail.com, chri...@chromium.org


On Monday, June 25, 2018 at 12:10:55 AM UTC-7, Yoav Weiss wrote:
OK, so if I understand you correctly, this intent would impact you in case your customer has page dismissal handlers that you choose not to initially load, and then need to load them afterwards (using syncXHR).

Would that actually happen? If the customer has page dismissal code, that code is bound to run, so it would make sense for you to load it from the start, no?



Some conditional code in handlers can still cause some function to be not loaded.

function beforeunloadhandler() {
   if (cond1) {
      f1();
   }else {
      f2();
  }
}

In above case, we may load f1 if cond1 was always true during profile. Now during optimization phase if it because false, we are in trouble.

Yoav Weiss

unread,
Jun 25, 2018, 3:39:20 AM6/25/18
to raja...@gmail.com, blink-dev, chri...@chromium.org
OK. Do you have data whether this is something that actually happens?
Would it be possible for you to modify your behavior to always load code which may be called from dismissal events?
 

--
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.

raja...@gmail.com

unread,
Jun 25, 2018, 4:00:22 AM6/25/18
to blink-dev, raja...@gmail.com, chri...@chromium.org

OK. Do you have data whether this is something that actually happens?
Would it be possible for you to modify your behavior to always load code which may be called from dismissal events?

No. I do not have data. We do function level profiling. Deep inside the call stack, a function does not have a way to find what event triggered the call (do you know any?).
To load everything which can get called during dismissal events, we will need a transitive closure of all the function dependencies. 
 
Probability wise this event will be low due to factors mentioned earlier.
Static analysis can potentially reduce the cases.
But will reduce the guarantee provided by syncXHR.

Yoav Weiss

unread,
Jun 25, 2018, 4:28:00 AM6/25/18
to raja...@gmail.com, blink-dev, chri...@chromium.org
On Mon, Jun 25, 2018 at 10:00 AM <raja...@gmail.com> wrote:

OK. Do you have data whether this is something that actually happens?
Would it be possible for you to modify your behavior to always load code which may be called from dismissal events?

No. I do not have data. We do function level profiling. Deep inside the call stack, a function does not have a way to find what event triggered the call (do you know any?).
To load everything which can get called during dismissal events, we will need a transitive closure of all the function dependencies. 

Alternatively, you could turn on a flag on `window` indicating that the page is being dismissed so everything called from that point on should be included in the initial code.
 
 
Probability wise this event will be low due to factors mentioned earlier.
Static analysis can potentially reduce the cases.
But will reduce the guarantee provided by syncXHR.

 

--
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.

--
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.

Rick Byers

unread,
Jun 25, 2018, 4:12:34 PM6/25/18
to Yoav Weiss, raja...@gmail.com, blink-dev, Chris Harrelson
Thanks for the use case! That's definitely an interesting technology I've never heard come up in the sync XHR debates in the past.

Does your product have any memory from page load to page load? I.e. when it detects that the profiling failed, can it remember that (either on the client or server) for a future load to potentially avoid the blocking round-trip in the future? To me the idea of JS streaming which blocks script execution on the network seems much more defensible from a perf perspective if the system learns such that such blocking events tend to be extremely rare in practice (performance optimization is fundamentally a statistical problem).

The idea behind this change is that it's always a pretty bad experience to have navigating away from a page block for an undetermined time on the network. Given that beforeunload handlers already aren't reliable (are themselves statistical tools to help avoid data loss most of the time), if your system was already relying on some sort of dynamic feedback to minimize blocking, I wonder if in the rare case that a beforeunload handler hits some un-fetched code, it might actually be a better user experience to skip the unload prompt in that case (and remember what code needs to be pre-fetched for next time) rather than block the unload?

Rick

Rick Byers

unread,
Jun 25, 2018, 4:20:02 PM6/25/18
to Yoav Weiss, raja...@gmail.com, blink-dev, Chris Harrelson
By the way, you can also check window.event.type=="beforeunload" to see if you're currently within the context of a beforeunload handler. It's not perfect (Firefox support is being added I believe) so installing your own beforeunload listener and setting a flag as Yoav suggests may be better, but I can imagine that for cases like this it might actually be a pretty reasonable option.

Rajaram Gaunker (@zimbabao)

unread,
Jun 25, 2018, 6:54:07 PM6/25/18
to blink-dev, yo...@yoav.ws, raja...@gmail.com, chri...@chromium.org
On Monday, June 25, 2018 at 1:20:02 PM UTC-7, Rick Byers wrote:
By the way, you can also check window.event.type=="beforeunload" to see if you're currently within the context of a beforeunload handler. It's not perfect (Firefox support is being added I believe) so installing your own beforeunload listener and setting a flag as Yoav suggests may be better, but I can imagine that for cases like this it might actually be a pretty reasonable option.

Yes. I'm thinking about this, as you mentioned FF was the issue I faced, but we do not have. But that won't solve the issue.
Because I'll still miss the functions which did not get called during profiling.

PS: I'm still reading your previous mail :) .

Rajaram Gaunker (@zimbabao)

unread,
Jun 25, 2018, 6:54:15 PM6/25/18
to blink-dev, raja...@gmail.com, chri...@chromium.org
No. I do not have data. We do function level profiling. Deep inside the call stack, a function does not have a way to find what event triggered the call (do you know any?).
To load everything which can get called during dismissal events, we will need a transitive closure of all the function dependencies. 

Alternatively, you could turn on a flag on `window` indicating that the page is being dismissed so everything called from that point on should be included in the initial code.
 
We already include all the functions which gets called. I am only worried about functions which do not get called during profiling and gets called later.

Rajaram Gaunker (@zimbabao)

unread,
Jun 25, 2018, 10:28:33 PM6/25/18
to blink-dev, yo...@yoav.ws, raja...@gmail.com, chri...@chromium.org
Comments inline


On Monday, June 25, 2018 at 1:12:34 PM UTC-7, Rick Byers wrote:
Thanks for the use case! That's definitely an interesting technology I've never heard come up in the sync XHR debates in the past.

Does your product have any memory from page load to page load? I.e. when it detects that the profiling failed, can it remember that (either on the client or server) for a future load to potentially avoid the blocking round-trip in the future?
It does know what missed and fetched from the server.
 
To me the idea of JS streaming which blocks script execution on the network seems much more defensible from a perf perspective if the system learns such that such blocking events tend to be extremely rare in practice (performance optimization is fundamentally a statistical problem).
We do that and if it fetches happen more often. Reprofile is triggered and new optimized version is generated.
For same user fetches will be cached locally to use in subsequent page views.


The idea behind this change is that it's always a pretty bad experience to have navigating away from a page block for an undetermined time on the network. Given that beforeunload handlers already aren't reliable (are themselves statistical tools to help avoid data loss most of the time), if your system was already relying on some sort of dynamic feedback to minimize blocking, I wonder if in the rare case that a beforeunload handler hits some un-fetched code,
 
it might actually be a better user experience to skip the unload prompt in that case (and remember what code needs to be pre-fetched for next time) rather than block the unload?

Unload is not a special case for us. This can happen anywhere in the app.  But in principle, I agree that this is low probability event and dataloss will happen only when unload handlers is complex.

--rajaram 

Boris Zbarsky

unread,
Jun 27, 2018, 12:59:11 AM6/27/18
to Rick Byers, blink-dev, raja...@gmail.com
On 6/25/18 4:19 PM, Rick Byers wrote:
> By the way, you can also check window.event.type=="beforeunload"

Except you can have other events firing under there, depending on what
the beforeunload code does. So this is not a reliable way to detect
"running inside a beforeunload handler".

This is why window.event is basically a bad idea... ;)

-Boris

Alex Russell

unread,
Jun 28, 2018, 12:21:06 PM6/28/18
to blink-dev, rby...@chromium.org, raja...@gmail.com, Paul Kinlan
LGTM2 with comments:

As the usage is uncomfortably high, it'd be great if we had DevRel support to publish some documentation outlining what's happening and how transition to the alternatives (sendBeacon and fetch keepalive).

Regards

Rick Byers

unread,
Jun 28, 2018, 4:18:11 PM6/28/18
to Rajaram Gaunker, blink-dev, Yoav Weiss, Chris Harrelson
On Mon, Jun 25, 2018 at 10:28 PM Rajaram Gaunker (@zimbabao) <raja...@gmail.com> wrote:
Comments inline

On Monday, June 25, 2018 at 1:12:34 PM UTC-7, Rick Byers wrote:
Thanks for the use case! That's definitely an interesting technology I've never heard come up in the sync XHR debates in the past.

Does your product have any memory from page load to page load? I.e. when it detects that the profiling failed, can it remember that (either on the client or server) for a future load to potentially avoid the blocking round-trip in the future?
It does know what missed and fetched from the server.
 
To me the idea of JS streaming which blocks script execution on the network seems much more defensible from a perf perspective if the system learns such that such blocking events tend to be extremely rare in practice (performance optimization is fundamentally a statistical problem).
We do that and if it fetches happen more often. Reprofile is triggered and new optimized version is generated.
For same user fetches will be cached locally to use in subsequent page views.


The idea behind this change is that it's always a pretty bad experience to have navigating away from a page block for an undetermined time on the network. Given that beforeunload handlers already aren't reliable (are themselves statistical tools to help avoid data loss most of the time), if your system was already relying on some sort of dynamic feedback to minimize blocking, I wonder if in the rare case that a beforeunload handler hits some un-fetched code,
 
it might actually be a better user experience to skip the unload prompt in that case (and remember what code needs to be pre-fetched for next time) rather than block the unload?

Unload is not a special case for us. This can happen anywhere in the app.  But in principle, I agree that this is low probability event and dataloss will happen only when unload handlers is complex.

Ok, thanks for the details. I think we should give this change a try and see how much of a problem it poses for the rare cases like yours in practice. Please test in Chrome Dev/Beta channels once this is on before it reaches stable and follow-up here if it causes a real issue for you in practice (beyond the breakage which must already occur occasionally due to the 2s timeout limit). Worst case, I think it might be worth discussing a site-level opt-out (eg. via a reverse origin trial) to allow rare sites that really need this capability to continue to get it. But from the discussion we had at TPAC, it certainly sounds like other browser vendors intend to move in this direction as well.

Rick Byers

unread,
Jun 28, 2018, 4:23:18 PM6/28/18
to Alex Russell, Shubhie Panicker, blink-dev, Rajaram Gaunker, Paul Kinlan
The MDN page has a decent section describing the justification and alternatives to sync XHR, so (in addition to a mention in the deprecations blog post for the release), that indeed satisfies my concern around developer outreach. As always, let's keep our ears open for any significant breakage and be prepared to delay a milestone or two if needed (especially since we currently can't expect anyone to see the deprecation warning in devtools, or be subscribed to the DeprecationReports which are just shipping now in M69 as well).

Shubhie, do you have any plans to measure the UX improvement we get from this change? I forget, is unload event handling included in navigation timing metrics like FCP (seems like it ideally would be - since it's what the user sees), or do we have other UMA metrics that do include it? I wonder if it's worth doing a finch hold-out or something so we can quantify how much better this makes worst-case page loads? Such data could better help us evaluate any compat tradeoffs and support other browsers in trying to decide whether it's worth making this change. I'm also OK shipping this without finch and watching the UMA stats.

LGTM3

Rajaram Gaunker (@zimbabao)

unread,
Jun 28, 2018, 5:51:10 PM6/28/18
to blink-dev, raja...@gmail.com, yo...@yoav.ws, chri...@chromium.org
 
Unload is not a special case for us. This can happen anywhere in the app.  But in principle, I agree that this is low probability event and dataloss will happen only when unload handlers is complex.

Ok, thanks for the details. I think we should give this change a try and see how much of a problem it poses for the rare cases like yours in practice. Please test in Chrome Dev/Beta channels once this is on before it reaches stable and follow-up here if it causes a real issue for you in practice (beyond the breakage which must already occur occasionally due to the 2s timeout limit). Worst case, I think it might be worth discussing a site-level opt-out (eg. via a reverse origin trial) to allow rare sites that really need this capability to continue to get it. But from the discussion we had at TPAC, it certainly sounds like other browser vendors intend to move in this direction as well.
 
Rick,  
Yes. We can try and gather some data.
Reverse original trial is what will solve our problem. Is that discussion happening on some online forum?.

Shubhie Panicker

unread,
Jun 29, 2018, 6:39:50 PM6/29/18
to Rick Byers, Jansma, Nic, Yoav Weiss, Alex Russell, blink-dev, Rajaram Gaunker, Paul Kinlan
Thanks.

On Thu, Jun 28, 2018 at 1:23 PM, Rick Byers <rby...@chromium.org> wrote:
The MDN page has a decent section describing the justification and alternatives to sync XHR, so (in addition to a mention in the deprecations blog post for the release), that indeed satisfies my concern around developer outreach. As always, let's keep our ears open for any significant breakage and be prepared to delay a milestone or two if needed (especially since we currently can't expect anyone to see the deprecation warning in devtools, or be subscribed to the DeprecationReports which are just shipping now in M69 as well).

Shubhie, do you have any plans to measure the UX improvement we get from this change? I forget, is unload event handling included in navigation timing metrics like FCP (seems like it ideally would be - since it's what the user sees), or do we have other UMA metrics that do include it? I wonder if it's worth doing a finch hold-out or something so we can quantify how much better this makes worst-case page loads? Such data could better help us evaluate any compat tradeoffs and support other browsers in trying to decide whether it's worth making this change. I'm also OK shipping this without finch and watching the UMA stats.
 

Navigation timing includes unload, but not beforeunload, there will be larger wins for the latter as beforeunload has an order of magnitude more sync xhrs compared to unload.  
I expect UX wins, especially in combination with changing the timeout to 500ms, however these will be at high percentiles and likely not easy to observe via UMA(?). Site analytics (with 3P) would likely be a better way to gather data here. 
Nic, Yoav -- any thoughts here?

Separately, this change will make it more palatable to proactively run beforeunload handler before freezing a page.
Shipping without Finch would certainly be much easier (I'd initially suggested more for kill switch rather than metrics), so I'd prefer that since you are okay with it :)

Finally -- does changing the page dismissal timeout need a blink-dev FYI or I2S? The timeout change doesn't have any impact upto 99.9% ile as mentioned in the bug.

Shubhie Panicker

unread,
Apr 1, 2019, 7:53:47 PM4/1/19
to Rick Byers, Jansma, Nic, Yoav Weiss, Alex Russell, blink-dev, Rajaram Gaunker, Paul Kinlan, Katie Dillon
To close the loop here: this change has been in experiment for last several months. 
We didn't find any reports of problems and have seen a 7% improvement (i.e. reduction) in FCP at 75th percentile, a clear UX win.
It is being turned on by default in M75 by kdillon.


yotams...@gmail.com

unread,
Jun 25, 2019, 12:02:41 PM6/25/19
to blink-dev
Hi,

Is there a way for developers to test their sites with this change, e.g. a flag that can be switched on?

Thanks,
Yotam

Ian Clelland

unread,
Jun 25, 2019, 12:57:50 PM6/25/19
to yotams...@gmail.com, blink-dev
You should be able to run Chrome with the command-line flag:

--enable-features="ForbidSyncXHRInPageDismissal"

It's also available in the browser at chrome://flags/#enable-forbid-sync-xhr-in-page-dismissal

Ian


--
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.

tobias....@gmail.com

unread,
Sep 5, 2019, 9:17:05 PM9/5/19
to blink-dev, yotams...@gmail.com
Hello everybody, please tell me how to do this without sync xhr:

- The user changes something in a textarea
- The contents of the textarea is auto saved to the server.
- The user just changed the contents of the textarea and reloads the page
- The browser is not fast enough to send the change asynchronously.
- How can i make sure that the newly loaded page shows the newest content without sync xhr

Is SendBeacon delivered to the server before the reload request?

thorsten...@sap.com

unread,
Sep 9, 2019, 12:26:13 PM9/9/19
to blink-dev, yotams...@gmail.com

Hi,

 

To my opinion/experience there is no solution for your case. It is the nature of a async call that I might be later than the refresh event.

 

Even worse it depends on the event in which a sendBeacon is created if it will be sent out or not. We would like to use sendBeacon during unload event but Google confirmed it will not sent out in a reliable way. Therefore sendBeacon can’t be used during page dismissal event. Maybe you can try it in the visisbilityChange event (will not solve the async issue).

Of course you could send immediately a second request to check for updates hoping the user doesn’t change the text in the meantime.

 

To overcome the situation we would need a kind of refresh event in which we still can use sync XHR. It will not break the user experience as it is still the same page. At least the argument of a “evil” page is not valid anymore.

 

Thorsten

blaise...@gmail.com

unread,
Jun 16, 2020, 12:00:00 PM6/16/20