Closed Bug 1549775 Opened 2 years ago Closed 9 months ago

[meta] RDM UI embedded into browser

Categories

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

task

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bradwerth, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file, 3 obsolete files)

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

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).

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 :).

(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)
Assignee: nobody → bwerth
Priority: -- → P3
Status: NEW → ASSIGNED

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.
Attached image 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.

Blocks: 1574886
Whiteboard: dt-fission
Blocks: 1574888

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.
Priority: P3 → P1
Whiteboard: dt-fission

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.

Assignee: bwerth → nobody
Status: ASSIGNED → NEW
Summary: Prototype RDM UI embedded into browser → [meta] RDM UI embedded into browser
Depends on: 1578824
Depends on: 1578839
Attachment #9084139 - Attachment is obsolete: true
Depends on: 1584346
Depends on: 1585008
Attachment #9064283 - Attachment is obsolete: true
Depends on: 1585100
Depends on: 1585121
No longer depends on: 1585121
No longer blocks: 1574888
No longer blocks: dt-rdm-fission
Attachment #9063292 - Attachment is obsolete: true
Blocks: 1610657
Blocks: 1534459

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

Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.