Split bindings/browser.xml into a local-browser and remote-browser bindings

RESOLVED FIXED

Status

Fennec Graveyard
General
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: mfinkle, Assigned: mfinkle)

Tracking

Details

Attachments

(1 attachment)

Created attachment 449884 [details] [diff] [review]
patch

Since we will use message manager APIs for non-e10s and e10s browsers, we need to support the core message based APIs in a base browser binding and then inherit the remote browser binding from it.

In the future, we'll look at moving the core message based API binding into toolkit/browser.xml, but for now it's faster and safer for Fennec to keep this binding local.
Attachment #449884 - Flags: review?(21)
The patch also removes some methods we haven't overriden from the local, core binding.
Attachment #449884 - Flags: review?(21) → review+
pushed to m-b:
http://hg.mozilla.org/mobile-browser/rev/fa191f695f1a
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
After applying a few patches on top of this change, and thinking ahead to supporting local and remote pages in a single app, we might need to:

* Add full _webProgress support in local-browser since we want the exact same callbacks used for local (about: pages) and remote (web content pages). We can remove the _webProgress from the remote-browser since it inherits it from local-browser.
* Add full _webNavigation support in local-browser for the same reason as above. The code paths for local and remote browsers should be the same.

The only reason to keep the local-browser is some properties _will_ work (contentWindow and contentDocument), but can't in remote-browser.

I'll file a new bug
bugspam
Assignee: nobody → mark.finkle
You need to log in before you can comment on or make changes to this bug.