You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
I experimented with moving updating the window name after the browser has navigated to the new URL (as shown below) and (while it worked fine for most tests) it did cause some test (from the angular/angular.js repo) to fail. I am not sure whether there is a more reliable way to execute some JS code after the new page has been loaded but before any JS (including AngularJS) has been executed.
We discussed this a bit more yesterday and there doesn't seem to be a great way to fix this (i.e. one that is straight-forward and does not involve the risk of breaking other usecases) 🤔
For now, using the work-around mentioned in #17117 (comment) should be sufficient. We might re-visit this if something changes in the future (for example, if the work-around stops being available).
Yeah, I don't know exactly when we'll remove the preference and we at Firefox are happy to collaborate on making that as painless as possible for everyone involved (please chime in at https://bugzilla.mozilla.org/show_bug.cgi?id=1704469), but this window.name dependency was already breaking Safari and will soon also break Chrome so it's high time to migrate to something new.
An alternative (and likely worse) option is to keep on using older version of Firefox in these e2e tests.
We currently can't think of a permanent solution to this problem that wouldn't require modification of the test suite and/or the AngularJS application bootstrap code.
Activity
zeha commentedon Mar 2, 2021
A temporary workaround for Protractor with FirefoxDriver appears to be:
capabilities: { browserName: 'firefox', 'moz:firefoxOptions': { + prefs: {'privacy.window.name.update.enabled': false} } },Mozilla bug report for enabling this feature: https://bugzilla.mozilla.org/show_bug.cgi?id=1685089
Note that it says:
"File follow-up bug for removal of privacy.window.name.update.enabled once it's been flipped for a couple of releases."
gkalpak commentedon Mar 3, 2021
Thx for reporting this, @zeha.
We need to do some investigation to determine what can/should be done about this (esp. given the current LTS status of the project).
In the meantime, I very briefly looked at the Protractor source code and wanted to capture my findings (for future reference).
Currently, protractor adds
NG_DEFER_BOOTSTRAP!to the window name right before setting thewindow.locationto the new URL (source code):I experimented with moving updating the window name after the browser has navigated to the new URL (as shown below) and (while it worked fine for most tests) it did cause some test (from the
angular/angular.jsrepo) to fail. I am not sure whether there is a more reliable way to execute some JS code after the new page has been loaded but before any JS (including AngularJS) has been executed.Modified protractor/lib/browser.ts:
.then(() => { - // Set defer label and navigate + // Navigate return this.executeScriptWithDescription( - 'window.name = "' + DEFER_LABEL + '" + window.name;' + - 'window.location.replace("' + destination + '");', + 'window.location.replace("' + destination + '");', msg('reset url')); }) .then(() => { // We need to make sure the new url has loaded before // we try to execute any asynchronous scripts. return this.driver.wait(() => { return this.executeScriptWithDescription('return window.location.href;', msg('get url')) .then( (url: any) => { return url !== this.resetUrl; }, (err: IError) => { if (err.code == 13 || err.name === 'JavascriptError') { // Ignore the error, and continue trying. This is // because IE driver sometimes (~1%) will throw an // unknown error from this execution. See // https://github.com/angular/protractor/issues/841 // This shouldn't mask errors because it will fail // with the timeout anyway. return false; } else { throw err; } }); }, timeout, 'waiting for page to load for ' + timeout + 'ms'); }) + .then(() => { + // Set defer label + return this.executeScriptWithDescription( + 'window.name = "' + DEFER_LABEL + '" + window.name;', + msg('set defer label')); + })gkalpak commentedon Mar 23, 2021
We discussed this a bit more yesterday and there doesn't seem to be a great way to fix this (i.e. one that is straight-forward and does not involve the risk of breaking other usecases) 🤔
For now, using the work-around mentioned in #17117 (comment) should be sufficient. We might re-visit this if something changes in the future (for example, if the work-around stops being available).
I'll keep the issue open for tracking purposes.
zeha commentedon Mar 25, 2021
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1700931 for Firefox (Marionette).
Splaktar commentedon Apr 3, 2021
I wanted to find a Protractor issue for this, since it's more of an issue there than with AngularJS itself. Related issues
window.nameusage here: Safari Technology Preview can't find Angular 1 protractor#4004window.namesetting either: Protractor doesn't support angular synchronization on iOS protractor#2840Splaktar commentedon Apr 3, 2021
From the Firefox bug tracker:
So it looks like that work-around may only work for another couple of months.
annevk commentedon Apr 12, 2021
Yeah, I don't know exactly when we'll remove the preference and we at Firefox are happy to collaborate on making that as painless as possible for everyone involved (please chime in at https://bugzilla.mozilla.org/show_bug.cgi?id=1704469), but this
window.namedependency was already breaking Safari and will soon also break Chrome so it's high time to migrate to something new.mgol commentedon Apr 12, 2021
@annevk Thanks for the update.
Is https://bugs.chromium.org/p/chromium/issues/detail?id=1090128 a relevant Chromium issue so that we have all the relevant references?EDIT: I found Chromium's Intent to Ship in a separate issue: https://groups.google.com/a/chromium.org/g/blink-dev/c/86VeIi5sZzc/m/fPOAbuRHCAAJ
Splaktar commentedon Jun 7, 2021
Chromium is getting closer to shipping this in a beta:
https://groups.google.com/a/chromium.org/g/blink-dev/c/86VeIi5sZzc/m/CVJadvpqAQAJ
Do we have any plans for working around this?
So läuft es
IgorMinar commentedon Jul 29, 2021
Just a quick not that the current workaround for this issue is to disable the new privacy firefox feature via webdriver configuration:
An alternative (and likely worse) option is to keep on using older version of Firefox in these e2e tests.
We currently can't think of a permanent solution to this problem that wouldn't require modification of the test suite and/or the AngularJS application bootstrap code.