2027036 - Explore capability to open link in split-view with a specified side

Status: NEW

(Firefox :: Tabbed Browser: Split View, task)

Description

[Erik Nordin [:nordzilla]]

Attachment: image.png

Description

We on the Translations team would like to make the upcoming Translate QuickAction (Bug 2004463) compatible with split view.

Note: The QuickAction ships in Firefox 150. This is not a requirement for release, rather something we would like to iterate on after release.

As part of that experience, we need the ability to open a link in split view (Bug 2019011), but it would be nice to also allow configuring which side of the window SplitView should open in.

For left-to-right locales, it probably makes sense to open the about:translations page on the left-hand side of the page. For right-to-left locales, we could open it on the right-hand side (see screenshot). We may also want to make this configurable independent of locale.

Comment 1

[Stephen Thompson [:sthompson]]

The existing Tabbrowser.addTabSplitView API https://searchfox.org/firefox-main/rev/c1f215a6400d8ddbb1e72092c2fda6dea0384473/browser/components/tabbrowser/content/tabbrowser.js#3601-3622 allows callers to pass tabs as a 2-element array of tabs in the logical order they should appear, i.e. the first tab in that array is always the first tab in the split view.

If you call gBrowser.addTabSplitView([newAboutTranslationsTab, tabToBeTranslated], { ... }), then about:translations would be the left-hand pane in LTR and right-hand pane in RTL.

If you wanted to configure which side gets the about:translate page, then I'd recommend managing that at the call site (i.e. in the translate quick action code that calls gBrowser.addTabSplitView) so that it calls addTabSplitView with the desired tab order.

Comment 2

[Sarah Clements [:sclements]]

Erik, have you tried Stephen's suggestion? I do want to point out that you should also pass in the insertBefore argument, so gBrowser.addTabSplitView([newAboutTranslationsTab, tabToBeTranslated], { insertBefore: tabToBeTranslated}) otherwise it'll deviate from current behavior and add the splitview wrapper (and move both tabs with it) to the end of the tabstrip. (I actually think we might want to change the default behavior to do that to avoid accidental consistencies but don't worry about that for now.)

Comment 3

[Erik Nordin [:nordzilla]]

This may very well work as intended as-is, and require no changes.

I only filed high-level bugs that I think I would need to implement Translations support with Split View, and if the capabilities are already possible, we can just close the bug.