Device emulation and responsive testing tools should be available independent of DevTools

[codepo8]

As described in this explainer document the device emulation and responsive design tools should be available in the main browser window, without the need of DevTools being open at the same time. This would enable non-developer users to test products in different states and users of single screens in lower resolution to simulate high-resolution devices without having to zoom out.

The Microsoft Edge Extension for Visual Studio Code currently features a screencast with an own toolbar that offers similar functionality.

Other browsers like Firefox also have this option.

[AB#40624471]

[WebMechanic]

FF has Ctrl+Sh+M (Win) to toggle "mobile view" but then lacks an icon for that to put on the browser toolbar; Chromiums lack the ability to customize a toolbar at all to get quick access to anything, so that'd be a starter for better DX/UX for that line of browsers.

I got so used to using the keyboard shortcut that it always annoys me that I must open DevTools first in Chrome/Edge, click on that Mobile icon (or F12 + Ctrl+Sh+M) to get the responsive view: too many steps that definitely need a change. Performing that task using browser menus is a UI desaster.

Speaking of other required features: Sizzy appears to be the only tool (using Chromium under the hood) that also simulates the keyboard drawer if you tap into a form control: that's the main reason we also use Sizzy for testing.

Without that annoying keyboard or url bar (or any browser chrome) showing up during interactions with a page, you can't safely test a design and interactions and the upcoming viewport unit variants can't be tested at all.

All browsers provide responsive/mobile view modes, but it's a stretch to call any of them device emulations.

[captainbrosset]

All browsers provide responsive/mobile view modes, but it's a stretch to call any of them device emulations.

Very good point. Browser DevTools only provide a way to resize the viewport, fake the UA string, and enable touch events. But they're far from actually emulating real devices.

Anyway, this is a great issue to track. Having access to the device mode without requiring DevTools to be opened first would be great.

And I like the idea of the keyboard drawer. @WebMechanic would you mind opening another issue on this repo just about this so we can have a discussion about it there, in more detail, and see if there's interest from other people?

[codepo8]

FF has Ctrl+Sh+M (Win) to toggle "mobile view" but then lacks an icon for that to put on the browser toolbar; Chromiums lack the ability to customize a toolbar at all to get quick access to anything, so that'd be a starter for better DX/UX for that line of browsers. I got so used to using the keyboard shortcut that it always annoys me that I must open DevTools first in Chrome/Edge, click on that Mobile icon (or F12 + Ctrl+Sh+M) to get the responsive view: too many steps that definitely need a change. Performing that task using browser menus is a UI desaster.

That is exactly what we are working on.

Speaking of other required features: Sizzy appears to be the only tool (using Chromium under the hood) that also simulates the keyboard drawer if you tap into a form control: that's the main reason we also use Sizzy for testing.

Also a very good point. I assume they are different sizes on different devices though, so we need to check where we could get that information.

Without that annoying keyboard or url bar (or any browser chrome) showing up during interactions with a page, you can't safely test a design and interactions and the upcoming viewport unit variants can't be tested at all.

Well, it is tricky to bring tooling for non-finalised CSS features. We had a lot of trouble getting the forced colours emulation to work as the spec kept changing. But this is also on our radar. Great point about the URL bar, thank you.

All browsers provide responsive/mobile view modes, but it's a stretch to call any of them device emulations.

Yes, that is a big concern of ours. We don't want to over-promise here. What would you consider a good naming for it?

[WebMechanic]

Yes, that is a big concern of ours. We don't want to over-promise here. What would you consider a good naming for it?

@codepo8 what's wrong with "Responsive Design Mode"? ("mehr" steckt ja bei niemandem bislang dahinter) works for FF :) although Ctrl+Sh+M seems a relic when it was "mobile view" or such.