Context menu isn't invocable at `about:preferences`.
Categories
(Firefox :: Settings UI, defect)
Tracking
()
People
(Reporter: zn7esutb, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
I secondary-clicked (or invoked the ContextMenu key).
Actual results:
Nothing appeared.
Expected results:
A context menu should have appeared, so that I could utilize the items in it (like "Select All", or extension actions, like SingleFile's ability to save the page).
|
||
Comment 1•3 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Settings UI' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
Reporter | |
Comment 2•3 months ago
|
||
|
|
||
Comment 3•3 months ago
|
||
The severity field is not set for this bug.
:jhirsch, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 4•3 months ago
|
||
Works for me when right clicking e.g. the secondary headers like "Startup" or "Import Browser Data".
Doesn't work in some other places.
(In reply to Beedell, Roke, Julian Lockhart from comment #0)
or extension actions, like SingleFile's ability to save the page
I would be surprised if this worked even once the menu opens. (Arguably, it might be a security issue if it did.)
|
|
Reporter | |
Comment 5•3 months ago
|
||
or extension actions, like SingleFile's ability to save the page
I would be surprised if this worked even once the menu opens. Arguably, it might be a security issue if it did.
gijskruitbosch+bugs@gmail.com, extensions can be made to operate on restricted pages. That's standard functionality, as long as the user is familiar with about:config.
|
|
||
Comment 6•3 months ago
|
||
(In reply to Beedell, Roke, Julian Lockhart from comment #5)
or extension actions, like SingleFile's ability to save the page
I would be surprised if this worked even once the menu opens. Arguably, it might be a security issue if it did.
Gijs, extensions can be made to operate on restricted pages. That's standard functionality, as long as the user is familiar with
about:config.
I'm assuming you're talking about extensions.webextensions.restrictedDomains? If so, I don't think that'll make any difference to about:preferences. Please clarify.
I just checked and the extension menu shows up when selecting the headers I mentioned, but none of the actions work (even after clearing restrictedDomains). This is in line with my expectation. The settings page loads in the main Firefox process (like the tabstrip, navigation toolbar etc.) and extensions running code in that process would be a problem.
|
|
Reporter | |
Comment 7•3 months ago
|
||
I'm assuming you're talking about
extensions.webextensions.restrictedDomains? If so, I don't think that'll make any difference toabout:preferences. Please clarify.
Indeed. Apologies.
I just checked and the extension menu shows up when selecting the headers I mentioned, but none of the actions work (even after clearing restrictedDomains). This is in line with my expectation. The settings page loads in the main Firefox process (like the tabstrip, navigation toolbar etc.) and extensions running code in that process would be a problem.
Without allowing extensions to operate on that page, any that are useful for accessibility purposes - Dark Reader, for instance - don't function. That wouldn't be as much of a problem if https://bugzilla.mozilla.org/show_bug.cgi?id=1888225#c0 were resolved, but it isn't.
Irrespective, considering that I can write my own extension (which I would evidently wholly trust) it seems incredibly strange that there is simply no mechanism to allow it to operate on such pages - all the extensions I use would be just as useful there.
|
|
||
Comment 8•3 months ago
|
||
(In reply to Beedell, Roke Julian Lockhart from comment #7)
Irrespective, considering that I can write my own extension (which I would evidently wholly trust) it seems incredibly strange that there is simply no mechanism to allow it to operate on such pages - all the extensions I use would be just as useful there.
There is a mechanism on nightly / devedition - https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#adding-experimental-apis-in-privileged-extensions . That would allow you to write privileged JS and interface it into webextensions. But it's likely not trivial to do what you want.
There are pretty good reasons that there are some boundaries around what extensions can and cannot do: not having a boundary creates security issues (and the people who can write their own extensions and run only those is tiny compared to the overall Firefox population, and we have to keep those folks safe, too!). Not having a boundary also means that things break every time Firefox changes in ways that would break webextensions - the API boundary exists in part to offer a stable API, which we can't do if we just give extensions access to everything (I don't know how long you've used Firefox and how familiar you are with the history here - but that's how extensions used to work and people were upset every time things broke, which was frequently, because there didn't used to be an API boundary).
There is no way to allow webextensions to interact with the Firefox settings page without giving them access to everything (ie JS on that page can do pretty much anything Firefox can do, so if the add-on can run any JS on that page, it can do whatever it likes to Firefox).
|
|
Reporter | |
Comment 9•3 months ago
|
||
gijskruitbosch+bugs@gmail.com, I see your point. Those definitely would cause more headaches for you poor triagers. However, would an about:config preference to explicitly whitelist an extension be undesirable? Especially considering that extensions.webextensions.restrictedDomains already exists for a very similar purpose. I imagine it would be fairly inherently obvious to someone tinkering with such preferences that they're not designed to be reliable/stable?
|
|
||
Comment 10•3 months ago
|
||
(In reply to Beedell, Roke Julian Lockhart from comment #9)
gijskruitbosch+bugs@gmail.com, I see your point. Those definitely would cause more headaches for you poor triagers. However, would an
about:configpreference to explicitly whitelist an extension be undesirable? Especially considering thatextensions.webextensions.restrictedDomainsalready exists for a very similar purpose. I imagine it would be fairly inherently obvious to someone tinkering with such preferences that they're not designed to be reliable/stable?
You might be surprised how many people run Firefox with a set of prefs that someone on the internet told them would make it faster / safer / more private / more secure. So I'm not sure that I agree it would be "inherently obvious" to people changing such preferences that it might not be entirely safe for them to do so.
The other problem with this idea is that users are not the only people who can change about:config preferences. bug 1538008 has some example history around how prefs can be abused by malicious actors (there are other examples). Supporting simple prefs that effectively enable privilege escalation (which is what running extension code inside about:preferences would amount to) is risky at best. We're constantly working to make it harder for people to leverage sandbox escapes into "real" remote code execution, and this would go in the opposite direction. So no, I don't think we'd do that.
|
|
Reporter | |
Comment 11•3 months ago
|
||
Thanks for the explanations, gijskruitbosch+bugs@gmail.com. They're comprehensive. I understand now.
Description
•