957803 - Metro Firefox should use the remote-browser binding from toolkit/content/widgets

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: Browser, defect)

Description

[Matt Brubeck (:mbrubeck)]

Metro Firefox currently has its own XBL <browser> bindings in browser/metro/base/content/bindings/browser.xml, including local-browser (in-process) and remote-browser (out-of-process).  Both extend the default <browser> binding from toolkit/content/widgets/browser.xml.

Toolkit contains a separate remote-browser binding in toolkit/content/widgets/remote-browser.xml.  Currently Metro does not use this binding at all, and duplicates a lot of effort as a result.

Metro Firefox should switch to using both the local and remote bindings from toolkit.  We should extend them as little as possible, and instead add the feautres we need to the toolkit bindings whenever we can.

Comment 1

[Marco Mucci [:MarcoM]]

Hey Jim, to facilitate better estimating we are breaking down large pieces of work (13 points and above) into smaller components.  Can you do that for this bug.

Comment 2

[Matt Brubeck (:mbrubeck)]

If this is really a 15-point task, then it might be more trouble than it's worth.  I was hoping it would mostly be a matter of moving some code around.  Splitting up the work might look something like this:

* For functionality implemented in both Metro and toolkit bindings, update Metro to be compatible with the toolkit API, and delete the redundant Metro implementation.
* For functionality provided by the Metro bindings but not the toolkit ones, move the code from the Metro bindings into toolkit, or into standalone Metro source files.
* Switch Metro to use the toolkit bindings directly (or maybe with some minimal extensions).

The first one is probably where any hard work would be found.  The second should be straightforward but would depend on what toolkit peers think (if we choose to move any code "upstream" into toolkit).  After the first two items are done, the third should be trivial.

Comment 3

[Marco Mucci [:MarcoM]]

Hey Matt, thanks very much for the suggestions on splitting up the one large feature work into three separate components.  Splitting makes it easier to estimate, track and forecast.  Let's discuss at the Monday Team Meeting.

Comment 4

[Jim Mathies [:jimm]]

I was being conservative. This is a central part of the browser and I'm sure there will be incompatibilities between the two. So this will need a lot of testing and tweaking looking for bug fallout. It might not be as bad as a 15, but I'd rather over estimate than under estimate. We won't know how complex this is until we dig into it and start using the code in toolkit.

Comment 5

[Marco Mucci [:MarcoM]]

Hey Jim.  It's better to be conservative with your estimates.  With that, it will be good to break this down into smaller components with each one having it's own estimate.

Comment 6

[Jim Mathies [:jimm]]

I don't see a way to break this down into multiple bugs. There are two files that define two different interfaces, we want to switch from one to the other. It's a single task that will take some time to put together and test.

Comment 7

[Marco Mucci [:MarcoM]]

Hey Jim, do Matt's suggestions in Comment 2 not work for this bug?

(In reply to Jim Mathies [:jimm] from comment #6)
> I don't see a way to break this down into multiple bugs. There are two files
> that define two different interfaces, we want to switch from one to the
> other. It's a single task that will take some time to put together and test.

Comment 8

[Jim Mathies [:jimm]]

clearing all of these sp they don't show up in the p1/p2 list until dependent work is complete.

Comment 9

[Firefox Bug Husbandry Bot]

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354