Closed Bug 1487857 Opened 5 years ago Closed 5 years ago

Implement redesigned settings panel with edit functionality


(DevTools :: Responsive Design Mode, enhancement, P3)



(firefox68 fixed)

Firefox 68
Tracking Status
firefox68 --- fixed


(Reporter: victoria, Assigned: mtigley)


(Blocks 2 open bugs, Regressed 1 open bug)



(1 file, 1 obsolete file)

Mockup deck (6 screens):
Sample Inspect link for development (requires login):

Thanks to our contributor, Kristin, for her awesome work on these mockups! (
Priority: -- → P3
Summary: Responsive Design Mode — Implement redesigned settings panel with edit functionality → Implement redesigned settings panel with edit functionality
See Also: → 1498536
Assignee: nobody → mtigley
See Also: → 1394996
It would be a good idea to break this down into two parts: 

Part 1: Implementing the redesign (slides 1-4) since it only concerns styling the existing settings view.

Part 2: Adding the ability to edit device names/parameters (slides 5-6). It seems we don't have a way to update a custom device directly so I think it would make sense to have it in its own part. Initial thoughts: add a new action called updateCustomDevice which would update both the store and the custom device from local storage once the "Update" button is pressed.
This is part 1 of implementing the redesigned device settings panel. In this patch we are rearranging the existing device settings view to match the new design.
Blocks: rdm-ux

Hey Patrick, I wanted to get your input on whether or not this might be a good candidate to consider using mult-column layout over grid (see Part 1 patch) to improve on the responsiveness of the modal and variable number of devices.

Flags: needinfo?(pbrosset)

I think it's perfectly valid to use css grid here. It allows for responsiveness just as well, if not better, than css mulicol.
In order to improve the responsiveness of the modal, I think we should add a few media-query breakpoints to drop down to 2 and then 1 column, as space reduces.

A proposal:


phone phone custom
tablet laptop tv


phone phone
tablet laptop
tv custom

< 600px


Using grid-template-areas for this would be awesome! You could just use these name right there in the .device-modal-content rule (and redefine the areas in the media queries), and then just use grid-area in the different .device-type-phones, .device-type-custom, etc. rules.

At the same time, it might help making the modal itself. It has a 800px max-width, which is fine to avoid it looking weird on extra large screens. But then it has a 60% width (60% of the browser window's width) which makes it look really tiny when the window becomes small. I would increase this 90%. It won't change anything in most situations (because of the max-width), so the original design is preserved. But it'll look way better below 800px.

Flags: needinfo?(pbrosset)
Blocks: 1498492
Blocks: 1394996
Blocks: devtools-webcompat-team
No longer blocks: 1394996
Attached file Part 2: Add ability to edit devices (obsolete) —

I think we might want to land Part 1 after the merge since the release candidate will be made this immediate Monday.

(In reply to Gabriel [:gl] (ΦωΦ) from comment #8)

I think we might want to land Part 1 after the merge since the release candidate will be made this immediate Monday.

This sounds good to me. Landing after merge will give us more time to test the new design and device editing.

Pushed by
Part I: Rearranging devices setting view to new design. r=gl,flod
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Quick note: since one patch landed here and the bug wasn't marked as "leave-open", it got marked as RESOLVED/FIXED in 68.
However part 2 patch hasn't landed.

It's a good idea to use the "leave-open" keyword when we expect to be landing patches at different times, so bugs don't get closed in between.
It's however sometimes a bit dangerous because it sometimes happen that we land 1 part, but never anything else, and the bug never gets marked as closed because of that.
In this particular case, part 2 seems ready, so it might be ok to mark this bug as re-open and land the part 2.
But I think it might be just as easy to file a new one just for the device editing capability, and move the patch there (as we do that, we should also make sure this new bug blocks bug rdm-ux and bug 1493094 as this one does).

Micah: do you want to do that?

Flags: needinfo?(mtigley)

Patrick: Let's create a new bug for part 2 and land it there.

Flags: needinfo?(mtigley)

Comment on attachment 9048655 [details]
Part 2: Add ability to edit devices

Revision D22180 was moved to bug 1536808. Setting attachment 9048655 [details] to obsolete.

Attachment #9048655 - Attachment is obsolete: true
See Also: → 1325571

Just want to make sure what I need for 68 vs. 69. For 68, only the UI update, correct?

Flags: needinfo?(mtigley)

(In reply to Irene Smith from comment #17)

Just want to make sure what I need for 68 vs. 69. For 68, only the UI update, correct?

Hi Irene, for this specific bug yes this is only a UI update. But we also added the ability to edit devices in bug 1536808.

Flags: needinfo?(mtigley)

I have created new images for the UI and updated the text to match on Responsive Design Mode

Please review and let me k now if I missed anything!

Flags: needinfo?(mtigley)

Hi Irene, I apologize for the delay in reviewing this. It looks good to me! Thank you for working on this :)

One suggestion: it would be nice if the article can also have a section detailing the ability to edit custom devices. You can do this by hovering over a custom device in the settings modal and clicking the pencil icon that appears beside it. This will be showing a form similar to adding a device, except for editing.

Flags: needinfo?(mtigley)

Thanks for the suggestion. I will add a sentence or two and an image to show editing an existing custom device.

You need to log in before you can comment on or make changes to this bug.