[Reverted] Fixing keyboard navigation in Inspector Rules view

Posted by

Nicolas Chevobbe

–

January 11, 2024

2024-02-03 Update

Given the feedback we received on this blog post and in other channel, we’re reverting this and the Enter key will work the way it was previously. The fix is already in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06.
If you liked the “new” behavior that we were trying to introduce, you can enable it by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false. We also plan to expose this option in the settings UI (#1878490).

The new focus indicator style we introduced also revealed a couple issues that we’ll tackle in next releases:

The closing bracket is focusable, and hitting Enter or Space while it has the focus will add a new property to the rule. This is definitely not self-explanatory, so we’ll try to make it better (#1876676). Note that you can still click anywhere in the rule where there no item to add a new property, and we’ll keep it that way.
It’s hard to tell when an element is focused whether it’s being edited or not (#1876674). This one is a bit trickier, as we want to limit layout shift when toggling edit mode, and we want a consistent focus indicator. We’ll experiment various solutions to find what feels right.

Finally, I wanted to emphasize that we do want to hear (hopefully constructive) feedback from you, web developers, so we can make better choices to support you. You can do that on Mastodon, Twitter, Discourse, Element and of course, on Bugzilla, our bug tracker (you can connect with a Github account). We’re a very small team, we definitely don’t know everything and we can’t test all the new libraries, frameworks and workflows that are created. So we really rely on your feedback and bug reports to make Firefox Developer Tools better, faster and more solid.

2024-03-15 Update

Starting Firefox 124, you can control the Enter key behavior from the settings panel.

The Firefox DevTools setting panel, showing the Inspector section.
There's a checkbox with the following label: "Focus next input on Enter"
A tooltip is displayed, with the following text: "When enabled, hitting the Enter key when editin a selector, a property name or value will move the focus to the next input."

Original Article

Starting Firefox 122, when editing a selector, a property name or a property value in the Inspector, the Enter key will no longer move the focus to the next input, but will validate what was entered and focus the matching element (#1861674). You can still use Ctrl + Enter (Cmd + Enter on macOS) or Tab to validate and move the focus to the next input.

Firefox DevTools Inspector panel. The Rules view is highlighted and shows a couple rule. One of them has the following property `background-color: #000000`. The `#000000` element has a focus indicator around it, a thick blue border. — The Rules view after the `background-color` value was modified and validated with the `Enter` key. The value element is now focused (hence the focus indicator). Previously, this will have enabled the edit mode on the `color` property.

Why?

When you click on a selector, a property name or a property value, a text input appears to modify the underlying value. Previously, when the user hit Enter, we advanced the editor to the next editable property, which is also directly turned into a text input. This behavior seems to exist since the Firebug days and every browsers Developers Tools implemented it, as it allowed to quickly edit multiple properties in a rule without leaving the keyboard.

In 2023 the Accessibility team at Mozilla ran an audit on DevTools and created a list of issues that needed to be fixed. One of the area we focused on was the Inspector, and especially keyboard navigation in the Rules view. As we were fixing those issues, making the keyboard navigation better, it struck us that it was unnecessary hard to exit “edit” mode with the keyboard only; the only way to do this was with the Esc key, but that also reverts any changes that was made in the text input! What I ended up doing most of the time is do validate with Enter, which moves the focus to the next input, then hit Esc to opt-out of the edit mode.
This extra step (and the unnecessary CPU cycles that goes with it) doesn’t seem justified when we already have other keyboard shortcut that can validate the input and move to the next one: Tab, which already existed and works across all browsers, and Ctrl (Cmd on macOS) + Enter, which we added based on user feedback (#1873416).

On top of that, this could be confusing for non-sighted user. In the web, you navigate through the inputs of a form with the Tab key, and Enter should validate the form. The change we made bring the Rules view behavior closer to regular forms, which should be more comfortable for non-sighted user, as well as people with no prior experience of the tool.
For those who’ve been using it for years or even decades (and all the DevTools team members fall onto that category), we know this is going to take a bit to get used to. We did fix some of the issues we saw in Tab and “edit mode” navigation, so when you hit Enter but wanted the focus to move to the next input, you should be able to hit Tab and then Enter to activate edit mode on the field you wanted to modify.

Again, we know this could be frustrating in the beginning, but, for us, the advantages this brings to the table makes it worthwhile, and I hope to you to.

Nicolas Chevobbe

111 responses

pd

January 11, 2024

Seems like a simple case for an about:config toggle option.

As much as everyone wants to cater for all user’s abilities, it’s not necessarily fair to do so at the expense of a larger majority of users for a marginal benefit to very few users. In particular if the changes are only prompted by presumptuous, generic guidelines rather than actual input from, as this article references, non-sighted users, for example. Although it’s not necessarily easy to gather a representative perspective from any particular user group. Therefore flexibility has to be offered but in suspect the DevTools team may have opted for a blunt change, rather than an about:config toggle, because the latter was perceived to be the harder option to maintain, which would be quite disappointing if true.

Blanket so-called a11y surveys of highly functional interfaces used by millions tend to take the perspective that changes are necessary for the benefit of the relative few at the expense of vast majority.

Completely unenviable minefield scenario.

Reply
1. Nicolas Chevobbe
  
  January 11, 2024
  
  Hello pd,
  
  > Seems like a simple case for an about:config toggle option.
  
  It would have been very easy to do (or even a proper item in DevTools Settings panel), so this was not decided based on the complexity of the task. I also didn’t hesitate long because, as stated in the article, the alternative to keep the same behavior is simply to use another key, which feels okay, especially given that’s how things work natively in HTML.
  In the end, I wanted to avoid a setting because I do think this is a better behavior than what used to exist, for every keyboard user, not only non-sighted ones.
  
  Eventually, we might add a setting, it’s easy, but it’s not our preference.
  
  Finally, accessibility improvement is not something that benefit “just a few” (see https://a11ymyths.com/), and the issues we were fixing in DevTools last quarter (this one included), where not driven by a11y surveys, but by a thorough audit of accessibility experts at Mozilla (which does include screen-reader users and even screen-reader software creator).
  
  Reply
  1. Cy K. N.
    
    January 23, 2024
    
    > “just a few”
    
    About 20 years ago I wrote a shareware program for Windows in C++ with MFC to control parameters of a complex and quite unique hardware synthesizer, Yamaha FS1R, which was in production for mere 2 years. I bought mine used; it wasn’t made any more. The synth was a 1U rack unit (19-inch rack form factor is as common in musical hardware as it is in servers or networking), and if you wanted to build your own unique sound, all you had was a tiny 2-line LCD, rotary encoder, Enter and Back buttons *and tables in the printed manual*, as it couldn’t even display FM matrices, only their numbers to look up in the book. I was surprised how large the left nav tree grew while laying out a prototype, and each item selected a whole editing page on the right (think Windows Explorer), so many parameters there were—Wikipedia says “over 2000”, seems quite on the spot. A true geek machine, which likely explains it commercial failure, and I didn’t realise that it was so complex when I started my project. But I wanted a convenient editor for myself, and, of course, the parameters repeated for voices, then for sub-groups within each voice, and so on; it was doable and not so hard with right abstractions. I loathe the UIs with “realistically” looking round knobs and linear sliders, awkward to manipulate with mouse and keyboard, unlike physical things, and non-standard, so everyone invents their own, also invariably awkward set of gestures, at the worst but commonly mouse-only… I only used Windows standard numeric up-downs for numbers, drop-downs for fixed selection menus, and that was it.
    
    Uh, no. That was *almost* it. In most synths there is always a set of parameters that go together, controlling so-called envelope, which is a function of real time with certain parameters that you can alter to shape it, e.g., how much and how quickly it swells and then drops when you press a note, and how fast it decays when you release the key. In this very complex synth these parametrised envelopes were all over the place: for each operator volume, for inter-operator feedback, for a host of parameters of every filter… I wrote a special control for it, showing a little graph with a few handles corresponding to the parameters you can vary in hardware, which you could either drag or cycle with the space and and shift with keyboard arrows in the direction the parameters permit. I did all the drawing and mouse/keyboard interaction, but subclassed one of Windows controls to get the Tab or Alt+letter navigation across the page for free. I didn’t think about accessibility at all, but the side effect was that the thing was visible to screen readers as an empty text box or like. Useless but known to be present. I even received a few cheques in the post, and then… Then it began. I was receiving the feature request from blind users who were asking to make this envelope control accessible, some days more than once! Counting the cheques, I realised that about every fifth one of my users had to use screen reader! Of course I added that function with the help of my users who shared and evaluated different ideas, as I was completely naïve about accessibility. I spent some time on getting it right, but thoroughly learned a good thing to have under your belt.
    
    My sample was of course skewed. It’s well known that there are much more blind folks in musicianship than in an average vocation, and not unlikely more than in any other. Many people were just evaluating it, or used without paying‐the software didn’t degrade, just popped up a nag box every 45 minutes; I hadn’t planned to get money off it, but had to recover for at least some of the ungodly time I spent on it with its 2000+ editable parameters, so this was a quick afterthought. I later reduced the nagging pop-up to show up once upon closing the program if screen reader was used to interact with it, which did perhaps count as an accessibility feature, too. 🙂
    
    This was how I learned my lesson to regard accessibility seriously and design for it early, and that “just a few” is a myth indeed. This alone was worth it.
    
    * * *
    
    BTW, the new behaviour of Enter in the Inspector is much better—thanks for the change! The Enter-Esc arpeggio was awkward, and I could even do it with one hand when mousing up colours.
    
    Reply
  2. Talia Hatfield
    
    January 24, 2024
    
    Re: Nicolas Chevobbe
    
    I am fully on board with accessible defaults, but I am not on board with taking away options. Did you do any kind of studies, research, questionnaires, or anything to see that it would be better for ALL users, or was this just an arbitrary decision? Even if you found that it would be better for most users, though, I don’t think that’s enough reason to not implement an about:config for this. People should have the ability to customize their own browser to make things more convenient for them.
    
    The idea that this is better because tab is used for moving between form fields in native HTML ignores the fact that adding CSS declarations in the Dev tools doesn’t feel like using a form. It feels much more like adding a line in your file, which is done using the enter button.
    
    Reply
    1. Nicolas Chevobbe
      
      January 26, 2024
      
      We may add an option in about:config/in the settings panel
      
      > CSS declarations in the Dev tools doesn’t feel like using a form. It feels much more like adding a line in your file
      
      one could argue that when you hit Enter on a property name, it’s wasn’t adding a line but moving the edit to the value, which isn’t what you’d expect in any Editor.
      
      Reply
  3. Vallek
    
    January 26, 2024
    
    >I wanted to avoid a setting because I do think this is a better behavior than what used to exist, for every keyboard user
    
    You wanted to avoid adding choice for devs while breaking the way it works since Firebug because YOU think it’s better for everyone? How delusional are you pal? And again covering behind accessibility shield (also on behalf of a lot of people as per usual).
    
    >Eventually, we might add a setting, it’s easy, but it’s not our preference.
    wow
    
    And then you wonder why Firefox is loosing millions of users. That’s why.
    
    Reply
    1. Nicolas Chevobbe
      
      January 26, 2024
      
      I said it wasn’t our preference because of the blindspots it could create, I didn’t oppose to the idea entirely.
      I filed a bug this morning and added a patch to add a preference in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=1876220), and I’ll follow up expose it in the settings panel
      
      Reply
Ricardo M.

January 14, 2024

I agree that it might take a bit of time to get used to it but I find it extremely helpful to see the banner directing the user to this post, kudos to the team for that.

Reply
1. Andy
  
  January 31, 2024
  
  If they can spawn a banner telling us to come here, then they can certainly add an option in the config window… That’s literally less work invovled..
  
  Reply
  1. Nicolas Chevobbe
    
    February 5, 2024
    
    The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
    
    Reply
2. antlers
  
  February 6, 2024
  
  Seconded, that pop-up was pretty slick; wanted to show my SO but there was no way to make it happen again. Vry cute, and the “tone” was well-written.
  
  Reply
Devy Jones

January 15, 2024

I’d like to request adding a key combo to add a new CSS rule, and show what it is when hovering the plus button. Now I have to navigate to closing curly brace and press Enter, or click the empty space to the right of existing rules, which requires grabbing the mouse.

Previously, if I was at the last rule’s value, I could press Enter and immediately start typing the new rule’s key. Now there’s an extra Tab press before that. I can get used to that change over time, but also I’d like new combos, since I’m frequently writing new CSS rules, and I’d like to get speedier at adding and editing them.

Please consider new combos for these actions:

1. Add new CSS rules
– at the end of the current rule block
– after the currently edited rule

2. Move rules up/down
– by dragging them with mouse
– one by one or multiple text-selected rows
– alt-[up/down] is the combo in msvs, but in notepad++ it’s ctrl-shift-[up/down], so this could be a about:configurable combo;
– clicking small up/down arrow buttons (could be bad for accessibility unless the buttons are large enough, which would be bad for screen-space efficiency, unless the buttons are floating and only appear when a rule (or many) are selected);

3. Having an (i) button which opens a tooltip/hover window with the hotkeys/combinations, so we don’t have to google and end up on MDN to see what hotkeys are available.

Reply
1. Nicolas Chevobbe
  
  January 15, 2024
  
  Hello Devy
  
  > Previously, if I was at the last rule’s value, I could press Enter and immediately start typing the new rule’s key.
  
  Ctrl+Enter (Cmd+Enter on macOS) behaves the same as Enter used to, so it will create a new property in the rule if you were on the last property value.
  
  That being said, I agree that having shortcuts to directly add a property within the rule, create a new rule, move properties within a rule would be nice. One of the challenge is that there are not a lot of shortcuts available as DevTools/Firefox are already registering a vast variety of keyboard shortcuts.
  
  I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1874641 so we can consider this 🙂
  
  Reply
  1. Devy Jones
    
    January 18, 2024
    
    Hi, thanks for creating that feature request!
    
    Currently, ctrl-Enter only focuses on the next property when the value has been confirmed with a prior Enter hit, but not when you’re editing the value – pressing ctrl-Enter does not apply current value and change focus to the next property, as I would expect from the description of the new hotkey. Basically, you have to press ctrl-Enter twice or once. I think we already have the normal Enter for applying the value, so pressing ctrl-Enter should work in one hit to apply and move focus forward.
    
    Also, pressing Enter or ctrl-Enter while editing a value of the last property when it’s empty, deletes the current property, and completely loses the focus from editing the CSS block, which is pretty frustrating behavior.
    
    If you think these are bugs, please create tickets for these behaviors. Thanks!
    
    Reply
    1. Nicolas Chevobbe
      
      January 18, 2024
      
      Hey Devy,
      
      > pressing ctrl-Enter does not apply current value and change focus to the next property, as I would expect from the description of the new hotkey
      
      I can’t reproduce this, for me the focus do move as expected. Can you tell me the version of Firefox you’re seeing this in, and maybe link to a codepen and tell me detailed steps you are doing that lead to the issue?
      
      > Also, pressing Enter or ctrl-Enter while editing a value of the last property when it’s empty, deletes the current property, and completely loses the focus from editing the CSS block, which is pretty frustrating behavior.
      
      Yes, I agree. This is not new behavior, but I’ll try to have something to move the focus to where it makes the more sense (so maybe on the closing bracket, so you can easily navigate with tab)
      
      Reply
Johnny Kermode

January 16, 2024

I find it absolutely outrageous and disrespectful towards developers that this change was implemented without any warning or opportunity for input, simply because a part or perhaps even a majority of people have made this decision for themselves. Personally, this change annoys me to the max and has such a negative impact on my workflow that I had to switch back to an older version. For me, personally, it’s much more intuitive to press ENTER after every line to add a new line of CSS, exactly the same way I would do it in any other code editor.

Moreover, for what felt like two weeks, I thought there was a bug with my Firefox or that it was broken in some other way, because I only saw this message in this thread after I downloaded the beta version of the regular Firefox. It’s super frustrating. I can’t understand why this decision was made, especially since it’s still possible in Safari or Chrome without any issues.

I hope there will be a hack, an about:config, workaround, or whatever for this.

Reply
1. Nicolas Chevobbe
  
  January 17, 2024
  
  Hello Johnny
  
  > Moreover, for what felt like two weeks, I thought there was a bug with my Firefox or that it was broken in some other way, because I only saw this message in this thread after I downloaded the beta version of the regular Firefox
  
  Yes, sorry about that. We now added a notice in the UI with a link to this post so it’s less confusing for people
  
  > I can’t understand why this decision was made, especially since it’s still possible in Safari or Chrome without any issues.
  
  It’s all said in the post, I hope you’ll be able to switch to Tab (which works in all browsers), or in Cmd+Enter
  
  Reply
  1. Emin Ozlem
    
    January 28, 2024
    
    what if we cant adapt ? or we dont want to ? Please put an optiion to revert this back, I am too frustrated just as much
    
    Reply
    1. Nicolas Chevobbe
      
      January 30, 2024
      
      Hello Emin,
      
      I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
      
      Reply
Johnny Kermode

January 16, 2024

Sorry I forgot to add one thing: cmd+Enter is not working for myself, this could be a “workaround” to life with maybe, but I have no idea why it’s not doing the job.

Reply
1. Nicolas Chevobbe
  
  January 17, 2024
  
  This was added in a later beta dot version (I think 122.0b8), so you might need to update (the shortcut will be in regular Firefox version 122 when it’s released next week).
  If it still does not work after updating, would you mind opening a bug in https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&component=Inspector:%20Rules
  
  Reply
Frustrated Dev and Long-Time Firefox Proselytizer and Devotee

January 17, 2024

When this was implemented in Firefox Dev Ed, it drove me absolutely nuts and I couldn’t find ANY info on whether this was an intentional change or a bug.

I hate this. I’m all about making sure people aren’t held back from using things because of disabilities, but realistically how many blind web devs are writing CSS, a visual language, that Firefox needs to change a muscle memory configuration that works for the vast majority? And make it so that we all have to interact with something that isn’t a standard UI form element the way we do with a standard UI form element? At least give an option in about:config or the DevTools settings to keep the same key setup everyone’s been using for years.
Feels like changing all car steering wheels to a new shape because 0.1% of drivers may find triangles an easier shape, regardless of 99.9% of people who use them. Trying to make sure dev tools work exactly like standard web forms is stupid in my opinion. Just because people know how to use a standard hammer doesn’t mean it’d be better to have wrenches work like hammers. If there were some HTML element in the viewport that had a funky key nav setup that was out of line with the rest of spec, that’s one thing. This is aggravating. I now cannot get into my flow of writing and testing CSS because I’m having to consciously spend *my* CPU cycles overriding my decade’s muscle memory. I’d rather keep the extra 20ms of processing to have a more fluid keyboard navigation experience when I’m doing dev work. Feels like optimization for optimization’s sake at the expense of inconveniencing millions.

I wouldn’t rant this hard but I spent days trying to figure out if my system had a new bug, if Firefox had a new bug, if my OS was mangling my inputs, if some driver or app in the background was hijacking my inputs, or whether there was a new config option I couldn’t find. I pored over the Moz bugtracker, Reddit, Youtube, and various forums. All because of a random “improvement”.

When you’re considering changing basic interactivity that will absolutely affect thousands, never mind millions, of people who use your software everyday, why not run a poll? Why not make it opt-in by default?

Reply
1. Nicolas Chevobbe
  
  January 18, 2024
  
  > When this was implemented in Firefox Dev Ed, it drove me absolutely nuts and I couldn’t find ANY info on whether this was an intentional change or a bug.
  
  Sorry about that. We now added a notice in the UI with a link to this post so it’s less confusing for people
  I hope you’ll get used to Cmd/Ctrl+Enter, or Tab (which works in all browsers)
  
  Reply
Jack R.

January 17, 2024

Yea, I totally agree with “Frustrated Dev”. It feels like the same bull** when Gutenberg was forced to be the new editor for WordPress and still millions of people hate to use it, but a bunch of people have decided this for a whole community.

Give us an option to change this “feature” back to old behaviour!

Reply
1. Nicolas Chevobbe
  
  January 18, 2024
  
  I’m sorry it’s momentarily frustrating, I hope you’ll get used to Cmd/Ctrl+Enter, or Tab (which works in all browsers)
  
  Reply
  1. Kervis Toledo
    
    February 1, 2024
    
    That is why I use Firefox, because it has different things to other browsers. Is there any way to return to the previous way?
    
    Reply
    1. Nicolas Chevobbe
      
      February 5, 2024
      
      The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
      
      Reply
Guy

January 19, 2024

Opposed to the noisy hate towards this change in the comment section, I actually really like & appreciate this change. I never got used to this behavior in the first place, so this is great.

Reply
1. Stefan
  
  January 24, 2024
  
  Same, I really like the new behavior, and always found the old keyboard navigation flaky, so thank you very much for improving it!
  
  Reply
2. Luka
  
  February 2, 2024
  
  Agreed, this is just so much better.
  
  Reply
  1. Nicolas Chevobbe
    
    February 5, 2024
    
    Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
    
    Reply
FireFox entusiast

January 24, 2024

That’s stupid. I like my muscle memory the way it is. Haters of haters does not understand because they use mouse to focus on another item. If something works, leave it alone. 😀

Reply
1. Nicolas Chevobbe
  
  January 24, 2024
  
  > Haters of haters does not understand because they use mouse to focus on another item
  
  Or they use the Tab key, like they already do in regular web pages 🤷 Hopefully you can switch to that to (or use the new Ctrl+Enter). And again, while you’re getting used to it, if you hit Enter and expected the focus to move, use the Tab key to focus the item you want to change and it Enter to activate the edit mode, should be easy for someone not using the mouse 😉
  
  Reply
Talia Hatfield

January 24, 2024

If this is for accessibility, that’s fine, I accept changing the default. But please just put an about:config option to change it back – I literally can’t think of any reason not to. Give people the power to control their own experience.

Reply
Tynach

January 25, 2024

I think I’ll be able to eventually get used to using Tab instead of Enter, but… Why on Earth does it select the curly brace instead of adding a new property, if you happen to press ‘Enter’ first?!

It took me something around 20 minutes to figure out how to get the new keyboard shortcut behaviors to go from highlighting the ending curly brace, to adding a new property (for those who haven’t yet, you have to press Shift+Tab to go back to the property value you just edited, then hit ‘Enter’ to start editing it again, and THEN press ‘Tab’ to automatically add a new property).

I understand the desire to have Tab just act as navigation, and I also understand the desire to have more consistency (nothing else in the UI that I’m aware of acted as ‘press enter to confirm and move to the next item’), but the current behavior is a horrific abomination of the most monstrous nightmares of a scared kitten, at least it is for those of us who still have muscle memory of the old behavior (and for people who also use Chrome and its derivatives).

I had thought that maybe Ctrl+Enter would work instead, but no, that acts as a normal ‘Enter’ and starts editing the field again.

So, in the event that, due to muscle memory, someone mistakingly presses ‘Enter’ to go to the next field and runs into this… They have a few different things they need to do to actually do what they intended:

1. If they’re in the middle or at the start of a list of properties within a selector:
– Press either ‘Enter’ or ‘Ctrl+Enter’ (same behavior both ways) to edit again, then press either ‘Tab’ or ‘Ctrl+Enter’.
– Press ‘Tab’ twice (the first one only goes to the checkbox), then press ‘Enter’ again to edit the next property’s name.
2. If they’re at the end of a list of properties within a selector:
– Press either ‘Enter’ or ‘Ctrl+Enter’ to edit again, then press either ‘Tab’ or ‘Ctrl+Enter’.

That sounds all fine and good, except that there’s no clear difference between tabbing while editing, and tabbing while NOT editing. The main difference is if the text is selected, which is sorta somewhat obvious, but plenty of other programs Don’t select the text of a newly tabbed-into element, so NOT seeing the text selected isn’t surprising, even if I expect it to be immediately editable. What’s more is that 99% of programs out there do NOT distinguish between a text field when it’s editable and when it’s not. If you tab into it, you can edit the contents of it immediately. There now being a distinction like that is Unexpected and Unfamiliar, which is bad for accessibility.

The combination of not expecting for tabbing around for navigation to Also cause text fields to seem uneditable, the difference in how Ctrl+Enter and Tab work when in ‘edit’ mode vs. when in ‘navigation’ mode, and that both ‘edit’ and ‘navigation’ modes render the property name/value fields in a way that can be considered consistent with expected ‘edit’ modes, make it WAY too easy to get confused by the new behavior and spend WAY too long getting to or creating the next property.

It is likely for these reasons that Chrome went with ‘Enter’ going to the next item, as they didn’t want Tab’s behavior to be too overloaded and they wanted a key that would be easily accessible to developers. Also, in actual CSS files, new lines usually are what precede a new property being made, so having ‘Enter’ mean to ‘make a new one’ is pretty intuitive.

In fact, come to think of it, I’m a bit confused by what you mean when you say:

> it struck us that it was unnecessary hard to exit “edit” mode with the keyboard only

I’m all for modal editing of things that need modal editing. But.. Why does this need modal editing? Why is there an ‘edit’ mode that’s separate from other forms of keyboard navigation? Chrome’s editor doesn’t have a separate edit mode. And it’s not like it’s needed for ‘validating’ the input (which you mention several times), because input is validated and applied As You Type.

No, I’m not talking about Chrome still, I’m talking about Firefox. Firefox validates and applies values as you type them. The ‘Esc’ key just reverts changes in case you made a mistake (and that’s a good thing too, because if you start using an autocomplete value (even if you don’t use it and it just fills in for you with the rest selected), it removes all the undo history). So why even have a separate ‘edit’ mode, when the non-edit mode is not used for literally ANYthing?

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  I agree that non-edit mode focused field and edit-mode input can look too similar, I’ll file a bug for that.
  It’s also not great that the closing curly bracket acts as a “Add new property” button, I’ll file a bug to add a proper button instead.
  
  Reply
  1. Tynach
    
    January 28, 2024
    
    Uh, no, the closing bracket DOESN’T act as a ‘add new property’ button. It appears that way when using the mouse, but only because clicking anywhere in the area that isn’t a property name or value will add a new property, and the curly brace is part of that ‘rest of the area’ thing.
    
    The problem is that when you’re NOT in edit mode, the ability to select the ending curly brace is useless and pointless. It provides zero value, and serves as a point of confusion. While ‘Tab’ will create a new property in edit mode, it DOES NOT create a new property when you’re NOT in edit mode, and thus if you press ‘Enter’ and expect to go to a new line to make a new property, but you instead leave edit mode… Well, now pressing ‘Tab’ just selects the ending curly brace, which doesn’t let you do anything and makes it harder to figure out what is going on.
    
    Like I said, it took me about 20 minutes or so to figure out what arcane series of key presses to use to do what I wanted after that point, if I wanted to avoid clicking with the mouse.
    
    And I STILL say that there’s no point in having a non-edit mode. Nobody else does this with text editing except Vim, and Vim at least takes full advantage of it by having complex and powerful shortcut combinations possible. Firefox Does Not.
    
    Reply
Ali K.

January 25, 2024

This is a very welcome change, the previous behaviour was indeed awkward. Unlearning muscle memory always sucks, but can be a worthwhile investment when it’s a change for the better. I think you executed this well with an elaborate explanation and the little notification banner linking here. Kudos!

Reply
Christoffer

January 25, 2024

I’d really love a toggle for this new option.
It often requires multiple CTRL+Enter presses depending if the current value is “active” or not.
I can see this adding a lot of extra keypresses over a whole day of editing, and as someone with joint issues this is not good.

Please consider adding a toggle.

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  Is there anything that prevent you to use Tab? It does behave the same as Enter used to.
  But yes, we might add an option in about:config or the settings panel
  
  Reply
  1. SKRAmmA
    
    February 3, 2024
    
    You should have added an about:config to change it to tab for users who actually have had a problem with this instead of just changing it with no option to toggle for us users who have been used to it behaving consistently for well over the last decade. Dropping these kinds of sudden changes on users with no way to change it back, then responding to complaints with “well just relearn the thing we changed 🤷” is rather disrespectful to Firefox’s already-dwindling userbase
    
    Reply
    1. Nicolas Chevobbe
      
      February 5, 2024
      
      The change was reverted, in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
      
      Reply
Vita

January 25, 2024

Is it just me or was the little fox popup explaining the new behaviour totally cute! 🙂 I’ll get used to this, no problem.

Reply
A. User

January 25, 2024

I hate everything about this.

Tynach’s comments are exactly on-point. Not only have you forced every user to override years of muscle memory, you’ve alienated the entire industry standard, and forced even more keystrokes by the user. Whoever green-lit this as a reasonable change needs to give their head a shake.

Beyond that, it appears to me that the inspector is now incredibly broken – values showing for wrong properties, inability to change/update existing values, odd loading behavior…

IMO, you guys broke something that absolutely did not need to be touched – all because some developer couldn’t be bothered to hit Escape when they were trying to escape what they were doing.

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  We may add an option in about:config/in the settings panel so people who want to revert to the previous behavior can, we’ll keep you updated
  
  The key shortcut change shouldn’t impact the rule view showing wrong properties, can you give us some steps to reproduce the issue you’re seeing? If you can, file a bug on https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&component=Inspector:%20Rules so we can investigate properly? Thanks
  
  Reply
2. Tynach
  
  January 29, 2024
  
  To be fair, if you stick with just using ‘Tab’ it all works perfectly well, and ‘Tab’ also works in most other programs, so it’s a bit of muscle memory that’s easy to switch to.
  
  This is why I compare it to the nightmares of a kitten. It’s not the biggest deal in the world, but it certainly can seem like one of the most immediately pressing issues to the metaphorical kitten. Combine that with the bizarre, non-standard, and unexpected choice of having separate edit and non-editing modes (seriously wat), and you have a lot of people suddenly becoming kittens.
  
  The other problems… I’ve sorta noticed things like that, but they’ve always turned out to be self-inflicted in my case, and happened in previous versions too. What happens (in my specific case) is that I’ll be using the ‘Style Editor’ as well, and I’ll make changes in there.. And those changes WON’T be reflected in the ‘Inspector’ tab until I select something else, then re-select the original element I had selected. If I make changes in ‘Style Editor’, and then make further changes in ‘Inspector’, it gives wonky results that don’t really mesh correctly.
  
  Again, that’s what happens in MY case. Your case might be different, and you might be running into actual bugs.
  
  Reply
Carlos

January 26, 2024

Please add an option to revert this change. It’s totally frustrating and time consuming changing and testing css code now

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  I filed a bug this morning and added a patch to add a preference in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=1876220), and I’ll follow up expose it in the settings panel
  
  Reply
  1. Julian Descottes
    
    January 29, 2024
    
    Small typo in the link above, the work is happening in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694
    
    Reply
Fen

January 26, 2024

Can you leave in settings for people to use like it was ?

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  I filed a bug this morning and added a patch to add a preference in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=1876220), and I’ll follow up expose it in the settings panel
  
  Reply
User1

January 26, 2024

At first, I though this was a bug. I did see a notice but its disappeared so fast because I keep clicking ‘Enter’ several times (because I though it was a bug… the focus is very troubling) so I didn’t see the message.

Whereas I can understand the reasons, I think the implementation without leaving the possibility for developers to keep the old behavior is a terrible mistake.

And it was hard to find the information, the first result on serp is a post complaining about this : https://connect.mozilla.org/t5/discussions/in-dev-tools-the-quot-enter-quot-key-began-to-perform-other/td-p/49127

Reply
1. Nicolas Chevobbe
  
  January 26, 2024
  
  I filed a bug this morning and added a patch to add a preference in about:config (https://bugzilla.mozilla.org/show_bug.cgi?id=1876220), and I’ll follow up expose it in the settings panel
  
  Reply
Charlie

January 26, 2024

To be honest, I never really liked the old behaviour anyway. This new design does feel more intuitive to me. Pressing Enter now feels like “submit”, instead of “next”, which always felt like Tab’s job anyway. I’ll be keeping it like this.

Reply
Why, It doesn’t matter.

January 26, 2024

This is very disruptive and annoying. At least the inferior browsers still work that way.

New Feature Request: You guys should implement a more difficult way of opening the browser as well. Maybe add in a right click to the standard double click. Stand up and turn around with the right double click.

Idiots!
Still love you guys, but grow some freaking brains…

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
  1. Fredric
    
    February 2, 2024
    
    I think the new behaviour makes more sense than old behaviour.
    Yes, it might be frustating for old users, but thinking for the future keeping the current, new behaviour is probably more helpful for new users. Adding an option in the preferences will hopefully silence the vocal people hating this change, but please keep the new behaviour as the default.
    
    Reply
    1. Nicolas Chevobbe
      
      February 5, 2024
      
      Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
      
      Reply
Bob

January 27, 2024

I really think this is a step backwards.
As a programmer I want the behavior to match my code editor ( vscode ).
In both vscode as in firefox i am using enter for the auto completion, now I got a mismatch between my browser and my editor.
From my point of view I thin these kind of behaviors should be configurable so you can match the behavior with the code editor you are using. I noticed I can use tab for auto completion as well in vscode. But it seems to be the world upside down that I need to change my workflow because my browser decided to change there logic.

So it is not a change that’s making me happy, thing that would make me happy if emmet support will finally will be supported by my browser. This would speed up my workflow as I’m using it as well in my code editor. I sometimes using emmet in FF because I’m used to this workflow.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Bob,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
  1. Bob
    
    January 31, 2024
    
    Thanks, personally I would look at what the other browsers support. As when people want to switch to firefox but they are used to the enter behavior, it could be more of a struggle to switch to firefox.
    
    Reply
Bob

January 27, 2024

Okay this sucks big time, I thought I will downgrade firefox to get the old behavior back. But you added “downgrade protection” so you need to start with a new user profile, I think this is bs. I thought maybe there is still something alive like firebug but this has died in 2017, there is still a firebug lite extension for chrome, but it is not working properly. The only working solution is to switch to chrome devtools as it does support the old enter behavior. I don’t like using chrome but for now it’s the only solution I can come up it.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
Ark

January 27, 2024

It really doesn’t affect my developer experience negatively or positively. I am onboard. But I am actually surprised how many people have their pitchfork up because muscle memory. How many people use their browser CSS rules to extensively change CSS properties? Just switch to your editor. For the small changes you need to test right within the browser CSS rules, it is fine because then you are doing double the work if you are writing the whole CSS right in browser and then back in the editor.. (I guess people might be copy pasting but that’s not my workflow).

Also, the new alternative is not bad either? It works as expected. I guess I just don’t care too much about it if I can clearly see all the rules. But some devs really want that extra checkbox in their settings haha.

I also feel “Tab” is more intuitive than “Ctrl+Enter”. Just “Enter” to go in and out of editing the property. Just that the selection of curly braces is weird at the end of a ruleset. But its been filed as bug already, I believe. “Shift+Tab” on the other hand goes to previous property (or ruleset) as expected, not select the curly brace.

Reply
Adam G.

January 27, 2024

I totally agree with everyone here, I hate it so much and it has destroyed my workflow. Of course I can try to get used to new methods, but changing a “major feature” (at least it is for me) without the possibility to opt-out is a nightmare decision by you guys.

I personally find it very intrusive to force this decision on all developers, thus negatively affecting the workflow (muscle memory). I can’t recall any comparable change in recent years that has ever had such a negative impact on my work process. I have ongoing projects and feel like I’ve become about 10% slower due to the change.

Nintendo doesn’t just change the function of the green button for ALL players just because a group of people see a better use for it. That’s why in most games there is usually the option to configure the buttons yourself. So give us the damn about:config change!!!!

Reply
Adam G.

January 27, 2024

I have set “rulesViewInplaceEditorEnterKeyOriginalBehavior” to true, but it’s not working on Mac?!

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Adam,
  
  The patch didn’t land yet, I’ll update the post when it does. First, it will be in Firefox Nightly, and then we’ll try to uplift it to Beta and release if possible
  
  Reply
Nikolay

January 27, 2024

I’ve been a webdeveloper for a long time 15+ yrs.
This feature (2x enter == save and (move to next line or create a new netry) ) was by far the best feature of the CSS editor.
It saved me so much time and was very ergonomic.
Now I have to move my hand to the tab and it does not feel ergonomic.
Also this bold blue border makes me feel something is not ok.

Please make a setting so I can revert back to the ergonomic behavior of double enter or revert this completely to how it was before.
Don’t make me switch to chrome, I don’t want to.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Nikolay,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  I also filed a bug so we can distinguish the focus indicator from the span from the one of the input when we’re in edit mode.
  
  Reply
Cadence

January 28, 2024

Thanks! I always wish it worked this way. I’m happy to see this changed.

Reply
TSi

January 29, 2024

I don’t mind the change, I’m not using the kb exclusively when editing or debugging live and tab feels more natural to move to the next input.
Just make sure everyone on team is aware that changes are not only validated on enter buy as you type, so, as far as I know, pressing enter now after editing a value has no “useful” benefit over the previous behaviour where it felt like going to the next line in a text editor… and that is what every dev expects a code editor to do. Now, the behaviour is more akin to a spreadsheet except no expression is ran and it’s a bit weird I have to say when you’re at the end of a line and nothing happens unless pressing ctrl enter twice.

My main issue is that it seems something else got broken as in some cases, I can’t click a property or value to change it and I don’t know why just yet. Maybe that’s a pebcak as I got caught off guard with this change.

Reply
TSi

January 29, 2024

I think this raises a question. Shouldn’t the inspector behave more like a code editor with auto-completion rather than like a spreadsheet/form ?
If this was the case, there would be less of a disconnect when going back and forth with your code editor of choice.

Reply
felipe

January 29, 2024

Our, that’s horrible, 30 years used to it this way now changes… at least I left it optional

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Felipe,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
name

January 29, 2024

Thank you for adding the toggle.

Reply
Matthew Miner

January 29, 2024

I get this is simpler, but I’m still not clear on the benefit. Is it really a problem to have the next cell selected instead of just the current cell focused? Personally, that doesn’t improve navigation at all for me, and it’s really unintuitive as someone used to this behavior in both developer tools and in spreadsheets in general like Excel. I don’t hate it, but it seems to just be making things harder for the sake of change.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Matthew,
  
  It was not driven by change for the focus of it, when using the Rule view myself, using only the keyboard, I was finding it not ideal to exit edit mode so I could focus other buttons like the checkbox toggle for example.
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
  1. Tynach
    
    January 30, 2024
    
    I get that being able to select the checkbox toggle is desirable. Personally, I’d propose that using ‘Tab’ and ‘Shift Tab’ would focus the next and previous (respectively) form field — including checkboxes — and that ‘Enter’ would select the next text field, such as property names and values. Then you can get rid of the difference between the ‘Edit’ and ‘Focus’ modes.
    
    It would be slightly harder to get used to for people who have been using ‘Tab’ all along, but it would be more consistent with expectations.
    
    Reply
Peter Charlton

January 29, 2024

Jesus Christ dude, just add a setting for the Firefox devotees. Better yet, put the switch in the little “Enter no longer moves focus to the next input.” message so that I can fix it right away and move on.

Fine if the new default is better for accessibility. Fine if new users learn the new default, but I’m working. I don’t want to dedicate mental load to retraining 20 years of muscle memory because of your preference. Your preference has very little value when we’re talking about MY workspace.

Changing a keyboard command with no option to change it back is what Microsoft would do.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Peter,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
Sean

January 29, 2024

Me and my homies prefer the old way

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Sean,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
Jonny

January 30, 2024

This is ridiculous. Revert this ridiculous change.

Please mozilla, tell me, which blind people are using inspector to develop websites? is it .000001% of the population?

So you diminish the experience and usability of firefox dev tools for 99% of your users?

Revert it or there is nothing keeping me using firefox. The new microsoft edge is looking pretty great right about now.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Jonny,
  
  I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  We clearly moved a bit recklessly with this change, but , believe it or not, blind or people with low vision, do use DevTools, including the inspector. We’re trying to make our tools accessible to not let anyone behind.
  
  Reply
Keifer

January 30, 2024

“Enter no longer moves focus to the next input.” Incorrect – if I type a property name like ‘display’ and hit enter, it does go to the next input.

“Use Cmd + Enter or Tab.” Incorrect – If either the property or the value are focused & you hit ‘Cmd + Enter or Tab’ it just allows you to type within the same field instead of going to the next input.

If I am using a form & I am focused or typing within an input and I use tab, it will go to the next available focus element.

If I hit ‘enter’ within a form it submits the form.

The biggest thing to note here is we are not using a form when entering properties and values, this is essentially a textarea element.

If I use ‘enter’ within a textarea element, in a form, it goes to the next line. If I use ‘tab’ within a textarea element it focuses the next element.

Overall this doesn’t feel like something that focuses on any sort of a11y forward thinking. If it was truly a11y it wouldn’t be an impedance for those who require a11y & those who do not require a11y. It just feels like change for the sake of change.

Can’t wait to see how you (Nicolas) break down my message & then link the wrong bug ticket.

Reply
1. Nicolas Chevobbe
  
  January 30, 2024
  
  Hello Keifer,
  
  It’s true that Enter does move to the focus to the value, but only for new property, otherwise we would have a weird in-between where only the name is filled-in, with no property, which is not something that we can really handle.
  I’m sorry I linked to the wrong bug on the other comment, I now have a patch ready in https://bugzilla.mozilla.org/show_bug.cgi?id=1876694 that will add a preference that people can switch. Given the feedback we are getting, we’re discussing reverting to the previous behavior by default.
  
  Reply
Ruben

January 30, 2024

While I understand the reasons you’ve provided to justify this change, I urge you guys to hear the community and revert this change sooner rather than later.

I like that Mozilla, in it’s many products, doesn’t make changes for sake of profitability but rather for the good of the ecosystem. With that said, as many have pointed out, this is an issue that doesn’t affect the vast majority of your users, I think it’s great you provided the option, but it should be an OPTION, not the new norm.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
Lucadev

January 30, 2024

Wow, finally! I’ve always been confused by the strange behavior of the Enter key in the Developer Tools. I love this change!

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
  
  Reply
Joel Kuhn

January 30, 2024

I know I’m just joining the dog pile, but this sucks. I spend a lot of my day in firefox writing CSS. Changing a behavior that is baked-in muscle memory for untold thousands of people, with no alternative is just bad. I care very much about accessibility, but I feel that all too often, accessibility measures don’t actually take into account how people actually use software. This change doesn’t really even improve things for all unsighted users. It arguably makes things slightly less confusing for *new* unsighted users, but I think it’s infantilizing to think that they couldn’t figure it out. Besides, unless the entire industry changes to this, it will just be more confusing for developers who need to work in multiple browsers, which is, checks notes, all of them.

Besides that, so many things smell bad about this change. CPU cycles? Really? We’re worried about the CPU cycles switching between some inputs? The user feedback was a Spanish language post on the dev’s personal Mastodon with 128 followers? If you really care about accessibility, why am I typing feedback in a light blue font on a white background with a 3.1 contrast ratio that doesn’t pass wcag?

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
stjn

January 30, 2024

Please don’t listen to all the hateful comments. This change is fine. It’s no problem to switch to Ctrl+Enter, and the benefit is apparent. Thanks for linking me to this post.

https://xkcd.com/1172/ seems to be immortal.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
  
  Reply
Alex_Ctr_Cmd_Shift_Alt_Tab_Enter

January 31, 2024

It’s very inconvenient, cos all other chromium based browsers work only by hitting Enter. If there’s a way to change back, please do it.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
Mark Maskell

January 31, 2024

This change is so jarring because it introduces a discontinuity between how CSS is written in the Inspector versus how it is written in every other development environment or browser Inspector.

Everywhere code is written (IDEs, Notepad.exe, other browsers’ Inspectors, etc), you universally hit Enter to advance to the next line and continue writing code. But with the new changes made to Inspector, hitting Enter now “quits” editing mode.

Enter then Escape makes perfect sense to me as a two-step process because I’m doing two separate things:
1.) ENTER: I’m done editing this particular property (or I accept the autocomplete suggestion), save my changes then advance, and
2.) ESC: I’m done with editing altogether, exit editing mode and discard any unsaved changes.

Before the change, you could treat the editor like a pure-code entry space with a handy auto-complete function, but now by combining those two distinct functions into the Enter key, it’s made it into a webform instead.

I appreciate the thoughtfulness in designing things that are disability-friendly, but this change may ultimately be more confusing to those with vision difficulties because it now behaves differently than everywhere else code is written, including other browser’s Inspectors.

(Also, thank you for providing the popup note, I was losing my mind and couldn’t figure out why it wasn’t working right!)

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
  1. Mark Maskell
    
    February 12, 2024
    
    Just thought I’d loop back and express my personal gratitude that you and the team have been so responsive to the community, especially being such a small team. Really appreciated.
    
    Quite frankly it’s amazing to me that, in all the years I’ve been doing development, this is the one and only time I’ve had any sort of issue or qualm with the Inspector. That’s an excellent track record as far as I’m concerned. Shows that the team is doing things right overall. Keep up the great work!
    
    Reply
Mesbah

January 31, 2024

Wow, some of the comments here are so hostile. I have no idea how Nicolas is dealing with all the hatred from a little shortcut change. I also want to point out that people who are completely fine and support the change aren’t leaving comments. Only an angry vocal minority is bashing this.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  Thanks for the kind words 🙂 Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
  
  Reply
CJ

February 1, 2024

Just adding another supportive voice: I appreciate the changed default and I too always wished it worked this way. The old way tripped me up often, and the new way makes more logical sense. Nice change!👍🏼

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
  
  Reply
Ulterno

February 1, 2024

I don’t do much web-dev and even when I do, most of it is in a separate text editor.
This one thing used to be unintuitive to me and the change is welcome.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  Due to the feedback we got, the change was reverted (in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1). You can set the Enter key to not automatically move the focus to the next input by navigating to about:config, and set devtools.inspector.rule-view.focusNextOnEnter to false
  
  Reply
Lucas

February 2, 2024

This is not a good change. Trying to remain polite here… but Ctrl Enter does not do the same thing. Having to use my mouse every time.

REVERT!!!! PLEASE!!!!

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted, in Firefox Beta/Developer Edition 123.0b6, and will be in Firefox 122.0.1 which should be released 2024-02-06
  
  Reply
Bad Change

February 4, 2024

This is how you get people to turn off automatic updates.

Reply
1. Nicolas Chevobbe
  
  February 5, 2024
  
  The change was reverted
  
  Reply
Leo

February 5, 2024

Relevant XKCD: https://xkcd.com/1172/
I appreciate that the new behaviour will at least be available via a config flag, I found the previous behaviour inconvenient and unintuitive.

Reply
Thomas

February 17, 2024

Tried to deal with it a couple of weeks now. I had to say: I deeply hate it. This change kills my workflow and the new bahavoir makes me angry all the time.

Reply

Firefox Developer Experience