Open Bug 1319080 Opened 8 years ago Updated 2 years ago

Web console should not offer JS evaluation on system-privileged pages unless devtools.chrome.enabled is turned on

Categories

(DevTools :: Console, defect, P3)

Product:
DevTools
Component:
Console
Type:
defect

Tracking

(Not tracked)

People

(Reporter: Gijs, Unassigned)

References

Details

(Keywords: sec-want) 

See bug 1318911.

Right now, if you open e.g. about:preferences (or about:addons, or any other chrome-privileged content page) and use the web console, it will let you evaluate arbitrary JS. This is not a good idea. We should disable the evaluation line here unless the user has toggled devtools.chrome.enabled to true.
We need to let the frontend know if the document that is being loaded is chrome privileged.  Maybe this could be passed into the "tabNavigated" event https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webbrowser.js#1992 and https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webbrowser.js#1952.
Don't we use the debugging APIs to run evaluations? Do they not already expose with what principal stuff is evaluated? From a brief look, it looks like we have an _evalWindow reference to the content window we eval stuff in - that should not allow being set to a window that has chrome privileges if the pref isn't flipped, IMO.
See Also: → 1319382
I don't have access to bug 1318911, so I don't know the precise background behind this request.
But don't we want to completely disable the toolbox?
I imagine we can also gain some privileges from the inspector, but I imagine that's not as easy as pasting some text. (There is also scratchpad)

The main diff between comment 1 and comment 2 is about when/how we display a warning.
comment 1 is about displaying a warning message early on toolbox open or navigation, whereas comment 2 is only after evaluation. A check on evaluation sounds like a safe default to do anyway.
(In reply to Alexandre Poirot [:ochameau] from comment #3)
> I don't have access to bug 1318911, so I don't know the precise background
> behind this request.
> But don't we want to completely disable the toolbox?

If the pref isn't set, I guess so.

> I imagine we can also gain some privileges from the inspector, but I imagine
> that's not as easy as pasting some text. (There is also scratchpad)

Right.
(I've CC'd you on 1318911)
(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to Alexandre Poirot [:ochameau] from comment #3)
> > I don't have access to bug 1318911, so I don't know the precise background
> > behind this request.
> > But don't we want to completely disable the toolbox?
> 
> If the pref isn't set, I guess so.

That gets kind of hairy when opening the toolbox on a non-chrome page then navigating to a chrome page - should the toolbox close?  Then, should it reopen if you navigate backwards to the non-chrome page?

I suppose we could have a 'mode' in the toolbox where it's only showing a warning message and hiding everything else once we navigate to a chrome priv page.
(In reply to Brian Grinstead [:bgrins] from comment #6)
> I suppose we could have a 'mode' in the toolbox where it's only showing a
> warning message and hiding everything else once we navigate to a chrome priv
> page.

Alternatively:

(In reply to Brian Grinstead [:bgrins] from comment #6)
> That gets kind of hairy when opening the toolbox on a non-chrome page then
> navigating to a chrome page - should the toolbox close?

Yes.

>  Then, should it
> reopen if you navigate backwards to the non-chrome page?

No.

That is simple to implement, and IMO really not that bad. There's not a lot of privileged pages around that you could reasonably expect the user to navigate to *in the same tab where they navigate to web content* unless they're being phished or whatever. If web developers love manually typing in about:preferences in their tabs and expecting it to stay open, they can flip the pref or reuse the shortcut that they used to open it in the first place.

That said, we'd need some kind of messaging to the user when the toolbox closes, and so the implementation difficulty might then end up being materially different from implementing a 'mode' - depends on how hard it is to change the toolbox to support that.
(In reply to :Gijs Kruitbosch from comment #7)
> That said, we'd need some kind of messaging to the user when the toolbox
> closes
... or refuses to open if you use the shortcut / menuitem.
about:newtab is still privileged, isn't it?

That one would be problematic. We already had to workaround because of it being running in the parent process. I wish we could prevent having yet another specifics.

I imagine we could easily start with a simple rejection from the webconsole actor to evaluate anything against a system principal. That sounds like a check we want no matter what the overall frontend UX is.
(In reply to Alexandre Poirot [:ochameau] from comment #9)
> about:newtab is still privileged, isn't it?

Yes.

> That one would be problematic.

Why? You can't go back to about:newtab. It doesn't go into session history. This breaks opening the toolbox immediately after opening a new tab in order to leave it open for the next page, I guess? Not sure why you'd want to do that rather than just open it when your page is open...

> I imagine we could easily start with a simple rejection from the webconsole
> actor to evaluate anything against a system principal. That sounds like a
> check we want no matter what the overall frontend UX is.

I agree.
(In reply to :Gijs Kruitbosch from comment #10)
> (In reply to Alexandre Poirot [:ochameau] from comment #9)
> > about:newtab is still privileged, isn't it?
> 
> Yes.
> 
> > That one would be problematic.
> 
> Why? You can't go back to about:newtab. It doesn't go into session history.
> This breaks opening the toolbox immediately after opening a new tab in order
> to leave it open for the next page, I guess? Not sure why you'd want to do
> that rather than just open it when your page is open...

There was a long standing / highly duped bug where the toolbox would close when going from newtab to another page, so people are doing it (bug 1068400).  My guess for one use case is that if you want to start capturing network traffic before loading your page you would open toolbox on the new tab then go the page.

> > I imagine we could easily start with a simple rejection from the webconsole
> > actor to evaluate anything against a system principal. That sounds like a
> > check we want no matter what the overall frontend UX is.
> 
> I agree.

We could do that - and even return an error message that will show in the console in response.  There are still other cases where evaluation could happen (i.e. watch statements when paused in debugger), so it might be best to do the check inside debugger execution rather than the web console actor.
So I think there's a few options here:

1) Do a rejection from webconsole actor / debugger API when executing code on a chrome page without the chrome debugging pref set.  Return it as an error message like: "Cannot execute chrome privileged script without devtools.chrome.enabled set"
2) Prevent opening the toolbox at all on chrome priv pages when devtools.chrome.enabled is false, and close it if it was already opened when navigating to one.  This will need some UX/product thinking, especially considering the about:home situation as discussed in Comment 11.
3) Create an overlay / unusable mode in the toolbox when entering a chrome priv pages when devtools.chrome.enabled is false.  This would have the benefit of (a) re-allowing toolbox access when navigating away from the chrome priv page, (b) more space for messaging, and (c) the toolbox would still open when doing the key shortcut / context menu items.  But it would require working inside the toolbox around unloading all the opened tools when entering the mode so you don't accidentally hit a breakpoint while in the unusable mode.  It could be flexible enough though to allow certain tools (inspector) to open, but not the debugger/console.

If we think (1) is enough to resolve this issue satisfactorily then let's do that - it's much easier than the other options and will cause less user confusion (esp around about:home).

What are the other security threats inside the toolbox besides being able to run code via the debugger API?  In the inspector you could edit HTML and inject a script tag that way, but that's a lot harder to explain and trick someone into doing than pasting something into the console.
There's a fourth option also I didn't mention which is the initial request in this bug: detect when we are on a chrome priv page without devtools.chrome.enabled set, and hide the input line in the console.  It has similar pros/cons to option 1 above, although it may be less obvious to the user why it isn't working.
(In reply to Brian Grinstead [:bgrins] from comment #13)
> There's a fourth option also I didn't mention which is the initial request
> in this bug: detect when we are on a chrome priv page without
> devtools.chrome.enabled set, and hide the input line in the console.  It has
> similar pros/cons to option 1 above, although it may be less obvious to the
> user why it isn't working.

We could do (1) and then update the browser console to not be a special snowflake? :-)


Personally, I would be OK with (1), though note that we should make sure that it also applies to the console when opened in/from other tools with [esc]. (I guess given how it's implemented, it should, but I figured having it written down in the bug was not a bad thing...)
Jim, we are considering ways to prevent users from being tricked into running code in the console when on a chrome privileged 'about' page.

One thing that's been discussed is preventing executing code through the debugger API (at least executeInGlobal, executeInGlobalWithBindings, frame.eval, frame.evalWithBindings) and having those methods return an error so that when you typed some value in the console you would get something like:

> 1+1
"Error: Cannot execute chrome privileged script without devtools.chrome.enabled set"

So the debugger would hit this condition if it detected that the window is chrome privileged and devtools.chrome.enabled is false.

Would that be relatively easy/doable from the Debugger end?  Can you think of any unintended consequences to doing that?  This could also be handled in the webconsole actor before requesting evaluation but it seems more secure / future proof to handle it inside the debugger.
Flags: needinfo?(jimb)
(In reply to :Gijs Kruitbosch from comment #14)
> (In reply to Brian Grinstead [:bgrins] from comment #13)
> > There's a fourth option also I didn't mention which is the initial request
> > in this bug: detect when we are on a chrome priv page without
> > devtools.chrome.enabled set, and hide the input line in the console.  It has
> > similar pros/cons to option 1 above, although it may be less obvious to the
> > user why it isn't working.
> 
> We could do (1) and then update the browser console to not be a special
> snowflake? :-)

Happy to remove a special snowflake

> Personally, I would be OK with (1), though note that we should make sure
> that it also applies to the console when opened in/from other tools with
> [esc]. (I guess given how it's implemented, it should, but I figured having
> it written down in the bug was not a bad thing...)

Yes that would apply to the console in any mode, and also scratchpad
If we're going to do this with Debugger modifications, I think there are two changes necessary.

First, we should be able to tell a given Debugger, "We have no intention of ever using you to run privileged debuggee code." Then that Debugger can refuse to accept privileged globals as debuggees.

Second, Debugger should refuse to run code in a non-debuggee compartment. That it will do so now is a preexisting bug. This won't require changes to Debugger.Frame methods, since Debugger already refuses to create D.F's for non-debuggee frames (and neuters D.Fs whose compartments are removed as debuggees), but it will require changes to Debugger.Object.prototype.executeInGlobal{WithBindings}, and to D.O.P.call and D.O.P.apply. The term you're looking for is "invocation functions": Debugger API functions that can cause debuggee code to run.

On the server side:

First, we should create most Debuggers with this restriction in place. That will act as a backstop: if the server somehow attempts an evaluation it shouldn't, maybe Debugger will throw an exception that the server wasn't prepared for and we'll have a bad user experience, but at least we won't run privileged JS.

But that will require the server to NOT restrict Debuggers for the browser console, the add-on debugger, the chrome debugger, and so on. So, Second, we'll need to get that right too.

Third, we need to make the actors catch and report these errors properly to the client.

Fourth, we need to make the client react to the errors helpfully.

The Debugger stuff seems straightforward, assuming we can readily distinguish the sorts of JSPrincipals we want to accept from those we want to reject. The server and client stuff is just plumbing, right?
Flags: needinfo?(jimb)
Some notes from a conversation with bz about using JSPrincipals to filter Debugger debuggees:

- Talked with bz and John-Galt about using principals to filter debuggees.

  - bz pointed out that one could also have a bit on the compartment indicating
    whether it should be acceptable to debug. There was some discussion in bug
    1316480 in which bholley said he wasn't fond of the idea of duplicating
    information in flags that is already available from the principals.

  - bz pointed out that workers don't have any principals at all. Rather, we
    have boolean flags indicating whether the worker is system. The
    debugger/worker distinction is just implemented by the wrapper policy, which
    is driven by the global type (we think).

  - It wouldn't be too hard to introduce principals to workers. There'd be two:
    "debugger" and "worker", where the latter does not subsume the former. The
    debugger and all its sandboxes would use the "debugger" principal, and the
    worker content global would use the "worker" principal.

  - On the main thread, we have principals for webextensions that are separate
    from the system principal. (Non-webextension add-ons use the system
    principal.) Then, webextensions can create content scripts, which run with a
    principal that subsumes that of whatever content the script wants to mess
    with.

  - We could create a principal that subsumes all content, but no privileged
    code. Then we could use that as a filter for debuggees, telling the Debugger
    to only accept debuggees whose principal is subsumed by the given one.
un-hiding: doesn't reveal details about bug 1318911 and most of the people who would try to take advantage of this already know about chrome-privileged pages. 

The feature is useful for chrome debugging and testing, but definitely a specialized niche use-case that doesn't need to be enabled by default.
Group: firefox-core-security
Keywords: sec-want
Product: Firefox → DevTools
Priority: -- → P3
(In reply to Brian Grinstead [:bgrins] from comment #12)
> 2) Prevent opening the toolbox at all on chrome priv pages when
> devtools.chrome.enabled is false, and close it if it was already opened when
> navigating to one.  This will need some UX/product thinking, especially
> considering the about:home situation as discussed in Comment 11.

about:home and about:newtab are now unprivileged, so this is much easier than it was 2 years ago (ie the "open new tab, open toolbox, navigate" steps would continue to work if we did this). It seemed like technically, this was the easiest option. I could probably write a patch if someone pointed me to where the toolbox hooks into tab URL changes (I assume it must do somehow because all the tools/views get updated), assuming that seemed like a viable option?
Flags: needinfo?(bgrinstead)
(In reply to :Gijs (he/him) from comment #23)
> (In reply to Brian Grinstead [:bgrins] from comment #12)
> > 2) Prevent opening the toolbox at all on chrome priv pages when
> > devtools.chrome.enabled is false, and close it if it was already opened when
> > navigating to one.  This will need some UX/product thinking, especially
> > considering the about:home situation as discussed in Comment 11.
> 
> about:home and about:newtab are now unprivileged, so this is much easier
> than it was 2 years ago (ie the "open new tab, open toolbox, navigate" steps
> would continue to work if we did this). It seemed like technically, this was
> the easiest option. I could probably write a patch if someone pointed me to
> where the toolbox hooks into tab URL changes (I assume it must do somehow
> because all the tools/views get updated), assuming that seemed like a viable
> option?

Going to ni? Alex to confirm that this is something we'd still want to take on, and also to sanity check my suggestions here. By the way, is there an easy way to check whether a tab's content document is chrome from the UI? Because we could prevent initial open in the first place from showToolbox (https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools.js#454).

The actual permission check could happen when sending the final "tabNavigated" event from the server side over RDP at: https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/server/actors/targets/browsing-context.js#1389-1395. At that point we would have access to the actual document and could check document.nodePrincipal.isSystemPrincipal or whatever and pass it as a boolean.

Then the target on the frontend would receive that event and emit "navigate" to the toolbox (https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/target.js#562), which could either
1) directly call gDevTools.closeToolbox with itself (https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools.js#582)
2) Pass along the boolean about whether this is chrome and have the toolbox check the pref and close itself if needed in response to that event (https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/toolbox.js#190)
Flags: needinfo?(bgrinstead) → needinfo?(poirot.alex)
There's also a question as to how we message what happened to the user. I think I'd be confused if I had devtools opened on a page, then navigated to about:preferences or whatever and it just went away. Maybe that's not so bad since it should be rare nowadays, but something to consider.
(In reply to Brian Grinstead [:bgrins] from comment #24)
> (In reply to :Gijs (he/him) from comment #23)
> > (In reply to Brian Grinstead [:bgrins] from comment #12)
> > > 2) Prevent opening the toolbox at all on chrome priv pages when
> > > devtools.chrome.enabled is false, and close it if it was already opened when
> > > navigating to one.  This will need some UX/product thinking, especially
> > > considering the about:home situation as discussed in Comment 11.
> > 
> > about:home and about:newtab are now unprivileged, so this is much easier
> > than it was 2 years ago (ie the "open new tab, open toolbox, navigate" steps
> > would continue to work if we did this). It seemed like technically, this was
> > the easiest option. I could probably write a patch if someone pointed me to
> > where the toolbox hooks into tab URL changes (I assume it must do somehow
> > because all the tools/views get updated), assuming that seemed like a viable
> > option?
> 
> Going to ni? Alex to confirm that this is something we'd still want to take
> on, and also to sanity check my suggestions here. By the way, is there an
> easy way to check whether a tab's content document is chrome from the UI?

document.nodePrincipal should be able to tell you, if you have access to the 'real' document object. If you mean over the debugging protocol, I don't know... but IIRC the toolbox code has access to the toplevel chrome window, and presumably the <browser> for which we're attaching, in which case you can check browser.contentPrincipal instead.

For either principal object, a simple `isSystemPrincipal` check should do. 

> Because we could prevent initial open in the first place from showToolbox
> (https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools.
> js#454).
> 
> The actual permission check could happen when sending the final
> "tabNavigated" event from the server side over RDP at:
> https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/server/actors/targets/
> browsing-context.js#1389-1395. At that point we would have access to the
> actual document and could check document.nodePrincipal.isSystemPrincipal or
> whatever and pass it as a boolean.

Right.


(In reply to Brian Grinstead [:bgrins] from comment #25)
> There's also a question as to how we message what happened to the user. I
> think I'd be confused if I had devtools opened on a page, then navigated to
> about:preferences or whatever and it just went away. Maybe that's not so bad
> since it should be rare nowadays, but something to consider.

This makes sense to me - we could show a (tab?)modal alert. It doesn't need to be fancy (IMO) given it's an edgecase.
(In reply to :Gijs (he/him) from comment #26)
> (In reply to Brian Grinstead [:bgrins] from comment #24)
> > Going to ni? Alex to confirm that this is something we'd still want to take
> > on, and also to sanity check my suggestions here. By the way, is there an
> > easy way to check whether a tab's content document is chrome from the UI?
> 
> document.nodePrincipal should be able to tell you, if you have access to the
> 'real' document object. If you mean over the debugging protocol, I don't
> know... but IIRC the toolbox code has access to the toplevel chrome window,
> and presumably the <browser> for which we're attaching, in which case you
> can check browser.contentPrincipal instead.

I was wondering if we could check from the parent process to so we don't ever attempt to open the toolbox (and we could also disable menu items, etc) Because otherwise we'd have to be careful to avoid a weird thing where the toolbox opens for a second, then realizes it shouldn't be, then closes itself.

Although now that I think about it: do we ever run chrome priv windows in the content process? Because if we are only talking about pages like about:preferences then we should have access to the actual document from the parent process to do a permission check.
(In reply to Brian Grinstead [:bgrins] from comment #27)
> (In reply to :Gijs (he/him) from comment #26)
> > (In reply to Brian Grinstead [:bgrins] from comment #24)
> > > Going to ni? Alex to confirm that this is something we'd still want to take
> > > on, and also to sanity check my suggestions here. By the way, is there an
> > > easy way to check whether a tab's content document is chrome from the UI?
> > 
> > document.nodePrincipal should be able to tell you, if you have access to the
> > 'real' document object. If you mean over the debugging protocol, I don't
> > know... but IIRC the toolbox code has access to the toplevel chrome window,
> > and presumably the <browser> for which we're attaching, in which case you
> > can check browser.contentPrincipal instead.
> 
> I was wondering if we could check from the parent process to so we don't
> ever attempt to open the toolbox (and we could also disable menu items, etc)
> Because otherwise we'd have to be careful to avoid a weird thing where the
> toolbox opens for a second, then realizes it shouldn't be, then closes
> itself.
> 
> Although now that I think about it: do we ever run chrome priv windows in
> the content process? Because if we are only talking about pages like
> about:preferences then we should have access to the actual document from the
> parent process to do a permission check.

Both for remote and non-remote tabs, <browser> bindings have a `contentPrincipal` property that contains the content (remote or not) toplevel document's principal, so yes we can check this in the parent process.
(In reply to :Gijs (he/him) from comment #28)
> Both for remote and non-remote tabs, <browser> bindings have a
> `contentPrincipal` property that contains the content (remote or not)
> toplevel document's principal, so yes we can check this in the parent
> process.

In that case I wonder if we should handle this all outside of the target/RDP from gDevToolsBrowser (devtools-browser.js). That would make it easier to update menu states and whatnot.

For example:
- Have a function that given a tab, checks [principle + pref] and sets the command disabled state accordingly to handle menu state, and closes a currently opened toolbox if necessary.
- Call that function both when the selected tab changes and when the location of a <browser> changes.

This could be wired up somewhere around registerBrowserWindow (https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools-browser.js#449)
(In reply to Brian Grinstead [:bgrins] from comment #24)
> Going to ni? Alex to confirm that this is something we'd still want to take
> on, and also to sanity check my suggestions here.

This plan sounds like the most complete one. Ensuring that we really cover all the cases,
including navigating to a privileged page.

> By the way, is there an
> easy way to check whether a tab's content document is chrome from the UI?
> Because we could prevent initial open in the first place from showToolbox
> (https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools.
> js#454).

If we do just that, we will only cover opening against a privileged doc, not navigating to.
But that sounds like a good and easy start. Assuming we at least display an alert or something.
A silent inaction would be confusing!

> The actual permission check could happen when sending the final
> "tabNavigated" event from the server side over RDP at:
> https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/server/actors/targets/
> browsing-context.js#1389-1395. At that point we would have access to the
> actual document and could check document.nodePrincipal.isSystemPrincipal or
> whatever and pass it as a boolean.

Yes, that the best way to convey such information.
Note that navigate is sent on "load" event, so there is in theory a possible race
where you might be able to do something before this event.
It is hard to know if that's possible in practice.

You can try passing such information from the tabNavigated/start event,
which happen very early during location change. I think that's the earliest possible event.
But I'm expecting the window object to still refer to the previous doc:
  https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/devtools/server/actors/targets/browsing-context.js#1349-1354

> Then the target on the frontend would receive that event and emit "navigate"
> to the toolbox
> (https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/target.
> js#562), which could either
> 1) directly call gDevTools.closeToolbox with itself
> (https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/devtools.
> js#582)
> 2) Pass along the boolean about whether this is chrome and have the toolbox
> check the pref and close itself if needed in response to that event
> (https://searchfox.org/mozilla-central/rev/
> 448f792f9652d29daebdad21bf50b03405e40a45/devtools/client/framework/toolbox.
> js#190)

Looks good, still assuming there is a notification made to the user rather than just having the toolbox to disappear.
alert/dialog sounds good to me, but well, I'm not a UX designer at all.
Flags: needinfo?(poirot.alex)
(In reply to Brian Grinstead [:bgrins] from comment #29)
> (In reply to :Gijs (he/him) from comment #28)
> > Both for remote and non-remote tabs, <browser> bindings have a
> > `contentPrincipal` property that contains the content (remote or not)
> > toplevel document's principal, so yes we can check this in the parent
> > process.
> 
> In that case I wonder if we should handle this all outside of the target/RDP
> from gDevToolsBrowser (devtools-browser.js). That would make it easier to
> update menu states and whatnot.
> 
> For example:
> - Have a function that given a tab, checks [principle + pref] and sets the
> command disabled state accordingly to handle menu state, and closes a
> currently opened toolbox if necessary.
> - Call that function both when the selected tab changes and when the
> location of a <browser> changes.

While it looks like a nifty UX behavior to have. I'm not really sure this edge case justify spending any CPU cycle on every tab change and location change for everyone.

(In reply to Brian Grinstead [:bgrins] from comment #13)
> There's a fourth option also I didn't mention which is the initial request
> in this bug: detect when we are on a chrome priv page without
> devtools.chrome.enabled set, and hide the input line in the console.  It has
> similar pros/cons to option 1 above, although it may be less obvious to the
> user why it isn't working.

I'm not sure this is still something anyone want to to do, but the input should be disabled with a tooltip rather than hidden to avoid confusions.
We could apply the same pattern to the toolbox here, but that would surely be some more work to do it right as we are not talking about just an input field.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:nchevobbe, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(nchevobbe)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(nchevobbe)
You need to log in before you can comment on or make changes to this bug.