I have run into this issue with Firefox, angular-js and protractor: https://docs.angularjs.org/guide/bootstrap "If window.name contains prefix NG_DEFER_BOOTSTRAP! when angular.bootstrap <https://docs.angularjs.org/api/ng/function/angular.bootstrap> is called, the bootstrap process will be paused until angular.resumeBootstrap() is called."
It makes use of the ability to pass window.name and broke with Firefox's implementation of clearing this. I had to set 'privacy.window.name.update.enabled=false' to restore functionality. Hopefully the feature can continue to be disabled for testing purposes. On Tuesday, 15 June 2021 at 12:53:42 am UTC+10 [email protected] wrote: > Thanks for the review. I will proceed with Mike's suggestion. > > On Thu, Jun 10, 2021 at 3:49 PM Yoav Weiss <[email protected]> wrote: > >> LGTM3 >> >> On Thu, Jun 10, 2021 at 9:16 PM Chris Harrelson <[email protected]> >> wrote: >> >>> LGTM2 >>> >>> On Thu, Jun 10, 2021 at 12:15 PM Mike West <[email protected]> wrote: >>> >>>> LGTM1. This is the right direction for the platform, and following >>>> Firefox's and Safari's good example gives me confidence that the 0.6% >>>> number above is more benign than it looks. >>>> >>>> That said, two things seem prudent: >>>> >>>> 1. Given the usage, it's probably a good idea to roll this out via >>>> Finch, as you suggest. I'm comfortable leaving the rollout schedule to >>>> y'all, as long as we have the ability to turn it off if our hopes about >>>> compatibility turn out to be unfounded. >>>> >>>> 2. Likewise, we often discover that our enterprise users are >>>> unexpectedly exercising portions of the platform we'd like to remove. It >>>> would be ideal to add a policy that allows them to carve themselves out >>>> from this change for a limited time while they adjust their applications. >>>> >>>> Thanks! >>>> >>>> -mike >>>> >>>> On Friday, June 4, 2021 at 12:24:54 AM UTC+2 Shuran Huang wrote: >>>> >>>>> Tried to calculate feature hit rate with origin matching "*.google.*", >>>>> which contributes ~27% of all the feature hits (other sites are below >>>>> 3%). >>>>> Note that the GAPI script could be loaded on other sites that do not set >>>>> the window.name field, which can contribute to the feature hit but >>>>> does not have compatibility issues if we enable the feature. >>>>> >>>>> I also checked the latest data from Chrome Status Platform, the >>>>> feature popularity drops to 0.4%. Could it be a reaction to the Firefox >>>>> change? According to the response received from Firefox, they haven't >>>>> observed any breakage so far. If enabling this feature for the binary is >>>>> considered risky, we can also go for a Finch rollout. >>>>> >>>>> On Wed, May 19, 2021 at 5:20 AM Yoav Weiss <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, May 18, 2021 at 6:58 PM Shuran Huang <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Based on the UKM collected from beta M91, this feature is triggered >>>>>>> the most on https://www.google.com, way higher than other origins. >>>>>>> >>>>>> >>>>>> Fun! >>>>>> >>>>>> If we exclude google.com, what is the %age of visits that are >>>>>> hitting this? >>>>>> >>>>>> >>>>>>> >>>>>>> To figure out its compatibility impact for google, I've reached out >>>>>>> to GAPI team (GAPI is Google’s client library for browser-side >>>>>>> JavaScript, >>>>>>> which calls the window.name property, and is loaded when browsing >>>>>>> www.google.com) , as well as Web Testing team to find whether >>>>>>> enabling this feature would cause issues for GAPI or any google3 web >>>>>>> test >>>>>>> to fail (on chrome-linux). The test results showed that this feature >>>>>>> shouldn't be a problem for GAPI, and does not have any impact for >>>>>>> google3 >>>>>>> web tests. >>>>>>> >>>>>>> I also haven't heard back from Firefox for any compatibility issues >>>>>>> after shipping this feature. So I wonder if we can enable the feature >>>>>>> for >>>>>>> the binary and be prepared to revert it back if it causes any breakage >>>>>>> in >>>>>>> beta. Also want to mention that this feature can be disabled in >>>>>>> Chrome://flags with >>>>>>> clear-cross-browsing-context-group-main-frame-name. >>>>>>> >>>>>>> On Fri, May 7, 2021 at 2:05 PM Shuran Huang <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> The UKM UseCounter was released in beta yesterday. I am waiting to >>>>>>>> collect data from it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shuran >>>>>>>> >>>>>>>> On Thu, May 6, 2021 at 2:20 PM Mike West <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ping. Were you able to make progress with regard to tracking down >>>>>>>>> usage anecdotes to better understand possible compat issues? >>>>>>>>> >>>>>>>>> -mike >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Apr 23, 2021 at 8:39 PM Shuran Huang <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Mike, >>>>>>>>>> >>>>>>>>>> I am still trying to collect data to clarify the impact. >>>>>>>>>> Unfortunately HTTP Archive does not have the data, so UKM was >>>>>>>>>> recently >>>>>>>>>> added for it. Meanwhile, I am tracing down the window.name >>>>>>>>>> usage in Google's client library, which can contribute a lot to the >>>>>>>>>> ratio. >>>>>>>>>> >>>>>>>>>> It's worth mentioning that 0.6% is an upper bound ratio, i.e. >>>>>>>>>> whenever a site reads the non-null-but-should-be-null window.name >>>>>>>>>> after a cross-site cross-BCG navigation, which may not really be >>>>>>>>>> indicative >>>>>>>>>> of the compatibility problem. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shuran >>>>>>>>>> >>>>>>>>>> On Thu, Apr 22, 2021 at 3:10 PM Mike West <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Friendly ping on this. Were you able to clarify the compat >>>>>>>>>>> impact of the 0.6% usage number? >>>>>>>>>>> >>>>>>>>>>> -mike >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 7, 2021 at 9:49 PM Shuran Huang <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Yoav, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the feedback! I spent some time on your questions >>>>>>>>>>>> and answered them inline. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 1, 2021 at 4:44 AM Yoav Weiss <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> This seems like a privacy-positive change, so thanks for >>>>>>>>>>>>> working on this! >>>>>>>>>>>>> >>>>>>>>>>>>> On Wednesday, March 31, 2021 at 10:36:11 PM UTC+2 Shuran Huang >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>> >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>> >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specification >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://html.spec.whatwg.org/multipage/browsing-the-web.html#resetBCName >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary >>>>>>>>>>>>>> >>>>>>>>>>>>>> The value of the window.name property is currently preserved >>>>>>>>>>>>>> throughout the lifetime of a tab, even with navigation that >>>>>>>>>>>>>> switches >>>>>>>>>>>>>> browsing context groups, such as when a user initiates a >>>>>>>>>>>>>> navigation from >>>>>>>>>>>>>> the URL bar or some cross-site navigation by clicking on a >>>>>>>>>>>>>> hyperlink on the >>>>>>>>>>>>>> current page. This can leak information and potentially be used >>>>>>>>>>>>>> as a tracking vector >>>>>>>>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=444222>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To address this, we want to clear the window.name when the >>>>>>>>>>>>>> navigation is cross-site and switches browsing context groups, >>>>>>>>>>>>>> which aligns >>>>>>>>>>>>>> with the requirement by the spec. >>>>>>>>>>>>>> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#resetBCName> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The implementation is behind a flag. This should be a low risk >>>>>>>>>>>>>> change since >>>>>>>>>>>>>> looking up a browsing context by name ( >>>>>>>>>>>>>> https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name) >>>>>>>>>>>>>> >>>>>>>>>>>>>> does not work where the documents’ origins are different and in >>>>>>>>>>>>>> different >>>>>>>>>>>>>> browsing context groups, so the name isn't actually useful. User >>>>>>>>>>>>>> counter is at around 0.006%: >>>>>>>>>>>>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/3353 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hmm, did you mean 0.6%? >>>>>>>>>>>>> Usage seems rather high for such an esoteric bit of >>>>>>>>>>>>> functionality. Did you do some more digging as to how this is >>>>>>>>>>>>> being used >>>>>>>>>>>>> and by whom? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> You are right that it should be 0.6%, sorry for the confusion. >>>>>>>>>>>> I am looking into HTTP Archive and see what sites are using this >>>>>>>>>>>> feature. >>>>>>>>>>>> Will provide more detail. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> There are two other related changes that are required by spec >>>>>>>>>>>>>> but not covered in this intent, and are addressed by separate >>>>>>>>>>>>>> bugs: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> Restoring browsing context names on navigation (as >>>>>>>>>>>>>> defined in >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-traversal): >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://crbug.com/1141017 >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> Clearing window.name for cross-site navigations when the >>>>>>>>>>>>>> browsing context group is not replaced: >>>>>>>>>>>>>> https://crbug.com/706350. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>> >>>>>>>>>>>>>> UI>Browser>Navigation >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation> >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>> >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not applicable >>>>>>>>>>>>>> >>>>>>>>>>>>>> Risks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>> >>>>>>>>>>>>>> This change will affect where window.name is used for >>>>>>>>>>>>>> cross-domain communication, but we already have >>>>>>>>>>>>>> window.postMessage() as >>>>>>>>>>>>>> the recommended mechanism for the purpose. Other browsers are >>>>>>>>>>>>>> mitigating >>>>>>>>>>>>>> this usage as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Firefox: Shipped >>>>>>>>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1685089> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Seems like they've hit some compatibility issues related to >>>>>>>>>>>>> WebDriver: >>>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1685089#c8 >>>>>>>>>>>>> Have we looked into that? Would we suffer from similar issues? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Thanks for catching it. It looks to me the issue lies in >>>>>>>>>>>> Protractor, a testing tool used by FirefoxDriver. Protractor uses >>>>>>>>>>>> the >>>>>>>>>>>> "Deferred Bootstrap" feature provided by AngularJS, which mangles >>>>>>>>>>>> with the >>>>>>>>>>>> window.name property, to perform tests. This has been broken >>>>>>>>>>>> on Safari for 4 years now: >>>>>>>>>>>> https://github.com/angular/protractor/issues/4004. Based on >>>>>>>>>>>> the issue comments >>>>>>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1700931#c6>, it's >>>>>>>>>>>> mostly a wontfix on the FireFox side. I also feel it makes sense >>>>>>>>>>>> for the >>>>>>>>>>>> Protractor team to fix this issue. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Safari: Shipped >>>>>>>>>>>>>> <https://trac.webkit.org/changeset/209076/webkit> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Web developers: No signals >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>> ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>> https://wpt.fyi/results/html/browsers/windows/clear-window-name.https.html?label=master&label=experimental&aligned >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://crbug.com/1090128 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.chromestatus.com/feature/5962406356320256 >>>>>>>>>>>>>> >>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>> <https://www.chromestatus.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 [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ3-5L2c9wXMJ841984sZRHQMOaafX9NbJo6JKSdaO4a2Yg2pw%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ3-5L2c9wXMJ841984sZRHQMOaafX9NbJo6JKSdaO4a2Yg2pw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55bcc3c0-3fb3-4bc4-a728-9d4270797414n%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/55bcc3c0-3fb3-4bc4-a728-9d4270797414n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7342c77f-de7f-4f65-82f6-3a8fdccd4b4cn%40chromium.org.
