Open Bug 1427986 Opened 5 years ago Updated 5 days ago

indexedDB access when "Always use Private Browsing Mode" is set

Categories

(WebExtensions :: Storage, defect, P3)

57 Branch
defect

Tracking

(Not tracked)

People

(Reporter: harshmw, Unassigned)

Details

Attachments

(1 file)

Attached image Error.png
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171226083017

Steps to reproduce:

1. Open Firefox
2. Add the following Add-on
   "https://addons.mozilla.org/en-US/firefox/addon/youtube-subscription-checker/"
3. Go to Options=>Privacy & Security=>and Enable "Always use Private Browsing Mode"
4. Firefox Restarts
5. Go to the Add-on page via the Add-on icon in the customisable space of address bar..


Actual results:

The Add-on stops working and gives Error.
Failed to open internal database
(Screenshot of the same is attached)


Expected results:

The Add-on should work normally.
Component: Untriaged → Private Browsing
What happens if you open up Firefox's preferences, go to the Privacy tab, and change the Tracking Protection option to "Never"?
Flags: needinfo?(harshmw)
(In reply to Josh Matthews [:jdm] from comment #1)
> What happens if you open up Firefox's preferences, go to the Privacy tab,
> and change the Tracking Protection option to "Never"?

Still the same error, on other hand if i disable this always private browsing mode,,and restart,the Add-on is back working as if nothing happened....
Flags: needinfo?(harshmw)
Maybe bug 1406675? In any case, I think the WebExtension team is a better contact for this.
Component: Private Browsing → WebExtensions: Untriaged
Product: Firefox → Toolkit
It still occurs for me in an up to date nightly, so it not be bug 1406675.
Flags: needinfo?(lgreco)
Priority: -- → P3
Summary: When I enable Always use private browsing(never remember history), The Youtube Checker Add-on stops working and this is not a bug in the Add-on, it is an issue with Firefox desktop. → indexedDB access when "Always use Private Browsing Mode" is set
Yes, Bug 1406675 doesn't cover the permanent private browsing mode.

In Bug 1406675 comment 21 I have briefly described which is the current behavior:

- permanent private browsing mode:
  - extension pages' localStorage not persisted (cache cleared once the last private browsing window is closed)
  - extension pages' indexedDB.open raises an exception (like any webpage opened in a private browsing window)

(in the last part of end of the Bug 1406675 comment 21 I also briefly described why we agreed that it wasn't possible to cover it in the same Bugzilla issue: "the best option seems to be to ensure that the extension pages are not in private browsing mode, but it has to be discussed in much more detail to decide if it is really a viable approach).
Flags: needinfo?(lgreco)
I can confirm the same issue with the Update Scanner extension. I suspect that most webextensions that use IndexedDB will be broken when private browsing mode.

It would be useful to either exclude webextensions from storage restrictions when in private browsing mode, or provide a permission to allow this.
Product: Toolkit → WebExtensions
Kris, I feel like this has come up on other bugs that I can't find, but is it still the case that "always use private browsing mode" results in the WebExtensions' OriginAttributes being marked with Private Browsing mode?  In https://bugzilla.mozilla.org/show_bug.cgi?id=781982#c71 a developer is reporting their extension can't use IDB in PrivateBrowsing, which makes sense if the OriginAttribute thing is still happening.

I understand there may be reasons to not change that yet, like :pauljt's concerns in bug 1457001 but I want to know the right bug to point people at for this scenario, which perhaps is this bug?  (In which case, can it be moved out of untriaged and marked confirmed?)  Thanks!
Flags: needinfo?(kmaglione+bmo)
Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958
Component: Untriaged → General
(In reply to Andrew Sutherland [:asuth] from comment #7)
> Kris, I feel like this has come up on other bugs that I can't find, but is
> it still the case that "always use private browsing mode" results in the
> WebExtensions' OriginAttributes being marked with Private Browsing mode?  In
> https://bugzilla.mozilla.org/show_bug.cgi?id=781982#c71 a developer is
> reporting their extension can't use IDB in PrivateBrowsing, which makes
> sense if the OriginAttribute thing is still happening.

Yes, I can confirm that this is still the case.

The background page gets the originAttributes's privateBrowsingId set to 1 when Firefox is running in permanent
private browsing mode:

- https://searchfox.org/mozilla-central/rev/e22c0d152060f4f8d4ca8904094f15f65a1b6f93/toolkit/components/extensions/ExtensionParent.jsm#1105-1109

Whereas extension pages opened in tabs are going to have a triggering principal with
the privateBrowsingId set to 1 if the related window is a private window:

- https://searchfox.org/mozilla-central/rev/e22c0d152060f4f8d4ca8904094f15f65a1b6f93/browser/components/extensions/parent/ext-tabs.js#561

> 
> I understand there may be reasons to not change that yet, like :pauljt's
> concerns in bug 1457001 but I want to know the right bug to point people at
> for this scenario, which perhaps is this bug?  (In which case, can it be
> moved out of untriaged and marked confirmed?)  Thanks!

I took a look to the other existing WebExtensions bugs related to IndexedDB and this bug seems the better
one to point people that are experiencing this issue (and I've just marked it as confirmed).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kmaglione+bmo)
Component: General → Storage

This is definitely related to bug 781982, but that one's about web scripts and this one's about extensions, IIUC.

Given that bug 1345474 has landed, could we allow IndexedDB for background pages for Web extensions that have been enabled in private browsing? Or is that already the case?

(I am trying to use IndexedDB but users of permanent private browsing are complaining of breakage. It would be nice to to tell them to allow the add-on in private browsing as a workaround, but perhaps they already need to do that to install the extension anyway?)

You need to log in before you can comment on or make changes to this bug.