Move Firefox's nsIWebBrowserChrome3 implementation into an actor
Categories
(Core :: DOM: Content Processes, enhancement, P3)
Tracking
()
People
(Reporter: mossop, Assigned: mossop)
References
Details
Attachments
(1 obsolete file)
The new way to implement a WebBrowserChrome implementation is through an actor. GeckoView does this already. Unfortunately this makes it more difficult to have per-frame behaviour and in Firefox we already have a behaviour for tabs and a behaviour for webextensions and I haver plans to add a third.
This will implement a base WebBrowserChrome whose behaviour can be changed per-browsingContext. You can send it a message to register a different actor to use for the calls. If one isn't registered then it will attempt to get a DefaultWebBrowserChrome actor. If all that fails just return sane defaults.
Assignee | ||
Comment 2•4 years ago
|
||
We use different nsIWebBrowserChrome implementations for different browsers so
this adds a base WebBrowserChrome actor which can be told to defer to another
actor. It identifies the actor to defer to based on the browser ID added in
bug 1601104. The mechanism for telling the actor what to use is a bit of a
kludge but we need to have the data available across all content processes and
I'm not sure of an alternative way of doing that.
Comment 3•4 years ago
|
||
mossop, do you plan to continue work on this bug? Do we need this bug for Fission?
Nika expects that some day we will remove nsIWebBrowserChrome* entirely.
Assignee | ||
Comment 4•4 years ago
|
||
No I think this bug is the wrong approach since as you say nsIWebBrowserChrome3 isn't likely to live in fission. For now the feature I needed this for is not currently resourced anyway.
Updated•4 years ago
|
Description
•