gNotificationBox doesn't go there anymore (it goes inside the toolbox),
so we have really no use for that.
Simplify how the devtools theme is set on the browser, so that it is set
on the root.
Differential Revision: https://phabricator.services.mozilla.com/D220769
Hopefully this comment and marker will make it so that we don't have to
chase any ghosts in rr in the future to understand what dirtyFrame is
doing!
Differential Revision: https://phabricator.services.mozilla.com/D215794
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
If there is at least one record for expected I/O, but all of them have
`ignoreIfUnused: true`, and no I/O is reported, then the tests should
succeed (they are all unused and thus ignored). There's a check which
expects to see I/O markers in that case, so this patch conditionally
skips it. (Also: fix some pre-existing typos pointed out in review.)
Differential Revision: https://phabricator.services.mozilla.com/D212632
In bug 1804140, we shipped SHIP everywhere on desktop. Unfortunately, we
never removed the now-dead code from SessionStore.
This patch removes the easy to identify SessionStore code for non-SHIP,
now that it is a fully unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D205479
In bug 1804140, we shipped SHIP everywhere on desktop. Unfortunately, we
never removed the now-dead code from SessionStore.
This patch removes the easy to identify SessionStore code for non-SHIP,
now that it is a fully unsupported configuration.
Differential Revision: https://phabricator.services.mozilla.com/D205479
When I rewrote nsMenuPopupFrame, I made sure percentage sizes worked so
that we could do stuff like this.
This removes some complex code, and improves the behavior on platforms
where screen sizes might not be 100% reliable.
Differential Revision: https://phabricator.services.mozilla.com/D204754
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
* Flip the component pref to true by default for nightly builds only
* Move the pref check and initialization to a startup idle task
* And be a bit smarter about when we get and disable the addon
* Fix a bug where we try to communicate with the overlay after the window actor is destroyed when
the component pref gets flipped off during use
Differential Revision: https://phabricator.services.mozilla.com/D196888
This moves handling of the preferences and log value setting into ConsoleInstance, which is where the preferences
are received. It also makes ConsoleInstance add a listener on the preferences service so that updates are triggered.
The functionality is already covered by dom/console/tests/test_jsm.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D199657
If this test fails (`shouldPass` is false at the end), and
`MOZ_UPLOAD_DIR` is unset (typically the case when running locally), the
test raises an exception about using `PathUtils.join` with an empty path.
This is harmless (the test was already failing) but slightly confusing.
Differential Revision: https://phabricator.services.mozilla.com/D199166
See also bug 1840515. Normally a content process will open the omnijar
files during startup, but when the fork server is used, this is done
once in the fork server and then inherited by child processes.
Differential Revision: https://phabricator.services.mozilla.com/D199165
If this test fails (`shouldPass` is false at the end), and
`MOZ_UPLOAD_DIR` is unset (typically the case when running locally), the
test raises an exception about using `PathUtils.join` with an empty path.
This is harmless (the test was already failing) but slightly confusing.
Differential Revision: https://phabricator.services.mozilla.com/D199166
See also bug 1840515. Normally a content process will open the omnijar
files during startup, but when the fork server is used, this is done
once in the fork server and then inherited by child processes.
Differential Revision: https://phabricator.services.mozilla.com/D199165
