Contact emails
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:
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)
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.
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
--
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.
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/CAK7ODi--QbHmWAbBE0E2jyo6fHQNQgWs9zN_j8PTCCR_d6%3Dgag%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.
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.
--
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.
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.
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
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.
☆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.
--
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.
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.)
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
https://annevankesteren.nl/
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
☆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.
--
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/1de3a04f-644f-4e07-b556-ab71c5797249%40chromium.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?
☆PhistucK
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/CALjhuic4z73JmjZ5pJHaSdWhqkcAcThujw5hyzVd3nvxN%2BREUw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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+...@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.
--
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/1de3a04f-644f-4e07-b556-ab71c5797249%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.
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.
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...
--
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.
Sorry, I should add that the API owners discussed this today. We agree that this case is pretty special: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.
- 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.
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?
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?).RickOn 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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9xDMaz6xdFtuWH93DXEYZaWPSNJB4pt7jLxJnLgq4YVw%40mail.gmail.com.
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: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.
- 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.
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.
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: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.
- 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.
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)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh47W0wW5wgFK%2BUwQnq%3DtKNpLq-csgWB0agFNxNxcsuUg%40mail.gmail.com.
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 .
--
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/86d04946-8c75-4e0c-9e5b-3fb2293f705c%40chromium.org.
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca622fd0-4222-4a94-84a2-d54c5de0a2c3%40chromium.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.
--
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/a80c9bf9-0874-4d25-8b5c-94958b2c106a%40chromium.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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/90129429-a73d-49fb-a6b7-34b2c67201f8%40chromium.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?
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.--
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/90129429-a73d-49fb-a6b7-34b2c67201f8%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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6dd6b9b3-0aa8-4022-8b17-5146f6d302cb%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjg9FQVVOmr_w8P5-h6%2BA-dQuUMXrjaGn4aetsXtkQ_dg%40mail.gmail.com.
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.
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.
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?
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/acc3ffa0-6312-4784-b3ec-7bfaae91ede5%40chromium.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.
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.
--
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/72d20189-f1af-485d-b804-352a87dd8403%40chromium.org.
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
On Tue, Jun 19, 2018 at 5:58 AM, PhistucK <phis...@gmail.com> wrote: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.)