harshmw Reporter
	Description • 6 years ago

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.

	Josh Matthews [:jdm]
	Comment 1 • 6 years ago

What happens if you open up Firefox's preferences, go to the Privacy tab, and change the Tracking Protection option to "Never"?

	harshmw Reporter
	Comment 2 • 6 years ago

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

	Johann Hofmann [:johannh]
	Comment 3 • 6 years ago

Maybe bug 1406675? In any case, I think the WebExtension team is a better contact for this.

	Andy McKay
	Comment 4 • 6 years ago

It still occurs for me in an up to date nightly, so it not be bug 1406675.

	Luca Greco [:rpl] [:luca] [:lgreco]
	Comment 5 • 6 years ago

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

	Pete
	Comment 6 • 6 years ago

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.

	Andrew Sutherland [:asuth] (he/him)
	Comment 7 • 6 years ago

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!

	Firefox Bug Husbandry Bot
	Comment 8 • 6 years ago

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

	Luca Greco [:rpl] [:luca] [:lgreco]
	Comment 9 • 6 years ago

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