New Responsive Design Mode: RDM Lands in Firefox Dev Tools

Firefox Developer Tools now includes a completely redesigned Responsive Design Mode (RDM for short) that’s just landed in Firefox Developer Edition, thanks to hard work from the DevTools team.

In a mobile-first world, it’s essential to prioritize performance for low-bandwidth and offline mobile experiences and design progressive web apps that can deliver across a range of devices. We aim to design developer tools that prioritize empathy for users and developers. That’s why we’ve put so much effort into the Responsive Design Mode.

We want to make it easier for developers to build web experiences that load and respond on screens of all different sizes and support a multitude of browsers, platforms, and device types. RDM is a significant upgrade to the Firefox tools themselves, reflecting our commitment to people who build for the web.

To access the RDM tool, make sure you’re running an up-to-date version of DevEdition. Next, open any web page to view  the Responsive Design Mode via Developer Responsive Design Mode.

There’s a lot in this new tool, and many new features still to come. Check out the video walk-through to see the tool in action with all of its features enumerated, including:

  • Popular device emulation
  • Network throttling
  • Touch-event emulation
  • Ability to set DPR (device pixel ratio) of devices
  • Screenshotting devices at certain sizes

Firefox Developer Tools already has a series of improvements planned for the next release of Responsive Design Mode, including:

About Helen V. Holmes

Helen V. Holmes is the designer on the Firefox Developer Tools team, passionate about everything from typography to arduinos. A big proponent of making tech a healthy community for all, she helped found Women Who Code DC’s chapter and has mentored at student hackathons all over the U.S.

More articles by Helen V. Holmes…

About J. Ryan Stinnett

Staff Engineer working on Firefox DevTools at Mozilla.

More articles by J. Ryan Stinnett…


24 comments

  1. fvsch

    Well, this is underwhelming.

    I had many doubts about this design when I first saw it, but hoped that tweaks along the way would improve it. Doesn’t look like it.

    Core design issues:

    1. On one hand it wastes a lot of space. On a 13″ laptop with everything maximized I have roughly 700px available vertically; yet the only device size that fits in the screen (counting the padding, top bar, viewport, *and* the size control below) is the iPhone 5. That’s frustrating when, with a design made for efficiency, sizes like the iPhone 6 and the Nexus 5 could fit alright. I find it worrying that the planned solution for this is “well, let’s zoom out the whole thing automatically”, and not “hmm, maybe 3 toolbars that each have some white space around is not a great use of space”. E.g. moving the width/height dimensions to one of the toolbars could help, and maybe making the white space around the top toolbar depend on the window height: tight on small windows, comfortable on larger ones — CSS Media Queries to the rescue!

    2. On the other hand everything is very small and buttons are awfully close together and implemented with tiny hitboxes. Why make such liberal use of empty space but not actually make a UI you can only click without 100% motor skills *and* frustrating strain?

    3. Why the strange-looking combo-boxes? More importantly:
    – Why is the first one clickable on the full text and the second one split between the “DPR” label and the tiny number value (another ridiculously small hitbox)?
    – Why is the DPR combo-box still looking like a combo-box but does not react to clicks when a device size was picked? That’s very confusing.

    I also have a few concerns about the implementation:

    4. Abysmal performance when toggling the RDM on (not sure if I’m waiting a full second or more, there’s some flashing and it seems that the tools are anchored to the left first and center themselves with one reflow or several).

    5. Performance is not great when resizing the viewport from the sides or corner either. Obviously that’s going to depend on the web page inside, but it’s still noticeably slower and jankier than in the old RDM.

    6. Zoom is funky, and probably not what users expect.

    7. The select and buttons implementation has a few issues, especially when it comes to keyboard use. Haven’t tried it with a screen reader yet.

    It’s great that some good features have been implemented and others are on the way, but that UI has So. Many. Issues.

    November 22nd, 2016 at 11:51

    1. fvsch

      My apologies for the first three sentences in that comment, though. They sound condescending and are unhelpful.

      November 22nd, 2016 at 12:41

    2. J. Ryan Stinnett

      Thanks for the feedback! Keep in mind that this is a work in progress, we still have a lot planned for the future, and it exposes many features that were unavailable before.

      In general, the RDM tool was rewritten in HTML (from Mozilla’s internal XUL) to help us grow the tool more readily in the future, which was a large effort, but there are still some areas that need a bit more polish.

      1. You’re probably right that margins could be tightened up, especially on smaller screens. I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319593 for this.

      2. We’ll keep the small hit boxes in mind for future updates. There are more elements we plan to expose, so it may be tough to fit everything if they grow to be much larger.

      3. For the DPR selector, the text is not part of the menu, so that makes it differ from throttling. However, it seems like we could easily trigger then menu when clicking the DPR text. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319597. At the moment, we lock the DPR value when a device is selected, but we could allow it to be changed in that case. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319599.

      4. I agree it can be a bit slow to enable. I haven’t noticed it being too bothersome, but we should try to polish it up where possible! We have https://bugzilla.mozilla.org/show_bug.cgi?id=1278757 to track this.

      5. You’re right, it can be a bit more jittery than before. I believe this partly connected to the viewport being centered now. In any case, let’s track this with https://bugzilla.mozilla.org/show_bug.cgi?id=1318340.

      6. Yes, I agree most people probably expect zoom to target the web content instead of the RDM UI. We have https://bugzilla.mozilla.org/show_bug.cgi?id=1278758 for this.

      7. I am not sure what you mean here, but please file a bug with more details so we can investigate it.

      Feel free to file additional bugs for issues or enhancements so we can track them along with other work.

      November 22nd, 2016 at 15:57

  2. Max

    Hello,

    It seems that some features were lost with the new RDM. For example, it’s not possible to use Ctrl + click nor Caps + click to precisely resize the viewport (by increments of 1 and 10 pixels, respectively). Did you remove that on purpose or do you intend to bring it back?
    Moreover, it seems that it’s no more possible to save custom viewport dimensions as presets for the “dimensions dropdown”.

    Many developers rely on these features a lot, and now they seem to be gone.

    As for the new RDM itself, do you plan to add non-integer as DPR values to the list? 1.5 is very common on actual devices, and some mobile browsers allow to use DPR values such as 1.25 or 1.75.

    November 22nd, 2016 at 12:22

    1. J. Ryan Stinnett

      Thanks for the feedback!

      For the resize precision modifiers, we weren’t sure how many people used these, since they aren’t mentioned in the UI anywhere. We have https://bugzilla.mozilla.org/show_bug.cgi?id=1245237 to track porting this to the new RDM UI.

      You’re correct that for the moment, it’s not possible to save custom sizes. I believe there are several upcoming features that aim to help with that: restoring the settings last used when you reopen RDM (https://bugzilla.mozilla.org/show_bug.cgi?id=1248619) and defining custom devices with their own size and other properties (https://bugzilla.mozilla.org/show_bug.cgi?id=1173142).

      For non-integer DPR values, we don’t currently have a way to set those in the DPR selector. However, if there is a device in the device selector with a non-integer DPR (such as “Google Nexus 6”), we will apply the value correctly. I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319605 to expose some UI for setting a non-integer DPR directly.

      November 22nd, 2016 at 16:16

      1. Max

        Thanks a lot for all this information, and for the quick answer. Really appreciate it!

        November 22nd, 2016 at 16:28

  3. Nick Tomic

    Hello,

    How do I setup a custom user-agent with the new RDM?

    Cheers!

    November 22nd, 2016 at 13:30

    1. J. Ryan Stinnett

      Choosing a device from the device selector will apply the user agent for that device. At the moment, there is no way to set a completely custom user agent.

      We’ll be adding support for custom devices with their own size, user agent, and other properties (https://bugzilla.mozilla.org/show_bug.cgi?id=1173142), so that seems to match what you’re looking for.

      If you have a commonly used device that’s missing from the device list, feel free to contribute it at https://github.com/mozilla/simulated-devices, and we’ll publish an updated list in the DevTools using that data.

      November 22nd, 2016 at 16:22

  4. Alex Bell

    Strongly agree with @fvsch. Weird that a design so expansive would have click targets so painfully small.

    1) My eyes are tired of dark grey text on light gray backgrounds. Contrast please, and larger type.

    2) The screenshot functionality is an “every once in a long while” thing. RDM is not a true emulator with respect to lots of things, including browser chrome at top and bottom, and thus of limited utility. Capturing screenshots directly in the OS is something every developer knows how to do, already, I’m guessing. Bury it in a corner menu?

    3) Don’t put the dims below the window. For 1:1 viewing of phablets on small laptops, that puts the dims out of view when the dev is actually setting things.

    4) Please just consolidate all UI elements into a single horizontal bar, flush against the top of the viewport. That top margin is wasted space AFAIAC.

    I really love Firefox and am waiting for the day when I can switch my day-to-day development to it full time. But this is one area where I wish FF would just copy Chrome for now, and focus the design effort instead on forward-thinking virgin territory like multi-device preview.

    November 22nd, 2016 at 15:09

    1. J. Ryan Stinnett

      Thanks for the feedback!

      1. For an alternate color scheme, try opening the DevTools toolbox, go the options (gear icon), and choose the dark theme. For larger type, you can zoom the RDM UI at the moment using the browser’s zoom shortcuts.

      2. Many designers and developers have told us how critical screenshots are to their workflow and that they would appreciate additional features in this area, so for the moment at least, I think we’ll continue showing this in primary UI.

      3. I agree it does make things tricky when the viewport is tall and when using a smaller screen. I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=1319619 for this.

      4. A single toolbar might be tricky to pull off with everything we’re planning, but we’ll keep it in mind.

      November 22nd, 2016 at 17:10

  5. Tom

    I would like to reinforce the comments about the UI implementation.

    1. Usability
    The controls are non-standard – I’m seeing a Mac styled drop-down on Windows. There is little user support in identifying what drop-downs represent (tooltips). The control hit areas are too small (drop-downs, pointer, camera, close, rotate). The ‘Responsive Design Mode’ label is presented the same as options (‘No throttling’) for no apparent reason. Related settings are displayed in different locations (‘DPR’, device profile, pixel size).

    2. Fit and finish
    The fit and finish is poor (alignment, spacing, consistency). There are unnecessary glows and transitions. The pixel size field bizzarely adopts Android styling which is confusing and out of place for Windows users. The edit device list UI is an odd modal overlay with non-standard controls. Centring the responsive viewport has resulted in poor performance when resizing the viewport.

    3. Functionality
    The basic pixel size selection list has changed for something more encompassing, but where is the migration of user settings and previous functionality? How can I save a custom device size/DPR? What do entries on the device list represent (size/DPR)?

    November 22nd, 2016 at 15:50

    1. J. Ryan Stinnett

      Thanks for the feedback!

      1. We’ll continue to the tune the appearance of the controls. They aren’t meant to match any OS in particular. I agree the hit boxes are a bit small at the moment, hopefully we can improve that.

      2. I believe other replies covered these issues. Please file bugs if you have more specific issues that don’t appear to be tracked already.

      3. We’ll be adding support for custom devices with their own size and other properties (https://bugzilla.mozilla.org/show_bug.cgi?id=1173142). The devices in the list are taken from https://github.com/mozilla/simulated-devices. Feel free to contribute additional devices, and we’ll publish an updated list in the DevTools using that data.

      November 22nd, 2016 at 17:16

  6. lestnas

    This is a welcome addition. Thank you.

    I have an inquiry regarding developer tools, is there away to enable inspecting the html as I am debugging(breakpoint hit) the script? Since I’ve been using the firebug on pre firefox 50, it’s a great to have that capability.

    November 22nd, 2016 at 17:43

    1. J. Ryan Stinnett

      Thanks!

      For your question about inspecting elements while debugging, this is being actively worked in https://bugzilla.mozilla.org/show_bug.cgi?id=1177346. I would expect to see this land in Firefox 53 (currently the Nightly channel).

      November 22nd, 2016 at 17:46

  7. Flimm

    Yay, throttling tools! I like this.

    November 23rd, 2016 at 02:20

  8. Clément

    Debugging responsive design and network are two unrelated works:
    Network throttling should be used outside of screen size emulation tool.

    November 23rd, 2016 at 05:24

    1. Clément

      I think, Network throttling should be placed in “network” tab of devloper tool

      November 24th, 2016 at 06:30

  9. Mte90

    It’s pretty amazing the problem now is to find where is written the real size of the windows, a time was on the top now is in the bottom of the view and in a color that is not easy to see.
    Only clicking on it get a real black, it’s not better to have this field on the top like before? You have all the tool on the top and only one in the bottom but usually the size in every viewer or editor is showed in the top of the view itself.

    November 23rd, 2016 at 07:12

    1. J. Ryan Stinnett

      Thanks for the feedback!

      Several others have also mentioned they’d prefer the dimensions on top, so we have https://bugzilla.mozilla.org/show_bug.cgi?id=1319619 to think about this again.

      November 23rd, 2016 at 16:03

  10. Tim

    I like the added features such as the DPR mand the network throttling. Like others said before there are some serious UI/UX problems that could be fixed. I won’t repeat everything from before, but I think aligning it to the top left in combination with one menubar would really make things a lot faster and usable. I actually really like the old responsive view with that top bar and the black background and big buttons.

    November 24th, 2016 at 02:59

  11. Tom

    Well if i could save my own window sizes again to test my breakpoints i would give it a thumb up – right now I had to downgrade my version to get this feature back.

    November 29th, 2016 at 04:40

  12. Tiago Celestino

    Is there the possibilty this updates come on Firefox?

    December 6th, 2016 at 04:37

    1. Dan Callahan

      Yes, it will come to Firefox as soon as it is stable and working well in Developer Edition, likely early next year.

      December 6th, 2016 at 12:03

  13. JS

    Thank you for listening & filing bug reports! I’ve been incredibly frustrated with the waste of vertical space & dimensions below the viewport – very glad to know it’s being noted!

    December 12th, 2016 at 07:51

Comments are closed for this article.