Open Bug 1028905 (emulation-devtools) Opened 5 years ago Updated 11 months ago

[meta] Create Emulation developer tool

Categories

(DevTools :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: ntim, Unassigned)

References

(Depends on 5 open bugs)

Details

(4 keywords)

Attachments

(2 files)

Attached image Chrome emulation tools
I'd be nice to get an emulation tab into the devtools :)
Here are the things we probably want :
- User agent
- Geolocation (custom coordinates and unavailable geolocation)
- Accelerometer
- Viewport and dppx (I think it's possible via about:config, but it'd be nice to get a temporary feature)
- Media queries (we can do this via GCLI, but it'd be nice to get an UI for this)
- Network emulation (see chrome devtools)
- Firefox OS stuff
I'm pretty sure there are bugs for all of these.
(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #1)
> I'm pretty sure there are bugs for all of these.

This can be used for tracking right ? Also, it should be an actual tool in the DevTools toolbox.
(In reply to Tim Nguyen [:ntim] from comment #2)
> This can be used for tracking right ?

Not really. These features are not directly related. "Emulation" is a pretty broad concept.

UA could be in the settings panel, accelerometer need controls, "Firefox OS stuff", not sure what this is, ...

Viewport, how do you "emulate" a viewport beside resizing the actual viewport or implementing some sort of scaling of the UI (we tried that for the responsive mode, with faking subpixel rendering).

And geolocation & network will be part of a different thing we call "profile".

> Also, it should be an actual tool in the DevTools toolbox.

I'm not sure about requiring a toolbox to do all that.

I'll close this bug because it's to vague.

Each of these are features we want, but let's discuss them in separate bugs, or maybe group some of them in smaller subsets.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #3)
> (In reply to Tim Nguyen [:ntim] from comment #2)
> > This can be used for tracking right ?
> 
> Not really. These features are not directly related. "Emulation" is a pretty
> broad concept.
> 
> UA could be in the settings panel, accelerometer need controls, "Firefox OS
> stuff", not sure what this is, ...
Pushing notifications in one click, changing battery status, ... 

> Viewport, how do you "emulate" a viewport beside resizing the actual
> viewport or implementing some sort of scaling of the UI (we tried that for
> the responsive mode, with faking subpixel rendering).
You just mentioned how :)

> > Also, it should be an actual tool in the DevTools toolbox.
> 
> I'm not sure about requiring a toolbox to do all that.
We have most of the features currently burried in about:config, or hidden into the developer toolbar. It'd be nice to actually being able to access those things easily, all in one place. Also, IE and Chrome have a pane dedicated for emulation, you can check for reference.
(In reply to Tim Nguyen [:ntim] from comment #4)
> (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> comment #3)
> > (In reply to Tim Nguyen [:ntim] from comment #2)
> > > This can be used for tracking right ?
> > 
> > Not really. These features are not directly related. "Emulation" is a pretty
> > broad concept.
> > 
> > UA could be in the settings panel, accelerometer need controls, "Firefox OS
> > stuff", not sure what this is, ...
> Pushing notifications in one click, changing battery status, ... 
> 
> > Viewport, how do you "emulate" a viewport beside resizing the actual
> > viewport or implementing some sort of scaling of the UI (we tried that for
> > the responsive mode, with faking subpixel rendering).
> You just mentioned how :)

Not that easy. Mostly because of how people use viewport (device-width/height is not a thing easy to simulate *at all*).

> > > Also, it should be an actual tool in the DevTools toolbox.
> > 
> > I'm not sure about requiring a toolbox to do all that.
> We have most of the features currently burried in about:config, or hidden
> into the developer toolbar. It'd be nice to actually being able to access
> those things easily, all in one place. Also, IE and Chrome have a pane
> dedicated for emulation, you can check for reference.

I'm not saying we should not build something, but we need a much more precise bug description, with a comprehensive list of features and requirements, with a well defined scope. We don't throw tools just like that :)
As someone on the Mozilla team just noticed, the Chrome emulation tools just updated and are now even more incredible:

https://twitter.com/canuckistani/status/481165279264014336
(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #5)
> (In reply to Tim Nguyen [:ntim] from comment #4)
> > (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> > comment #3)
> > > (In reply to Tim Nguyen [:ntim] from comment #2)
> > > > This can be used for tracking right ?
> > > 
> > > Not really. These features are not directly related. "Emulation" is a pretty
> > > broad concept.
> > > 
> > > UA could be in the settings panel, accelerometer need controls, "Firefox OS
> > > stuff", not sure what this is, ...
> > Pushing notifications in one click, changing battery status, ... 
> > 
> > > Viewport, how do you "emulate" a viewport beside resizing the actual
> > > viewport or implementing some sort of scaling of the UI (we tried that for
> > > the responsive mode, with faking subpixel rendering).
> > You just mentioned how :)
> 
> Not that easy. Mostly because of how people use viewport
> (device-width/height is not a thing easy to simulate *at all*).
> 
> > > > Also, it should be an actual tool in the DevTools toolbox.
> > > 
> > > I'm not sure about requiring a toolbox to do all that.
> > We have most of the features currently burried in about:config, or hidden
> > into the developer toolbar. It'd be nice to actually being able to access
> > those things easily, all in one place. Also, IE and Chrome have a pane
> > dedicated for emulation, you can check for reference.
> 
> I'm not saying we should not build something, but we need a much more
> precise bug description, with a comprehensive list of features and
> requirements, with a well defined scope. We don't throw tools just like that
> :)

Can this be an user story them ? I'll create a live mockup later if I have some time.
Maybe you should start a discussion in the devtools mailing list about this. I think it's a pretty important set of tools, and we need to understand where they should live and how they could fit in the current UI (toolbox, responsive mode, webide).
Can we un resolve-invalid this bug ?

This request has started to pick up pace as users are awed by the emulation features that Chrome DevTools provide now.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
We need product input here.
Flags: needinfo?(jgriffiths)
There are significant challenges here, and we are forced to solve them in different ways because we're gecko, not descended from webkit. I'll take each item here:

- User agent

* we can't really switch the UA to Safari on iPad and claim to render properly, so that's a pretty useless tool for debugging rendering issues. The UA switcher tool is then reduced to being useful for debugging what the server sends back ( assuming the server does this  ) and there are lots of add-ons available already for that:

https://addons.mozilla.org/en-US/firefox/search/?q=user+agent&appver=29.0&platform=Darwin

- Geolocation (custom coordinates and unavailable geolocation)
- Accelerometer

We have bugs for Geo ( bug 925761 ) but I cannot find one for acceleromter. I think they're high priority personally ( especially Geo ) and I suspect you there are interesting things we could do. I would not have placed them as higher priority than what Paul's team is currently working on though.

- Viewport and dppx (I think it's possible via about:config, but it'd be nice to get a temporary feature)

This is only really relevant to devices running Gecko with different display densities, becaus eif you care about display densities you're already caring about how things render at the pixel level, and we can never really claim to emulate a webkit browser

- Media queries (we can do this via GCLI, but it'd be nice to get an UI for this)

We have a UI for this, and are considering enhancing the UI as part of responsive design mode in response to the very nice tools now in chrome and especially Responsive Inspector:

https://chrome.google.com/webstore/detail/responsive-inspector/memcdolmmnmnleeiodllgpibdjlkbpim?hl=en

See bug 1031585 for more info. I don't think we need to slavishly copy the UI metaphor, and I actually dislike how difficult it is to discover the media query ui in chrome.

- Network emulation (see chrome devtools)

I would love to be able to do offline per-document. I'm a lot less interested in chrome's 'emulation' of gprs or whatever, it just looks to me like they baked in latency, but latency isn't the whole picture here. I think what you really want is an http proxy that becomes a 'chaos monkey' for network responses based on some rulesets / heuristics. Chrome's tool just slows things down; a real tool here would randomly slow some things down and load things out of order.

There is a lot to do here to help web developers with sketchy mobile networks but it's difficult to see the browser's role in this?

- Firefox OS stuff

I think we have to be really excellent about Firefox OS stuff, but I also think Paul's team is doing an amazing job of keeping up here. What's missing? I bet these are things already on the roadmap.

Aside: I'm not sure if this has really sunk in for people yet but fever dream will allow us to solve some of these problems by hooking our tools up to blink and iOS - giving us access to a real webkit-based renderer. I'm particularly interested in what sorts of extensions people will be able to build that use RDP to target these remote runtimes - a blink version of responsive design view? Multiple viewports using different renderers?

Tim: thanks for logging this as a call-out that this collection of features is an important cluster of capabilities to help people with mobile development. I think fever dream is a huge piece of this but all of these other details matter as well. Feel free to log bugs if something specific is missing, and have it block this bug.
Flags: needinfo?(jgriffiths)
Duplicate of this bug: 1070433
(In reply to Jeff Griffiths (:canuckistani) from comment #11)
> 
> - Network emulation (see chrome devtools)
> 
> I would love to be able to do offline per-document. I'm a lot less
> interested in chrome's 'emulation' of gprs or whatever, it just looks to me
> like they baked in latency, but latency isn't the whole picture here. I
> think what you really want is an http proxy that becomes a 'chaos monkey'
> for network responses based on some rulesets / heuristics. Chrome's tool
> just slows things down; a real tool here would randomly slow some things
> down and load things out of order.
> 
> There is a lot to do here to help web developers with sketchy mobile
> networks but it's difficult to see the browser's role in this?

I think the role for the browser here is to help diagnose your webpage's performance over a slow loading network.  A common problem would be that a page is completely blank while loading a script at the top of the page, seeing how confusing it is when some button that sends off an ajax request doesn't give any feedback, other things like that.  It's a useful feature to emulate a slow network, even if it isn't the best possible implementation.
I wanted to chime in to outline the difference in how to emulate slow networks whether you're dealing with mobile versus LAN or WiFi. In a LAN or WiFi, the throughput is usually so high that it's really the latency that is most often the issue. Latency is also most often the issue with use of HTTP. Things change the moment you use webSocket. In that case, you have a dedicated pipe that's opened, and the latency issue drops off radically. If you really want to get sophisticated you can use ipfw on Mac OS X to model different amounts of packet loss and latency. (If you use OSX that is.) Not sure the browser could ever really simulate packet loss very well unless you built an emulation for packet losses in right at the lowest levels in Firefox.

When dealing with mobile, there are additional issues related to network that affect power usage as well as giving poor network performance. There is actually a simulator tool on the AT&T developer website that provides a way to explore the effects of networking and battery usage. https://developer.att.com/application-resource-optimizer. The issue stems from RRC state transitions, you can read more about that here: http://www2.research.att.com/~sen/pub/LTE_mobisys12.pdf. 

Bottom line is that there is a lot of stuff to consider and it would be pretty hard to create an emulation tool that would take into account all the effects associated with latency deltas, packet losses and RRC state transitions. If you are going to be serious about optimizing your app, you're gonna use ipfw to simulate that sort of thing on a LAN, and you're gonna want to use an emulator like AT&T's application resource optimizer which integrates with the Android emulator to properly emulate a mobile network. 

One last note, we really need to improve our network inspector so that it's capable of telling developers where network errors occur and what they cause, and most importantly, why don't any of the browsers inform users know when the network is slow? That should really not be the job of web apps. It's common for skype to let folks know when the network is bad, the browser should do the same.
I think it would make sense to add a "Device" panel to the toolbox, that could control all the device emulation features, including Responsive Design features. This would also be a good place to offer a selection of device profiles, which upon selection would set values for the other emulation features (e.g. screen size, user agent, touch emulation, etc) like in chromium's device emulation.

The idea of a toolbox panel is not new, and was independently suggested multiple times e.g. in bug 828008 comment 7 and by myself at the october 2014 devtools work week.

I started working on such a Device panel, so I'm tentatively assigning myself to what actually feels more like a meta bug. I'm also working on the device profiles (no bug yet) which ties into device emulation for the devtools and for the Firefox OS simulator.

Thanks Jeff for laying out the challenges for the different components. As a whole, they could help toward "a way to *fully* emulate the mobile browser" requested on uservoice[1] with currently 76 votes.

- User Agent:

In spite of the rendering limitations and the existing add-ons, I believe the ability to change that string directly from devtools has sufficient expressed interest to be taken seriously. The feature could simply be an input field in the "Device" panel, and can be automatically changed when a device profile is selected (e.g. selecting "Firefox OS Flame" should set something like "Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1").

Bug 828008 makes the case, and the feature currently has 87 votes on uservoice[3].

- Geolocation:

Bug 925761 has an r+ed patch that can spoof GPS coordinates for the whole browser (no "unavailable position" spoofing yet). Bug 1073419 however is trying to achieve geolocation denying, blurring, and spoofing on a per-origin basis (for Firefox OS, not sure how that will work on desktop).

Side note: "Geolocation emulation in Firefox OS simulator" currently has 30 votes on uservoice[2].

- Accelerometer:

To my knowledge, this has not been widely requested (outside of 13 votes on uservoice), but it makes sense as a lower-priority addition to a "Device" panel.

- Viewport:

In spite of the screen-pixel vs device-independent-pixels vs viewport-pixels madness, the Responsive Design view has somewhat satisfying dimension controls that look simple. Chromium's device emulation opted for defining the viewport as just swappable "width" and "height" dimensions along with a "deviceScaleFactor" value[4]. If there is pixel-not-pixel or viewport-decision-tree madness involved (see bug 752473 comment 19) then either it's either hidden away or lied about.

I think Responsive Design mode emulates viewport well enough for now, and whenever you choose a device profile in the Device panel we could activate Responsive Design and set its dimensions to those in the profile.

Chromium also has a nice "shrink to fit" option for viewports that take up more space than is available, that dynamically scales down to available space by preserving aspect. For our Responsive Design view, this feature has 12 votes on uservoice.

I didn't know we had a GCLI feature for media queries, but it'd definitely be nice to have UI for that in Responsive Design and/or the Device panel.

Maybe it's also worth noting that a multi-screen Responsive Design view currently has 23 votes on uservoice, and there are 17 votes for a better touch emulation.

- Pixel density:

This probably ties into media queries and img srcset (not in Firefox yet[5]). I'm not familiar with all the technical implications, but since fundamentally simulating will never be as good as the real thing, my current bet is that something like Chromium's "deviceScaleFactor" should be fine (e.g. they define the Nexus 4 screen dimensions as {width:384,height:640,deviceScaleFactor:2} which I assume means 384x640 viewport with twice as many pixels on screen).

- Network:

I'll try not repeating too much of the thread here, but I also think that simulating "2G/3G/4G/WiFi" is cute but not very useful as is. Per-page offline on the other hand is great.

The use I can see for simulating a "slow network" is to improve perceived performance, like Brian said (e.g. a page shouldn't load social widgets before their main content!). This could be achieved by adding controllable random latency (not sure if throttling throughput is useful here).

Then the network can be made "unreliable" to test a website's resilience in the face of bad conitions, e.g. by randomly dropping requests (with controllable probability).

A "chaos monkey" mode like Jeff suggests seems like a good idea, but I'm not sure how close to the real thing even a well-researched throughput / latency / packet loss simulation can be. So maybe let's not get too serious about it.

- Firefox OS simulator:

More simulation features are in the works for FxOS, and they might or might not become available for the rest of the web (my hope is that they will somehow).

Bugs 989926, 1038606 and 1002463 basically aim to simulate a SIM card (Radio Interface Layer) with PIN lock and PUK code, controllable network states, simulated calls, etc.

Bug 943528 aims to spoof the Mobile Network and Country Codes (MNC/MCC) a SIM card exposes as one way to trick the simulator into believing it's in another country/city.

Bug 996619 aims to simulate an SD card in the device.

And lots more, like Time Zones, Language, custom startup parameters, custom paths for B2G/Gaia, etc.

[1] https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5895504-give-me-a-way-to-fully-emulate-the-mobile-browse
[2] https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5786927-geolocation-emulation-with-the-firefox-os-simulato
[3] https://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5895517-can-you-please-add-user-agent-switcher-in-tool
[4] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/toolbox/OverridesUI.js&l=312
[5] http://caniuse.com/#feat=srcset
Assignee: nobody → janx
Depends on: 925761
For pixel density, we have a pref that controls that (layout.css.devPixelsPerPx), but it's browser wide, so it also makes the browser bigger.
For pixel density, I actually wrote a patch that does change the DPI per tab. See bug 758011. I just never got a chance to finish it.
Thanks Paul! Let's depend on it for now.

Chrome's implementation of Device Pixel Ratio with their APZC-equivalent is supposed to get everything looking like a real device, e.g. supporting all meta viewport rules and media queries, kinetic scrolling, pinch-zoom (with Shift I think) should hit the right zoom min and max, etc. Paul Irish challenges us to find situations in which their simulation doesn't look/act like a real device.
Depends on: 758011
Depends on: 1073419
Depends on: 1110207
Depends on: 1133927
I uploaded a catalog of many reference device properties to bug 1133927, feel free to chime in there.
Depends on: 1069882
Attached file emulation.xpi
Here's a prototype of how an emulation tool could look like. It makes use of the device list :janx provided in bug 1133927.
The code is quite hacky (it relies on some Firefox prefs) and this is very buggy (especially pixel ratio emulation). Just a quick demo I made up :)
Thanks Tim, I really like your prototype! Would you like to make it into an official devtool? I can help :)
(In reply to Jan Keromnes [:janx] from comment #21)
> Thanks Tim, I really like your prototype! Would you like to make it into an
> official devtool? I can help :)

Yeah, sure ! I probably won't have much time though :/
Depends on: 1137681
Depends on: 1137699
Depends on: 1137701
Nice progress with the addon.  Why not roll these new options into responsive design mode?  The downside of adding a brand new panel for this is that you will likely be wanting to change these options *while* using some other tool.  So you'd be switching between Inspector and Emulation or Netmonitor and Emulation.

It would stay out of the way if these settings could be changed from the controls provided in the content area by responsive design.  It would also be easy to disable / reenable all emulation features at once by disabling the mode, and would leave no question about whether they are still on.
I created this prototype : http://ntim.altervista.org/FirefoxUX/DesignerToolbox/

You can check the prototype on your phone to see how it looks like there. There were concerns about touch screen typing. To overcome this, the device list is as well available on the touch screen.
I just talked to Brian about this, and here's what could be done : Enhance the responsive mode UI for Firefox Desktop, and use a new emulation panel for remote targets (kinda like how the scratchpad works).

Thoughts ?
Flags: needinfo?(paul)
Flags: needinfo?(jryans)
Flags: needinfo?(jgriffiths)
Flags: needinfo?(janx)
Flags: needinfo?(bgrinstead)
Flags: needinfo?(shorlander)
(In reply to Tim Nguyen [:ntim] from comment #25)
> I just talked to Brian about this, and here's what could be done : Enhance
> the responsive mode UI for Firefox Desktop, and use a new emulation panel
> for remote targets (kinda like how the scratchpad works).
> 
> Thoughts ?

I'm cautiously optimistic about this approach, but I think we need some interaction design smarts involved. Also, needinfo'ing Axel as this is his side of things.
Flags: needinfo?(jgriffiths) → needinfo?(akratel)
(In reply to Tim Nguyen [:ntim] from comment #25)
> I just talked to Brian about this, and here's what could be done : Enhance
> the responsive mode UI for Firefox Desktop, and use a new emulation panel
> for remote targets (kinda like how the scratchpad works).
> 
> Thoughts ?

Yeah. It's a thing we wanted to do for a long time. I think it makes sense.
Flags: needinfo?(paul)
Cool concept overall! A few nits:
- I'd prefer separating viewport width and height inputs from the device selector, that way the latter becomes cleaner, you understand that the selector changes values of other inputs (e.g. width, height, pixel ratio), but that you can also customize these (upon which the selector switches back to something like "<custom device>").
- I don't like that the User Agent is hidden by default. You don't see that it gets modified by the device selector, and customizing it is tricky. I'd prefer if it weren't hidden, but underneath/next to the viewport controls, as in chrome's device mode.
- GPS and accelerometer could be widgets like that, it's not hard to imagine a map or a 3D shape to rotate. I'd still prefer them in a panel, but I guess your design would work (except for remote targets).
Flags: needinfo?(janx)
(In reply to Jan Keromnes [:janx] from comment #28)
> Cool concept overall! A few nits:
Thanks for the feedback !

> - I'd prefer separating viewport width and height inputs from the device
> selector, that way the latter becomes cleaner, you understand that the
> selector changes values of other inputs (e.g. width, height, pixel ratio),
> but that you can also customize these (upon which the selector switches back
> to something like "<custom device>").
Hmm, I'm not sure how that would work, but I can try that.

> - I don't like that the User Agent is hidden by default. You don't see that
> it gets modified by the device selector, and customizing it is tricky. I'd
> prefer if it weren't hidden, but underneath/next to the viewport controls,
> as in chrome's device mode.
The UA icon should turn blue when the UA gets modified, I think it's pretty clear that way. Maybe the button could flash if it's already blue.

> - GPS and accelerometer could be widgets like that, it's not hard to imagine
> a map or a 3D shape to rotate. I'd still prefer them in a panel, but I guess
> your design would work (except for remote targets).
Instead of a simple input, it could use some widgets instead (a map and 3D shape), this was just a quick prototype anyway.
For remote targets, we'll have an emulation panel instead (kinda like how the scratchpad panel only appears on remote targets).
Depends on: 1138456
Is there a reason we can't just put the panel in the tab real estate where the page was? Or is it going to be a separate panel?
Flags: needinfo?(akratel)
(In reply to Tim Nguyen [:ntim] from comment #29)
> Thanks for the feedback !

You're quite welcome!

> > - I'd prefer separating viewport width and height inputs from the device
> > selector [...]
> Hmm, I'm not sure how that would work, but I can try that.

That's what chrome device mode does: https://developer.chrome.com/devtools/docs/device-mode-files/device-and-network-tools.png (width, height and pixel ratio are separate editable fields).

> The UA icon should turn blue when the UA gets modified, I think it's pretty
> clear that way. Maybe the button could flash if it's already blue.

Hm, you're right this could work.

> Instead of a simple input, it could use some widgets instead (a map and 3D
> shape), this was just a quick prototype anyway.
> For remote targets, we'll have an emulation panel instead (kinda like how
> the scratchpad panel only appears on remote targets).

I'm looking forward to seeing this in action! Thanks a lot for the prototypes, I think they make sense and solve many problems in a smart way.
I published the add-on on Github : https://github.com/nt1m/devtools-emulation
(In reply to Tim Nguyen [:ntim] from comment #32)
> I published the add-on on Github : https://github.com/nt1m/devtools-emulation

Thanks for moving forward with this!  I checked it out, and I like the device list and pixel ratio features.  Using it confirmed my feeling that these controls would feel more natural as 'part' of the responsive design mode.  Having it a separate panel that essentially controls RDM feels weird because (a) I can't use the other tools when that panel is opened and (b) there are already controls above the content in RDM so it feels arbitrary which ones end up there vs which ones end up in the panel.

I'd love to see this prototype modify the RDM UI directly, taking into account some of your previous design ideas.
Flags: needinfo?(bgrinstead)
(In reply to Brian Grinstead [:bgrins] from comment #33)
> (In reply to Tim Nguyen [:ntim] from comment #32)
> > I published the add-on on Github : https://github.com/nt1m/devtools-emulation
> 
> Thanks for moving forward with this!  I checked it out, and I like the
> device list and pixel ratio features.  Using it confirmed my feeling that
> these controls would feel more natural as 'part' of the responsive design
> mode.  Having it a separate panel that essentially controls RDM feels weird
> because (a) I can't use the other tools when that panel is opened and (b)
> there are already controls above the content in RDM so it feels arbitrary
> which ones end up there vs which ones end up in the panel.
Thanks for your feedback ! Seems like we still want to keep the panel for remote targets though. But I do agree it's more natural in RM.

> I'd love to see this prototype modify the RDM UI directly, taking into
> account some of your previous design ideas.
I'll do my best, but I think some features can be implemented right away, like populating the responsive mode select with all device presets for example.
(In reply to Brian Grinstead [:bgrins] from comment #33)

Tim: this is a great start - thanks!

...
> I'd love to see this prototype modify the RDM UI directly, taking into
> account some of your previous design ideas.

Agreed!
Flags: needinfo?(jryans)
Depends on: 1029203
Marking this as a feature to help with tracking, QA, and general awareness of active/upcoming work.
Keywords: feature
Depends on: 1156789
Status: REOPENED → NEW
Depends on: 943528
No longer depends on: 1073419
Flags: needinfo?(shorlander)
Depends on: 920956
Depends on: 1031585
Depends on: 1228819
Unassigning myself as I'm not actively working on this.
Assignee: janx → nobody
I would like to add emulation for print media as well.
(In reply to kamal.bhatt from comment #38)
> I would like to add emulation for print media as well.

In the developer toolbar (Shift+F2), you can type `media emulate print`.
Severity: normal → enhancement
Keywords: meta
Priority: -- → P3
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-ie][parity-chrome]
Product: Firefox → DevTools
Depends on: 1508196
Summary: Create Emulation developer tool → [meta] Create Emulation developer tool
You need to log in before you can comment on or make changes to this bug.