When background tabs crash, they were being replaced by about:blank tab
hosted in parent process.
Now that there is a mechanism for lazily creating browsers, discarding the
crashed background browser until they are selected is a cheaper operation
(compared to creating about:blank).
Certain test cases were also updated to take into account the new scenario.
--HG--
extra : rebase_source : ab2c6c7b2faf5710ebfc52259632fbcd6d67b5fa
extra : amend_source : 0e15fb0f4818273daa3438d4e297f42558c1fc55
This patch adds data collection for 6 different data points:
- number of live bookmarks the user has
- number of times the user subscribes to a feed
- number of times we attempt to open feed preview
- number of times the user opens a feed popup in the UI
- number of times the user opens an entry from a feed popup in the UI.
MozReview-Commit-ID: DG9JDFXCjai
--HG--
rename : browser/components/feeds/test/valid-feed.xml => browser/components/feeds/test/browser/valid-feed.xml
extra : rebase_source : 9f3df4ca19eec0750092deb9066634a388ec59f7
This is part of the work to remove XUL overlays. The overlay was originally
created to help startup performance, but inlining the overlay seems to
no longer have detrimental effects to performance and is more straightforward.
MozReview-Commit-ID: 7sfVel6qvgv
--HG--
extra : rebase_source : b6311cf1fb98851b4f4203c314ae9ecc8160d766
This also updates the AppMenu mozscreenshots module to work with the Photon main menu.
MozReview-Commit-ID: FciQH815F95
--HG--
extra : rebase_source : 5c129b0d4aa824bbe899066f2bb197106d1c0408
This stops redundant ViewHiding and late ViewShown events from being dispatched when the panel is closed during a ViewShowing event or a transition, and stops dispatching ViewHiding events when a view becomes invisible but is still open.
The panelMultiView property on "panelview" nodes is now set to null when the view is closed, indicating that the view can be immediately reused in a different panel. The Places view had to be updated so it doesn't rely on this property during the PanelMultiViewHidden event.
MozReview-Commit-ID: B1yU6si3eD3
--HG--
extra : rebase_source : 440ddc3eabcbe9d0f02a172f8adf047c66ca53ac
The ViewHiding event is now dispatched consistently, regardless of whether the ViewShowing event is canceled or the panel is closed during the event. This is done by a new _openView helper, while the logic that is specific to each of the showMainView, showSubView, and goBack functions has been moved out of the _showView function.
MozReview-Commit-ID: 5WvW6THWbyb
--HG--
extra : rebase_source : 666c5744843f5197ab5130212096a1c83a2e3983
This allows the openViews array to reflect the state of the navigation more accurately, paving the way for further simplification of the code. The showSubView function will now fail early when it's called with a view that is already open, so the rest of the code doesn't have to take this case into consideration.
MozReview-Commit-ID: 1VoIImxVTDN
--HG--
extra : rebase_source : b483f9c7e2782f070f5694d85a91a0bfefff5457
extra : source : 7ce7a10fd212989eee76b482632eac9b985d4b2e
The ViewShowing event is now called earlier and unconditionally, since we don't set the "current" attribute and call showMainView while the panel is closing anymore.
It is already the case that the ViewShowing event handlers don't depend on the "current" property, so we don't need to keep track of it before ViewShown events are dispatched.
MozReview-Commit-ID: Ii4SN03KjwW
--HG--
extra : rebase_source : 5e994fa4d54b2805b5eb10d9471bbb25bd21f24c
The showSubView public method now aligns with its callers and doesn't return a Promise anymore. The showMainView method still returns a Promise because at the moment it is used externally for asynchronous cleanup.
MozReview-Commit-ID: FcnEx5f5HKh
--HG--
extra : rebase_source : dc0a8e5267b7211c7ee3e2216bd1dc0cabdbd4bd
extra : intermediate-source : 9cc3eafb24f3936eb8ccb359f2f04e9839ae9ff2
extra : source : 7ce7a10fd212989eee76b482632eac9b985d4b2e
This is part of the work to remove XUL overlays. The overlay was originally
created to help startup performance, but using a hidden panel instead seems to
have no detrimental effects to performance and is more straightforward.
MozReview-Commit-ID: JlWcZEhPXyH
--HG--
rename : browser/components/downloads/content/downloadsOverlay.xul => browser/components/downloads/content/downloadsPanel.inc.xul
extra : rebase_source : 60a9fec344b1e346594015cd36947fe1779257a7
Because BrowserErrorReporter instances process previously-logged messages when
they are initialized, multiple runs of each test case (such as during the test
verification suite) cause new instances to process messages from the previous
test run. Resetting the console at the end of each test case prevents tests from
affecting each other.
Differential Revision: https://phabricator.services.mozilla.com/D589
MozReview-Commit-ID: HwjbbE00o97
--HG--
extra : rebase_source : 94ea69f8dbe679ff228c5c9b016f131650be1671
extra : amend_source : 5a9d0b5018d28d2dfc4782e66c732b711cb67109
In search.js, _updateSuggestionCheckboxes is already hooked up to update this checkbox
based on the preference value, including change handlers for when it changes. As a result,
having both the preference attribute and the 'manual' JS means that the actual checked and
disabled state races with which code sets the value first.
The search suggestion order preference already doesn't have a preference attribute and is
only ever updated via the JS. It seems sensible to do the same here.
MozReview-Commit-ID: Cm8evlembt7
--HG--
extra : rebase_source : 41a55211c08c911ac234ea3cbe004391d86e4a3b
Set pref datareporting.healthreport.uploadEnabled=false during mochitests
and set pref toolkit.telemetry.server to a dummy server during reftests
(uploadEnabled was already false for reftest and the telemetry server was
already set for mochitests - now these prefs are consistent).
Some mochitests failed with this change; they are updated to
set datareporting.healthreport.uploadEnabled where required.