1701814 - Popup exceptions set via about:preferences do not apply to private browsing windows

Status: RESOLVED WONTFIX

(Firefox :: Private Browsing, defect)

Description

[Brenda Selwood]

Attachment: Screen shot

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

• Go into private mode
• Have "http://garfield" and "https://garfield" in pop-up exception list
• put "garfield/home.asp" in address bar, this is a local IIS server on my network.
• Garfield/home.asp has 4 popups.
  I have firefox configured to display popups in a new tab (probably not relevant)

Actual results:

"Firefox prevented this site from opening 4 pop-up windows"

Expected results:

Firefox should allow the pop-ups.
It works normally out of private mode.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Johann Hofmann [:johannh]]

Pretty sure this is a regression of bug 1680237. Paul, I feel like we do want to support popup blocking exceptions in PBM still, right? If so, I think we have a few options:

• Add popup permissions to the OA strip list. That would also mean making them preloaded, IIUC. That's a bit unfortunate considering that it would add another blocker to removing preloading, but I guess we already have cookies and the overhead from popup permissions should be negligible.

• Re-work the dialog so that we no longer show the full origin, only the domain, and in the background add the relevant permissions for scheme, OAs, etc.. This might work for PBM but it doesn't sound like it scales well to cover userContextId etc.

• Strip OAs before getting/setting any popup permissions, in the popup blocker code itself. This is a bit of a hack but maybe it has the least amount of downsides.

Thoughts? :)

Comment 3

[Emma Zühlcke [:emz]]

Ideally permissions granted via the Permissions section in about:preferences#privacy should be granted for normal browsing, private browsing and all user contexts. This would be intuitive for the user. about:preferences is perceived as a global entry point, no matter if accessed via private, normal browsing or from a container tab.
In reality our permissions backend doesn't really support it. We have to explicitly pass origin attributes. We can work around this when the set of possible values is finite. That's currently still the case for private browsing (we might want to change it in the future?), but not for user contexts.

Re-work the dialog so that we no longer show the full origin, only the domain, and in the background add the relevant permissions for scheme, OAs, etc.

I'm in favor of this approach. For now we could always update permissions modified via about:preferences for both private browsing ids (normal and private browsing). This would solve the issue for all site permissions managed there. We don't ship user context permission isolation to any channel, so I wouldn't invest the additional time at this point.

Long-term some sort of wildcard functionality for origin attributes in permissions would be nice. For example, setting popup for https://permission.site^privateBrowsingId=*. This would allow popups for both normal and private browsing. This has the advantage that consumers that set the permission can set wildcards (e.g. from about:preferences, default permissions), but also target very specific origin attributes (e.g. from permission prompts).

Comment 4

[Emma Zühlcke [:emz]]

Johann, do you think we could apply your suggestion to all permissions managed in about:preferences like I described in comment 3? This way we'd improve user experience and avoid similar bugs for other permissions.

Re-work the dialog so that we no longer show the full origin, only the domain, and in the background add the relevant permissions for scheme, OAs, etc.

I can work on this on the side, do we want a fix for 89?

Comment 5

[Emma Zühlcke [:emz]]

Attachment: WIP: Bug 1701814 - Update normal and private browsing permissions via the preferences permission lists. r=johannh!

Comment 6

[Emma Zühlcke [:emz]]

I've submitted a WIP patch that makes about:preferences permission changes also apply to private browsing. It mostly works well, however if we don't want to update our UI we run into state issues.
For example, a user can add a popup permission, which gets added in both normal and PB. If they then revoke the permission only in private browsing, we have a conflicting state. My patch handles this by giving the normal browsing permission priority. But this isn't ideal.
There is another UX issue, if users already have a permission set in about:preferences, for example via accepting a permission prompt. The permission list will show that permission, but they will not be able to update the state for the other browsing mode where it's not set yet. To to that they'd need to remove the permission and re-add it or flip the state twice so it applies globally. This becomes even more apparent in our sitePermissions table (sitePermission.js), which only supports state switching, not adding new permissions.

If we want to go with the global about:preferences permissions approach we'd need to adapt the UI. Perhaps we could show the persistent private browsing permissions added via this dialog as separate items. For example:

https://example.com
https://permission.site
https://permission.site (Private Browsing)

Comment 7

[Brenda Selwood]

As a user, I'd expect private mode to work the same as normal mode, just there is no record kept of the session.

This bug didn't exist before about four days ago, I forgot to mention that in my initial bug report.
I assumed whatever got changed for v87 would be undone and away we would go.

Comment 8

[Emma Zühlcke [:emz]]

(In reply to Brenda Selwood from comment #7)

As a user, I'd expect private mode to work the same as normal mode, just there is no record kept of the session.

This is why we have added separated permissions of private and normal windows. So for example if you allow a site to access your camera in a private window, the site won't have permission to do that in the normal window. The confusing part is that the permission table in about:preferences manages only normal browsing permissions, even if you open the preferences from a private window.

This bug didn't exist before about four days ago, I forgot to mention that in my initial bug report.
I assumed whatever got changed for v87 would be undone and away we would go.

Yes, this is a result of Bug 1680237 which enables these separated permissions for 87. We don't want to undo that, because it improves user privacy.

Comment 9

[Emma Zühlcke [:emz]]

Closing this bug as wontfix. See my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1702290#c3