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
Tests that were using `evaluateJSAsync` are updated, either by using the new command,
or by awaiting for the `evaluationResult` event.
A couple chrome tests were moved to devtools/shared/commands/js/tests/ and turned
into browser tests, and some of them were completely removed as we tested the
features in mochitests as well.
Differential Revision: https://phabricator.services.mozilla.com/D116248
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
The reported error happens because `.parentNode` can be a document,
which doesn't implement the Element interface. Using `.parentElement`
solves this issue.
And while I'm fixing this: move the logic behind the menu ID check, so
that the logic is not unnecessarily run for non-pageAction contextmenus.
Differential Revision: https://phabricator.services.mozilla.com/D116138
This is a bit peculiar. When we show the bookmarks toolbar, we create its children. When it then
gets hidden, they do not get removed. When we then re-enable the bookmarks toolbar, we call
`rebuild` on the next tick (because of the `await` in `init` in PlacesToolbarHelper), which
synchronously removes all the children of the toolbar, and then rebuilds the places node. It
does that async because it avoids doing synchronous layout flushes.
This breaks in the test - and the closer you put the "show the bookmarks toolbar" code to
the code that tries to open the context menu, the more reliably it breaks, because we try
to show the context menu right after we synchronously remove everything, and before we've
(asynchronously) put content back.
To avoid the raciness here, we wait for the custom event in the places toolbar to indicate
we're done building it.
Differential Revision: https://phabricator.services.mozilla.com/D116118
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
