browser_ext_incognito_views.js is failing intermittently in optimized builds due to a race between
a browserAction popup being opened as part of the test task and the related window being closed at the
end of the same test task.
This patch moves the responsability of closing the browserAction popup and the window to the chrome-privileged
part of the test, and makes sure that we are explicitly waiting for the browserAction popup to be opened and
loaded and then completely closed before removing the related Firefox window.
Differential Revision: https://phabricator.services.mozilla.com/D124047
Also fix to actually call the correct requestLongerTimeout() method,
and shorten the timeout by half to see if That would be enough.
Differential Revision: https://phabricator.services.mozilla.com/D122052
Also fix to actually call the correct requestLongerTimeout() method,
and shorten the timeout by half to see if That would be enough.
Differential Revision: https://phabricator.services.mozilla.com/D122052
When an extension does call tabs.discard earlier in the tab creation (e.g. when the extension calls
tabs.discard from inside a tabs.onUpdated listener), when the tab is activated (e.g. by selecting
the non-currently active lazified tab) Firefox is expected to restore it to the webpage url that
was being loaded.
This was already working as expected on non-private tabs, where the expected tab url was stored
in the TabStateCache as the userTypedValue (which seems to be part of a fix also related to
tabs.discard and landed in Firefox 62 from Bug 1422588).
It didn't work yet for private tabs, because for a private tab we are storing `{isPrivate: true}`
into the TabStateCache as soon as we are creating the tab, and so the change to SessionStore
resetBrowserToLazyState applied from Bug 1422588 had no effect for the private tabs
(due to the check for an existing cached entry for the same tab).
This patch applies a small change to ensure we are caching the userTypedValue set on the browser
element if one is not already stored in the TabStateCache, and adds an additional test case
to browser_ext_tabs_discarded.js which cover the expected behavior (and fails as expected
without a fix for the underlying issue).
Differential Revision: https://phabricator.services.mozilla.com/D122370
Since this is testing undesired but previously consistent behavior, I'm just
relaxing the (sometimes) expected results with Fission SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D120798
The Netmonitor used to call the WebConsoleFront `getString` method to get the full
text of a long string. This could make some test to fail with Fission and target
switching.
Since the webconsole actor is not even involved in the webconsole method, there's
no reason to keep using it. A similar function is added into a util file; the only
difference is that it doesn't cache the front it creates, which does not matter
as the netmonitor only calls this once and then put the full text in its redux
store.
This allows us to re-enable `browser_ext_devtools_network.js` with Fission.
Differential Revision: https://phabricator.services.mozilla.com/D120333
The helper is already calling `gDevTools.closeToolboxForTab`, which does take care
of destroying its associated descriptor.
This makes some extension test to pass with server side target switching enabled.
Differential Revision: https://phabricator.services.mozilla.com/D120332
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
When we duplicate a tab, we don't need to have about:blank load in it, because
we are going to use restore mechanism to copy data into the new tab. If we
don't skip the superfluous load, the restoring process might race with the
loading of about:blank, and sometimes we might try to destroy the
WindowGlobalChild actor just as SessionStore is trying to restore docshell
capabilities for that tab resulting in a rejected promise in _restoreHistory
and `_restoreHistoryComplete` not getting called.
Differential Revision: https://phabricator.services.mozilla.com/D119313
I was unable to reproduce this locally, but looking to the logs from the failures tracked by this bug
I did notice this logged error which suspiciously point in the direction of a race between registering
a browser.runtime.onMessage listener and sending a message to that listner from the content script "script.js":
```
Console message: [JavaScript Error: "Error: Could not establish connection. Receiving end does not exist."
{file: "moz-extension://f0d0d3ec-6815-4d78-aa83-3516814353a2/script.js" line: 2}]
```
This patch just change the order of those two promise, making sure that the browser.runtime.onMessage will be registered by the time the content script is going to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D119175
I was unable to reproduce this locally, but looking to the logs from the failures tracked by this bug
I did notice this logged error which suspiciously point in the direction of a race between registering
a browser.runtime.onMessage listener and sending a message to that listner from the content script "script.js":
```
Console message: [JavaScript Error: "Error: Could not establish connection. Receiving end does not exist."
{file: "moz-extension://f0d0d3ec-6815-4d78-aa83-3516814353a2/script.js" line: 2}]
```
This patch just change the order of those two promise, making sure that the browser.runtime.onMessage will be registered by the time the content script is going to be executed.
Differential Revision: https://phabricator.services.mozilla.com/D119175
