Not able to query for loopback-network permission in v149
Categories
(Core :: Networking, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox151 | --- | fixed |
People
(Reporter: coirwin, Assigned: emz, NeedInfo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(3 files)
Steps to reproduce:
- Started using v149 beta version of Firefox
- In advanced preferences, set "network.lna.enbled" to true
- In advanced preferences, set "network.lna.blocking" to true
- In advanced preferences, set "network.lna.local-network-to-localhost.skip-checks" to false
- Ran "window.navigator.permissions.query({ name: "loopback-network" }).then(console.log);" in the console
Actual results:
I was not able to query the "loopback-network" permission. Running "window.navigator.permissions.query({ name: "loopback-network" }).then(console.log);" in the console showed the error "TypeError: 'loopback-network' (value of 'name' member of PermissionDescriptor) is not a valid value for enumeration PermissionName."
Expected results:
In v150 Firefox from the nightly release channel, I am able to successfully query the "loopback-network" permission. Do you happen to know if I might not be setting the preferences correctly to be able to query the permission in v149? If this is not an issue reflated to the preferences, do you know if there is a workaround that would allow me to query for the "loopback-network" permission in v149?
|
||
Comment 1•1 month ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 month ago
|
||
The new permission names landed in bug 1989920.
We might uplift them to 149 if possible.
Thanks Valentin! I noticed that the v149 beta release notes mention that the Local Network Access changes are a part of a progressive rollout. When v149 is released to the stable release channel, will the Local Network Access changes also be progressively rolled out to v149 stable version? Do you happen to know when the progressive rollout of the Local Network Access changes would start for the stable channel?
We also noticed that it looks like the loopback-network permission doesn't change state if the user does not select the Remember my choice for this site option. Do you happen to know if there is a way for us to programmatically check if the user has the permission temporarily enabled/disabled? Do you know if there are plans to add updates so that the loopback-network permission state is updated if the permission is temporarily enabled/disabled?
Would you be open to waiting to release the local network access changes to the stable release channel until the updates are added so that the loopback-network permission state is updated if the permission is temporarily enabled/disabled?
|
|
||
Comment 6•1 month ago
|
||
Do you happen to know if there is a way for us to programmatically check if the user has the permission temporarily enabled/disabled? Do you know if there are plans to add updates so that the loopback-network permission state is updated if the permission is temporarily enabled/disabled?
No, the entire point is that users should be notified when a page tries to do a LNA fetch.
If a page really needs to do a LNA fetch, it should do so, and the user will allow it if it is reasonable.
The current plan is for LNA to ship in 149 for ETP strict users, and 150 for all desktop users.
|
|
||
Updated•1 month ago
|
(In reply to Valentin Gosu [:valentin] from comment #6)
Do you happen to know if there is a way for us to programmatically check if the user has the permission temporarily enabled/disabled? Do you know if there are plans to add updates so that the loopback-network permission state is updated if the permission is temporarily enabled/disabled?
No, the entire point is that users should be notified when a page tries to do a LNA fetch.
I think this is missing the point @coirwin was trying to make. There is a (long-standing?) bug where temporarily granted or denied permissions are - in violation of the spec - not reflected in the Permission API but always returned as "prompt". See bug 1924572. Fixing that bug wouldn't change the fact that users are prompted when an LNA is attempted.
In the context of LNA, this bug makes it impossible to detect whether a connection was denied, making the Permissions API useless unless the user checks "Remember my choice".
|
|
||
Comment 8•1 month ago
|
||
I see. Thanks for the reference. I'll make this bug depend on 1924572.
|
Assignee | |
Comment 9•18 days ago
|
||
Could you please see if the issue is fixed now that Bug 1924572 has landed? You can test with the latest version of Nightly which should now report the permission via the permission API correctly.
|
Reporter | |
Comment 10•18 days ago
|
||
I am seeing that the issue has been fixed for most cases, thank you so much! I noticed one case where it looks like the permission isn't correct, though. These are steps to reproduce the case where the permission is showing an incorrect state:
- Attempt to access localhost, to trigger the Firefox permission prompt
- In the Firefox permission prompt, click "Block" without selecting the "Remember my choice for this site" checkbox
- The loopback-network permission state correctly shows the state "denied".
- Reload the same page that attempted to access localhost in step 1, to re-attempt to access localhost from the same site.
- The loopback-network permission state incorrectly shows the state "prompt". Firefox does not show a permission prompt, and the site permissions window shows that the "Access this device" setting is set to "Blocked Temporarily".
In that case, do you think that the permission state in step 5 should show the state "denied" instead of the state "prompt"? Also, do you think that https://bugzilla.mozilla.org/show_bug.cgi?id=1924572 will be released to the stable release channel before the Local Network Access changes are released to the stable release channel?
|
|
Assignee | |
Comment 11•18 days ago
|
||
Temporary block permissions are cleared on user reload so in that case "prompt" is expected after a reload. But when the permission is cleared the website should be able to trigger a new prompt.
Do you have a site / demo where I can reproduce the steps you're describing? It's possible I'm missing something.
Also, do you think that https://bugzilla.mozilla.org/show_bug.cgi?id=1924572 will be released to the stable release channel before the Local Network Access changes are released to the stable release channel?
We're currently discussing this internally.
|
|
Reporter | |
Comment 12•17 days ago
|
||
Thanks for your help with this Emma! When I reloaded the page, the Site Permissions panel still showed that the site was "Blocked Temporarily", but the "loopback-network" permission was shown as "prompt". This seemed like a mismatch between the Site Permissions panel and the "loopback-network" permission. When I reloaded the page, I didn't see that permission prompt appear. The site that I'm testing with is an internal site, but to test it, I'm attempting to access localhost from the browser.
I also did some testing with temporarily allowing the permission, to see if I encounter a similar issue. If I temporarily allow the permission, I'm seeing that the behavior depends on whether the localhost server is running, and the browser is able to successfully connect to localhost.
If the localhost server isn't running, and the browser isn't able to connect to localhost, I'm seeing that the "loopback-network" permission always matches the Site Permissions panel. These are the steps I followed when I was testing this case:
- Attempt to access localhost, to trigger the Firefox permission prompt
- In the Firefox permission prompt, click "Allow" without selecting the "Remember my choice for this site" checkbox
- The loopback-network permission state correctly shows the state "granted"
- The Site Permissions panel shows the site was "Allowed Temporarily"
- Reload the same page that attempted to access localhost in step 1, to re-attempt to access localhost from the same site
- The permission prompt re-appears, prompting the user for whether they would like to allow the access
- The loopback-network permission state correctly shows the state "prompt"
If the localhost server is running, and the browser is able to connect to localhost successfully, I'm seeing that the "loopback-network" permission does not always match what is shown in the Site Permissions panel. These are the steps I followed when I was testing this case:
- Attempt to access localhost, to trigger the Firefox permission prompt
- In the Firefox permission prompt, click "Allow" without selecting the "Remember my choice for this site" checkbox
- The loopback-network permission state correctly shows the state "granted"
- The Site Permissions panel shows the site was "Allowed Temporarily"
- Reload the same page that attempted to access localhost in step 1, to re-attempt to access localhost from the same site
- The permission prompt does not appear, and the Site Permissions panel shows that the site is "Allowed Temporarily"
- The loopback-network permission state is equal to "prompt", which does not match the Site Permissions panel
|
|
Assignee | |
Comment 13•10 days ago
|
||
(In reply to coirwin from comment #12)
Thanks for your help with this Emma! When I reloaded the page, the Site Permissions panel still showed that the site was "Blocked Temporarily", but the "loopback-network" permission was shown as "prompt". This seemed like a mismatch between the Site Permissions panel and the "loopback-network" permission. When I reloaded the page, I didn't see that permission prompt appear. The site that I'm testing with is an internal site, but to test it, I'm attempting to access localhost from the browser.
I've tested this with the latest Nightly 151.0a1 (2026-04-08) (aarch64) and my demo page here: https://playground.emz.run/local-network-access/
A reload does clear the block and the permission transitions are properly reflected via the permissions API. See the console on the bottom of the test page. Do you see the same issue on the test page?
I'll attach a screen recording of my tests.
I also did some testing with temporarily allowing the permission, to see if I encounter a similar issue. If I temporarily allow the permission, I'm seeing that the behavior depends on whether the localhost server is running, and the browser is able to successfully connect to localhost.
If the localhost server isn't running, and the browser isn't able to connect to localhost, I'm seeing that the "loopback-network" permission always matches the Site Permissions panel. These are the steps I followed when I was testing this case:
- Attempt to access localhost, to trigger the Firefox permission prompt
- In the Firefox permission prompt, click "Allow" without selecting the "Remember my choice for this site" checkbox
- The loopback-network permission state correctly shows the state "granted"
- The Site Permissions panel shows the site was "Allowed Temporarily"
- Reload the same page that attempted to access localhost in step 1, to re-attempt to access localhost from the same site
- The permission prompt re-appears, prompting the user for whether they would like to allow the access
- The loopback-network permission state correctly shows the state "prompt"
That's odd, because I don't get any prompt when the localhost server isn't running. The connection fails and the LNA prompt is skipped entirely. I think this is by design currently.
|
|
Assignee | |
Comment 14•10 days ago
|
||
|
|
Assignee | |
Comment 15•10 days ago
|
||
Sunil, if I recall correctly you integrated the lna permissions with the permission API. Is there anything I'm missing that would lead to the behavior described in comment 12 - from the LNA side?
|
||
Comment 16•9 days ago
|
||
(In reply to Emma Zühlcke [:emz] from comment #15)
Sunil, if I recall correctly you integrated the lna permissions with the permission API. Is there anything I'm missing that would lead to the behavior described in comment 12 - from the LNA side?
Hey Emma, We integrated this in 150. 149 it was too late to uplift
|
|
||
Updated•9 days ago
|
|
|
||
Comment 17•9 days ago
|
||
Hey coirwin,
which version are you using for testing
|
|
Assignee | |
Comment 18•9 days ago
|
||
Restoring needinfo for comment 17.
All my testing is based on Nightly.
|
|
||
Comment 19•9 days ago
|
||
That's odd, because I don't get any prompt when the localhost server isn't running. The connection fails and the LNA prompt is skipped entirely. I think this is by design currently.
Thats our current design. We dont prompt users if we are not able to connect to the server (establish TCP connections).
Coirwin, when the server is not running, does this mean the IP port is not reachable at all, or do we establish connections?
Other issue I see is that temproary permissions are not reset on page refereshes. This should not have anything to do with whether the server is running or not. On every page reloads we clear all temproary permission including LNA. Coirwin, how are you attempting to reload the page?
And do you observe this behavior (Firefox not resetting the temporary permissions) everytime you reload or only sometimes?
|
|
Assignee | |
Comment 20•9 days ago
|
||
(In reply to Sunil Mayya from comment #19)
That's odd, because I don't get any prompt when the localhost server isn't running. The connection fails and the LNA prompt is skipped entirely. I think this is by design currently.
Thats our current design. We dont prompt users if we are not able to connect to the server (establish TCP connections).
Coirwin, when the server is not running, does this mean the IP port is not reachable at all, or do we establish connections?Other issue I see is that temproary permissions are not reset on page refereshes. This should not have anything to do with whether the server is running or not. On every page reloads we clear all temproary permission including LNA. Coirwin, how are you attempting to reload the page?
And do you observe this behavior (Firefox not resetting the temporary permissions) everytime you reload or only sometimes?
User reloads clear temporray block permissions. Other temporary permissions are not cleared on reload. Non user reloads (e.g. location.reload()) do not clear temporary permissions.
|
|
Reporter | |
Comment 21•9 days ago
|
||
Thanks again for your help with this Emma and Sunil! I realized that in my previous message, when I thought that there wasn't a localhost server running, I had forgotten to quit one that was also running in the background, which explains why I was still seeing the permission prompt. If I ensure that no server is running, I see the expected behavior, that there is no permission prompt.
Our use case is that during an authentication, the browser reaches out to a desktop app running on the user's machine over localhost. When the the app is running the localhost server, I am still seeing the same behavior, where there is a mismatch in the permission state shown in the Site Permissions Panel UI and the loopback-network state. I am still seeing that after a reload, the Site Permissions Panel UI doesn't show the permission as reset, even though the loopback-network state is reset and is equal to 'prompt'. The page reload is a user reload.
I am testing with version 151.0a1 (2026-04-08) (aarch64). I'm unable to see the same issue on the test page https://playground.emz.run/local-network-access/.
I'll attach a screen recording of the behavior I'm seeing. From the screen recording, is there anything that you think could be causing the different behavior?
|
|
Reporter | |
Comment 22•9 days ago
|
||
This is the screen recording of the behavior I'm seeing.
|
|
Assignee | |
Comment 24•8 days ago
|
||
(In reply to coirwin from comment #22)
Created attachment 9568353 [details]
Firefox_LNA.movThis is the screen recording of the behavior I'm seeing.
Thanks! This was really helpful.
I think I found the issue. I'll submit a patch. Once the patch is in Nightly we can check if it fixes your issue.
|
|
Assignee | |
Comment 25•8 days ago
|
||
Browser-scoped (temporary) permissions were only sent to the content process
at creation time. After a cross-origin navigation that switches processes,
the new process never received them, causing the Permissions API to return
"prompt" instead of "granted".
Transmit browser-scoped permissions for the destination principal in
AboutToLoadDocumentForChild, mirroring what TransmitPermissionsForPrincipal
does for persistent permissions.
|
||
Updated•8 days ago
|
|
||
Comment 26•5 days ago
|
||
|
||
Comment 27•5 days ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 28•4 days ago
|
||
:coirwin, with the patch landed in Nightly, could you please test if the issue has been fixed for you? The latest version of Nightly should include the fix.
|
|
Reporter | |
Comment 29•4 days ago
|
||
I validated that the issue has been fixed. Thank you so much for fixing it!
I know we talked about how if the localhost server isn't running, the permission prompt isn't shown. I noticed that in Chrome, when the localhost server isn't running, the permission prompt is still shown. Would you be open to updating this behavior to match Chrome, so that when the localhost server isn't running, the permission prompt is still shown?
I also noticed that in Chrome, if the browser reaches out to localhost multiple times, the permission prompt is only shown once. In firefox, if the browser reaches out to localhost multiple times, the permission prompt is reloaded each time that the browser attempts to reach localhost. Would you also be open to updating this behavior to match Chrome?
|
|
Assignee | |
Comment 30•3 days ago
|
||
(In reply to coirwin from comment #29)
I validated that the issue has been fixed. Thank you so much for fixing it!
Awesome, so glad to hear!
I know we talked about how if the localhost server isn't running, the permission prompt isn't shown. I noticed that in Chrome, when the localhost server isn't running, the permission prompt is still shown. Would you be open to updating this behavior to match Chrome, so that when the localhost server isn't running, the permission prompt is still shown?
I'll defer to Sunil here who works on LNA.
I also noticed that in Chrome, if the browser reaches out to localhost multiple times, the permission prompt is only shown once. In firefox, if the browser reaches out to localhost multiple times, the permission prompt is reloaded each time that the browser attempts to reach localhost. Would you also be open to updating this behavior to match Chrome?
I think it would make sense to collapse permission requests if it's exactly the same request. It looks like we already do this for some sites permissions. If I got to https://playground.emz.run/repeated-permission-request/ and run the camera test there is still only one prompt. For geolocation I see that we're opening a new one each time, only the last request gets resolved and the old requests are left dangling - not ideal.
Sunil, could we when there are multiple LNA requests of the same type and the same origin queue them all behind one prompt? That is, if there is an existing prompt, chain them to the existing permission request, rather than showing a new prompt every time? I realize that his may need to be addressed in the permission code somewhere, but I'm curious whether we would be fine with this behavior from the LNA side.
|
|
||
Comment 31•2 days ago
|
||
(In reply to Emma Zühlcke [:emz] from comment #30)
I know we talked about how if the localhost server isn't running, the permission prompt isn't shown. I noticed that in Chrome, when the localhost server isn't running, the permission prompt is still shown. Would you be open to updating this behavior to match Chrome, so that when the localhost server isn't running, the permission prompt is still shown?
I'll defer to Sunil here who works on LNA.
We plan to do that in bug 2022790
I also noticed that in Chrome, if the browser reaches out to localhost multiple times, the permission prompt is only shown once. In firefox, if the browser reaches out to localhost multiple times, the permission prompt is reloaded each time that the browser attempts to reach localhost. Would you also be open to updating this behavior to match Chrome?
Sunil, could we when there are multiple LNA requests of the same type and the same origin queue them all behind one prompt? That is, if there is an existing prompt, chain them to the existing permission request, rather than showing a new prompt every time? I realize that his may need to be addressed in the permission code somewhere, but I'm curious whether we would be fine with this behavior from the LNA side.
I also think it makes sense to collapse multiple prompts into one as long as the requesting domain is the same.
|
|
Reporter | |
Comment 32•2 days ago
|
||
Thanks Emma and Valentin! Would you be willing to add those changes before releasing the Local Network Access permission to the stable channel of Firefox?
Description
•