This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
AFAICT this bug isn't reproducible anymore after bug 1623666. i.e., it's no
longer possible to show the history view. You can still see a history-like view
by typing ^ or a space, but in that case the first result is a search result,
not a history result, so it can't be deleted anyway. Nevertheless we should fix
this error.
Differential Revision: https://phabricator.services.mozilla.com/D79576
I considered wrapping `provider.tryMethod("updateBehavior", queryContext)` in a
promise in case there are implementations that aren't async or don't return a
promise. But there's only one implementation of `updateBehavior`, it's async,
and we probably won't end up with any more implementations, so for simplicity I
didn't.
Differential Revision: https://phabricator.services.mozilla.com/D79559
* Replace PlacesSearchAutocompleteProvider with UrlbarSearchUtils.
* Move the module from toolkit to browser. The only consumers of
PlacesSearchAutocompleteProvider are urlbar and UnifiedComplete.
* I'd like to add functions to UrlbarUtils instead, but
PlacesSearchAutocompleteProvider adds itself as an observer for search
engine changes, and it keeps some state so that alias lookups are O(1). It
has an init function to set that up. That's not quite as easy to do if I
just added some functions to UrlbarUtils, and I think that O(1) lookups of
aliases are worth keeping (vs. O(number of installed engines)), so I kept a
separate module, now called UrlbarSearchUtils.
* Init the search service (via UrlbarSearchUtils) from
UrlbarProvidersManager.startQuery so that every module involved in querying
doesn't need to do it.
* Remove PlacesSearchAutocompleteProvider.currentEngine. Previous consumers can
simply use Services.search directly now that the service is initialized early
(see previous point).
* Remove PlacesSearchAutocompleteProvider.parseSubmissionURL. Here again
consumers can use Services.search directly.
Differential Revision: https://phabricator.services.mozilla.com/D79244
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
This pref was enabled on all platforms, and the codepath which has it disabled
has been untested for some time. Remove the pref to simplify the code handling
the old case.
Differential Revision: https://phabricator.services.mozilla.com/D78974
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
As tabbrowser now uses `PROCESS_BEHAVIOR_STANDARD`, `PROCESS_BEHAVIOR_CUSTOM` is
now unused. This patch removes that now-unused code.
Differential Revision: https://phabricator.services.mozilla.com/D78972
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
We compare the value passed through with the title, and StyleSheet.title
returns null for empty titles, so we never consider an empty title to be
in the document, which is bad.
Differential Revision: https://phabricator.services.mozilla.com/D79700
This -moz-appearance is already set on #sidebar-box, in the main browser document.
Furthermore, we don't want to set the -moz-appearance when lwthemes are used, and
(as far as I can tell) we cannot detect lwtheme usage with :-moz-lwtheme in the
nested documents (bookmarksSidebar.xhtml, historySidebar.xhtml, syncedtabs/sidebar.xhtml).
Depends on D78924
Differential Revision: https://phabricator.services.mozilla.com/D78925
This is needed because under the new vibrancy model, vibrant -moz-appearance
values only work on elements that have nothing rendered behind them. The elements
with the vibrant appearance become truly transparent.
Differential Revision: https://phabricator.services.mozilla.com/D51465
The webrtc global indicator shows media indicators based on the indicator state
of the individual tabs.
Determining the visibility of the global indicator based on if there are active
streams (globally), but saving that state on tab level, lead to conditions where,
after a stream had ended, no tab had any indicators set, but a stray global
indicator without any icons would still be shown.
This patch fixes that by only showing the global indicator if there is actually
a tab with an indicator.
Differential Revision: https://phabricator.services.mozilla.com/D79315