WebExtension cannot open private browsing tabs or "windows" on Android
Categories
(WebExtensions :: Android, enhancement, P5)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
(Depends on 1 open bug, Blocks 3 open bugs)
Details
(Whiteboard: [android], triaged[addons-jira])
Normally, to open a tab in an incognito window, one can do browser.tabs.create({url, windowId: some_id_of_a_private_window}); or open a new private window: browser.windows.create({url, incognito:true}); Bug 1260548 adds the "tabs" API to Android, but not the windows API. When I run browser.tabs.query({}).then(console.log), I see that all tabs have the same windowId (even if the "incognito" key of the tab is true/false), so it is not even possible to use tabs.create({windowId}) to open a private tab. I think that we should support browser.tabs.create({url, incognito}); and let Firefox choose an (any) existing private window or open a new one if it does not exist. Alternatively, we could re-use the cookieStoreId parameter from bug 1302697. cookieStoreId:'firefox-private' would then open a private browsing tab. This parameter is however not recognized on Android yet, and using the API requires the "cookies" permission. An advantage of this over my first suggestion is that it does not add new keys to the tabs.create API. A third option is to implement a "windows" API with proper windowIds. Currently all tabs on Android have one windowId, namely "1". Since windows cannot be created or removed on Android, the API exposes the two tab stacks (default and private tabs) as "windows", through the browser.windows.getAll and browser.windows.get API. Private tabs can then be opened using browser.tabs.create({url,windowId}). Trying to emulate the concept of windows might be a bit too much efforts since the only distinguishing difference between the tabs in either context is whether private browsing mode is enabled.
Updated•7 years ago
|
Reporter | ||
Comment 2•7 years ago
|
||
Hi Aastha, thanks for your interest in contributing! If you're looking at this bug as a way to contributing to the WebExtensions API, then I'm afraid that it is not the most beginner-friendly bug, because of unresolved API design decisions that block this bug (see the bottom of my post). I've seen that you've also expressed interest in another Android-related WebExtension bug, so I'll providing some tips here too: If you have not set up a development environment yet, I suggest to set up an environment using artifact builds. After downloading the necessary files, you can make changes and compile the result in only a few minutes. After building Firefox for Android, you need to be able to run it (and unit tests). Here are some starting points to set up a development environment for Firefox for Android: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_for_Android_build#I_want_to_work_on_the_front-end https://wiki.mozilla.org/Mobile/Fennec/Android/Testing#Running_tests_on_the_Android_emulator After checking out the repo and setting up .mozconfig as shown in the first link, a specific test can be run as follows: mach build mach package mach install mach mochitest mobile/android/components/extensions/test/mochitest/test_ext_tabs_create.html You can look at existing code for examples on how to write tests, APIs, etc. For example via https://searchfox.org The directories of interest for WebExtensions are mentioned at https://wiki.mozilla.org/WebExtensions/Hacking#Code_layout If you have general questions (e.g. development, the direction of a patch, etc.), you could join the #webextensions IRC channel to ask us questions. As for the unresolved API design decisions: On Firefox for Desktop, "private tabs" can only exist in "private windows". At present, private and non-private browsing modes cannot be mixed in Firefox for Desktop. On Firefox for Android, the concept of "window" does not exist. Private and non-private tabs are listed together. The API design question is which direction we should go: - porting properties from the windows API to the tabs API (the incognito flag), or - introducing a "window" concept that maps to the two static tab stacks on Android.
Reporter | ||
Comment 3•7 years ago
|
||
Let's hold off working on this bug until we know whether a windows API for Android is acceptable.
Updated•7 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 4•4 years ago
|
||
Any news/plans about this? What's the status in Fenix?
Reporter | ||
Comment 5•4 years ago
|
||
Fenix has a "cookieStoreId" property (bug 1622500), but it doesn't behave as documented yet.
I suggest to watch bug 1643688 (that bug's summary is about concrete defects in the implementation, but the following discussion may pave the path towards a resolution of this bug).
Reporter | ||
Comment 7•2 years ago
|
||
FYI.
Currently, every "tab" on Fenix is in its own window. That does not only imply that methods such as tabs.move
and tab.index
cannot meaningfully be implemented yet, but that in theory it is possible to repurpose cookieStoreId: "firefox-private"
without it losing its meaning. A write-up of that is at https://phabricator.services.mozilla.com/D139796?id=604071#inline-844143
Another challenge is to not only get it working in unit tests (TestRunnerActivity), but also in Android-Components + Fenix. I don't know how difficult that would be: i.e. not just opening a new tab, but switching to the right UI view (the "tab stack" for private browsing tabs / normal browsing tabs) before opening the right tab.
Updated•2 years ago
|
Reporter | ||
Updated•4 months ago
|
Updated•4 months ago
|
Description
•