-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private tabs/windows handling in mobile form factors #632
Comments
This was discussed during the 2024-06-06 meeting. @Rob--W Requested for use cases which I have added to the main issue. I suggest everyone with |
In the meeting I mentioned the use case of opening a private tab. On Firefox's side there is a bug report for that at https://bugzilla.mozilla.org/show_bug.cgi?id=1372178 At the abstract level, I view a "window" in the extension API as a collection of tabs. In Firefox for Android the current extension implementation treats every tab as a single tab in a window, but this is something I'd like to change. The two most common collection of tabs on Firefox for Android are the private and non-private tabs. In your proposal (1) you mentioned window pairs. That could be implemented either as a property of the window (e.g. an array referencing others) or a new type (collection of ). I currently have no opinions on which to use, but note that the introduction of a new type would enable more metadata to be added to the collection of paired windows if desired. To answer the design questions in the original issue:
That API call could already return an empty list. E.g. on macOS, it is possible to close all browser windows and the application still be running. Even on non-macOS, you can have the global Browser Console open and there not being an active window. An alternative to an always-existing paired window is to introduce an option to the
Up to the implementation, but in the API design this could be exposed as
The created window. If another window is created the
From the API design perspective, one of the tabs in the window could be marked as active, i.e. the one to be highlighted if the window were to be activated. I know that the UI could not be focusing any particular tab. In that case it could be acceptable to either highlight the last active tab or none. |
Introduction
During the 2024 San Diego in-person meeting the question on how to handle private tabs/windows has briefly been discussed and promised to create a WECG issue to proceed this discussion.
The concept of window is often absent in mobile web browsers nowadays. The ability to open private tabs is often implemented by having a separate tab stack. Users can then toggle between their private tabs and normal tabs.
The questions for this group is how the extension APIs should handle this form factor. This is especially questioned for the browser.windows API.
In this issue I want to describe two approaches. The first approach is currently implemented by Safari on iOS. The second approach has not been discussed in detail however to make sure we make the right decision I want to include it as both approaches have their benefits and downsides.
Approach 1: using a window pair
This approach would mean every app frame would have two windows which are a pair. One window will contain all the normal tabs, while the other window will contain the private tabs.
To assist developers, a new
pairedWith
key in thewindows.Window
object can be introduced containing an array which includes the window ids of the other window(s) which the window is paired with.Benefit:
Downsides:
tabs.query({currentWindow: true, active: true})
could result in an empty list.windows.remove()
as it is unclear what should happen with paired windowsbrowser.windows.create
API would create two windows when calling. What window id to return in that case?Approach 2: using one window with mixed private and non-private tabs
This approach would allow "mixed" as value for the
incognito
property inwindows.Window
objects. As alternative a non-breaking new property can be introduced namedprivate
which can betrue|false|"mixed"
and has the added benefit of being more browser-neutral (see #113). In the case of "mixed" windows, theincognito
would then simply statetrue
to prevent any privacy issues and backwards compatibility issues.Benefits:
browser.windows
APIs would work fine and semantically make senseDownsides:
tabs.query({currentWindow: true, active: true})
could result in an empty list.Use cases
Reopen in private
This extension reopens the current tab in a private tab if it is currently a normal tab. And reopens it as a normal tab if it is a private tab. This requires the
browser.windows
API.Others
During the in-person meeting it was implicitly mentioned extension developers request the
browser.windows
API on mobile. Related issue on Firefox bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1372178Conclusion
Both approaches have benefits and downsides and need further discussion. There are a few open ends. For example, should we consider a device switching back and forth to a mobile form factor? (Think about a tablet for example).
The text was updated successfully, but these errors were encountered: