1549775 - [meta] RDM UI embedded into browser

Status: RESOLVED FIXED

(DevTools :: Responsive Design Mode, task, P1)

Description

[Brad Werth [:bradwerth]]

RDM will be much simpler in a one-domain-per-process model (Fission) if we can make it work without a message tunnel. One way to do that would be to embed the RDM UI elements into the mainline browser.xul and turn it on when RDM mode is enabled. This bug is to track the effort to build that prototype.

Useful links:
Brian Grinstead has suggested this is a location in browser.xul where we could add an iframe with RDM UI content that would persist in a window across all tabs: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/browser/base/content/browser.xul#1334

Comment 1

[Brian Grinstead [:bgrins]]

Attachment: Bug 1549775 - Rough integration of RDM frame in browser document

This is a proof of concept of hooking up the RDM controls into the tabbrowser.
It creates a single shared frame intended to render only the toolbar in RDM,
and then toggles the visibility based on whether the existing RDM is active.

There's a lot to do here:

• it doesn't actually render the toolbar (need to tease apart the bootstrapping logic in the existing RDM to allow for not swapping, etc)
• it doesn't send the browser's state into the tools.xhtml window in order to sync values between tab changes
• it doesn't replace the existing RDM connection or UI (and even relies on it for tracking visibility)
• it doesn't center the <browser> and provide resize handles for it
• and more, I'm sure

What it does do, hopefully, is provide a starting point for figuring out some unknowns
to help decide if this is a path we want to go (as opposed to adding fission support
to the existing message forwarding, etc that's needed for the current impl).

Comment 2

[Brian Grinstead [:bgrins]]

I've pushed up a very rough prototype that puts a new shared iframe on top of the tab in browser.xul, with visibility controlled by whether RDM is active. I think the next, harder, steps are:

• untangling the intialization in manager.js from swapToInnerBrowser and related functionality so that we can effectively bootstrap only the toolbar UI elements in this new doc
• drop the current RDM document so we have only the toolbar above the xul browser
• wire up the messages and data needed to properly populate the UI elements in the toolbar and then allow changes in them to affect the browser
• figure out centering and resizing the browser itself in browser.xul. I can help with this one if the above ones are looking feasible.

Micah or Brad, over to you :).

Comment 3

[Patrick Brosset <:pbro>]

(In reply to Brian Grinstead [:bgrins] from comment #1)

There's a lot to do here:

• it doesn't actually render the toolbar (need to tease apart the bootstrapping logic in the existing RDM to allow for not swapping, etc)
• it doesn't send the browser's state into the tools.xhtml window in order to sync values between tab changes
• it doesn't replace the existing RDM connection or UI (and even relies on it for tracking visibility)
• it doesn't center the <browser> and provide resize handles for it
• and more, I'm sure

Let's try to make this list as complete as we can in order to evaluate the costs of this solution:

• rendering the toolbar
• sending the browser's state into tools.xhtml
• replacing the existing RDM connection/UI
• center (or left-align based on user pref) the <browser>
• provide the resize handles for it, and synchronise this with the values displayed in the RDM toolbar
• make sure the device customization pop-up appears in full size, even if the RDM toolbar is in the tiny iframe at the top
• same thing for the various drop-down lists in the toolbar
• re-wire the screenshot functionality
• make sure the simulation features can be applied to the <browser> content:
  • touch events
  • DPR
  • <meta viewport> handling
  • network throttling
  • user agent string override
• make all of the existing tests pass again, and enable the ones we couldn't make work due to the current RDM's architecture (I think the zoom tests)

Comment 4

[Micah [:mtigley] (she/her)]

Attachment: Bug 1549775 - Render the RDM toolbar above the browser content.

Comment 5

[Micah [:mtigley] (she/her)]

Initial work on getting the RDM tools to render above the window content based on Brian's patch. Right now it will show the React toolbar component when RDM is opened. Still needs work on:

• Properly hiding the toolbar when RDM is closed per tab.
• Showing the Device setting modal component over the content when opened.

Comment 6

[Micah [:mtigley] (she/her)]

Attachment: initializing_RDM.png

Made a little more progress on getting the toolbar UI to communicate with the browser content via manager.js. Now RDM will resize the browser content when a new device is selected, the user agent string can be overridden, and the user can also rotate the viewport. The initial solution for this is to store a reference to the ResponsiveUI on the RDM frame when it's initialized. Doing this enables the RDM toolbar to directly call methods that apply simulation features to <browser> content from App.js. See onChangeUserAgent as an example. This is nice since it implies we no longer need to post messages between frames in the existing RDM and makes it easier for us to hide this prototype behind a pref.

Will update my patch with the described changes shortly.

Comment 7

[Gabriel Luong [:gl] (ΦωΦ)]

Attachment: Bug 1549775 - Prototype RDM UI embedded into browser.

Comment 8

[Gabriel Luong [:gl] (ΦωΦ)]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1569570#c7, Abdoulaye commented with Fission that we won't need to tunnel messages anymore since message managers are going away with fission work. We will eventually switch to using Actors that will handling the tunnelling for us.

This makes it really easy for RDM to be Fission compatible because we can rely on Firefox Frontend Fission work to help us eventually deprecate the tunnel. This is the existing documentation for the Fission team to avoid breaking RDM https://firefox-source-docs.mozilla.org/dom/dom/Fission.html?highlight=fission#do-not-break-responsive-design-mode-rdm.

So, this means we can avoid embedding the RDM into the browser UI since the message tunnelling will eventually be removed, and avoid more work on our end.

What we should do going forward:

• Putting a flag around the tunnel so that in a fission world we do not start the tunneling, and eventually we can remove tunnel.js
• Another thing would be to add unit tests to make sure that normal browser features (that were tunnelled before) work with RDM so that the Fission team doesn't break RDM.

Comment 9

[Gabriel Luong [:gl] (ΦωΦ)]

I spoke to mconley to verify what I discussed with Abdoulaye, and concluded we still want to carry on with this work since we don't want to remove the swapFrameLoaders in addition to the tunnel. It will also become increasingly difficult for Firefox Fission maintaining the RDM mozbrowser iframe since there will be process switches with fission.

To continue this work, we are converting this bug into a meta so that we can break down the work and land quickly.

Comment 10

[Micah [:mtigley] (she/her)]

Now that the RDM browser UI is the default as of Firefox 79 (see Bug 1585005), we can close this issue now.