1864220 - User profile tries to open something as an application link

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P2)

Description

[raymond.bennett]

Attachment: 2023-11-10_10-58.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0

Steps to reproduce:

Login with Mozilla Sync to my user profile
Try to open my user profile icon
Also tried to open settings > my email address

Actual results:

Firefox tries to open something as an application and there is no application found (see screenshot)

Expected results:

User profile and settings open up

Comment 1

[raymond.bennett]

It looks to be coming from synced tabs - I deleted the record for one of my computers and profiles works now. It seems to be this record

{
"title": "Frigate – Home Assistant",
"urlHistory": [
"https://or.excluded.com/ccab4aaf_frigate-fa/ingress"
],
"icon": "fake-favicon-uri:https://or.excluded.com/lovelace/0",
"lastUsed": 1699403263
},

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

I really don't understand this: trying to open your "manage account" page should take you to https://accounts.firefox.com - I don't see how a tab synced from another device could cause this to change.

Further, a synced tab should have no impact until it is opened - the fact another device happens to be syncing a tab should have no impact on this device until you explicitly select it - and even then, it should just open the tab as though you pasted the URL in yourself.

So I think we are going to need more details or clear steps to reproduce before this is actionable.

Comment 4

[raymond.bennett]

Attachment: ff.png

Adding screenshot to show what I meant, the main profile menu or the sub-menu. Clicking either one of those seems to read the synced tab info and then it would try to open an external application.

Comment 5

[Mark Hammond [:markh] [:mhammond]]

That's very odd. What's supposed to happen is that both of those should open another panel - eg, clicking the toolbar item takes no action, instead shows a menu with, eg, "Manage Account", "Sync now", etc. Ditto the main menu - that arrow on the right implies it will open another menu to the right with the same items. It's only when you click on one of the items in the new menu (eg, "Manage account") any action is taken.

To be clear, you are saying you do not see any sub-menus there but instead get taken to the screen in comment 0? Do you have any idea what it is which is showing that screen? The URL looks like it has ...i:https:// - are you able to post the entire first part of that URL?

Comment 6

[raymond.bennett]

That is correct, when clicking the R or trying to open the sub menu, rather than showing me the profile menu, it is popping up the dialog in the first screenshot rather than the expected menus. Because it pops up the dialog, it closes the menu so I am unable to get into the menu at all.

Closing Firefox allows me to navigate to the hamburger menu, but it breaks and I cannot even access the hamburger menu once I have selected the user profile submenu.

The full text from the screenshot is the part of this synced tab json it looks like it is using what is in the "icon" portion because it shows in the screenshot ...i:https://or.excluded.com/lovelace/0 - note I use 'excluded' here rather than my own personal domain name. If you think the actual domain name or there is a call out to that domain for something, I can share the domain details in private with you.

{
"title": "Frigate – Home Assistant",
"urlHistory": [
"https://or.excluded.com/ccab4aaf_frigate-fa/ingress"
],
"icon": "fake-favicon-uri:https://or.excluded.com/lovelace/0",
"lastUsed": 1699403263
},

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Are you using a snap for any chance? It seems fake-favicon-uri: is using nsIExternalProtocolHandler (here), which snap / flatpak have a different implementation of (because of the sandbox).

Comment 8

[Emilio Cobos Álvarez [:emilio]]

https://www.reddit.com/r/kde/comments/10xhx4h/what_is_this_fakefaviconuri_popup_that_keeps/ to this.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Also, if you paste fake-favicon-uri:https://or.excluded.com/lovelace/0 into the URL bar, do you get that popup?

Comment 10

[Emilio Cobos Álvarez [:emilio]]

It seems like if I do something like: new Image().src = "zoommtg:foo" in the browser console, we try to open the external protocol dialog (but fail with Can't show external protocol dialog. BrowsingContext has no browser associated. ContentDispatchChooser.sys.mjs:108:15).

However that in content doesn't. That's presumably because the content security manager blocks it for content but lets it through for the chrome principal. Maybe we should be more restrictive there?

Comment 11

[raymond.bennett]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Are you using a snap for any chance? It seems fake-favicon-uri: is using nsIExternalProtocolHandler (here), which snap / flatpak have a different implementation of (because of the sandbox).

Yes, I am using a snap

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

Also, if you paste fake-favicon-uri:https://or.excluded.com/lovelace/0 into the URL bar, do you get that popup?

Yes, it does the same thing if I put that in the address bar.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Thanks! So, I'd expect that prompt if you type fake-favicon-uri: into the address bar, but I don't think we should try to trigger that code-path for for images.

So, for content, we hit this. But for system principal we skip those because this early-returns.

Gijs, maybe we should apply some of these policies to system principal loads, wdyt?

Comment 13

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Thanks! So, I'd expect that prompt if you type fake-favicon-uri: into the address bar, but I don't think we should try to trigger that code-path for for images.

So, for content, we hit this. But for system principal we skip those because this early-returns.

Gijs, maybe we should apply some of these policies to system principal loads, wdyt?

Yes, that sounds right to me. Maybe Christoph can help? The code here suggest we exempt in part as an optimization. Not sure how big a performance penalty it'd introduce...

The frontend-y fix we could potentially use here is to introduce a CSP for browser.xhtml...

Comment 14

[Christoph Kerschbaumer [:ckerschb}]

(In reply to :Gijs (he/him) from comment #13)

Gijs, maybe we should apply some of these policies to system principal loads, wdyt?

Yes, that sounds right to me. Maybe Christoph can help? The code here suggest we exempt in part as an optimization. Not sure how big a performance penalty it'd introduce...

Yes, I think that is a valid option to apply more of these policies to SystemPrincipal loads. What I remember, when we started to check CSP for SystemPrincipal loads it did not introduce a measurable performance penalty. Probably a first reasonable step would be to simply test that by removing the early return and push to try (including talos).

Comment 15

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

The severity field is not set for this bug.
:lougenia, could you have a look please?

For more information, please visit BugBot documentation.

Comment 16

[Edgar Chen [:edgar]]

(DOM: Security seems to be a more appropriate component)

Comment 17

[Frederik Braun [:freddy]]

No, DOM: Security is also not "it"... Let's try again.

Comment 18

[:Gijs (he/him)]

I think what would have previously happened is we assign the URI (with fake-favicon-uri protocol) into an image and that load would trigger the external protocol link opening (apparently).

I would expect the new CSP we have for browser.xhtml to now prevent this. Tom, is that right? Raymond, I'm aware it's been a while - any chance you can still reproduce this / saw this go away at some point?

(In reply to Edgar Chen [:edgar] from comment #16)

(DOM: Security seems to be a more appropriate component)

nsContentPolicyUtils.h referenced in comment 12 is in DOM: Core & HTML. Enforcing content policy utils constraints on system principal loads falls pretty squarely on either that or DOM: Security. I don't mind which but it's clearly not frontend browser code. :-)

Comment 19

[Tom Schuster (MoCo)]

I would expect the new CSP we have for browser.xhtml to now prevent this. Tom, is that right?

The CSP for browser.xhtml is still limited to scripts, so normally an image load would not be blocked by it.

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Gijs,
In our triage meeting, we were not clear see why this was characterized as S2. Can you shed some light here, or does it make sense to move to S3?

Regarding the component, I can see arguments which component this bug fits the best. I will leave it as is for now; however, if this remains a valid S2 that requires a prompt fix, I am happy to drive the next steps and ensure it is assigned to the proper component. :)