Mike Taylor [:miketaylr] Reporter
	Description • 8 years ago

Currently RDM identifies as Chrome Mobile if you select an Android device. I get why, but I think it sends the wrong message -- we should identify as Firefox for Android, with the option to switch to Chrome Mobile.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 1 • 8 years ago

At the moment, we're using Chrome UAs for the devices because that's default browser.

I believe Mike's main point is that this could lead to confusion, since we're using Gecko to display the page content but sending a Chrome UA.  Sites that use UA detection to send different content to different UAs could trigger a confusing experience by sending Chrome specific content that Gecko won't interpret correctly.

One challenge here is the RDM feature set covers two different mindsets:

A. Checking a responsive site at different sizes (where I would argue screen size, dPR are the main factors, and UA would hopefully not be used by the site)
B. Testing a site as a specific device by simulating that device as closely as possible (size, dPR, UA, touch events, etc.)
  * We can only go so far here, since we're always using Gecko at the core

For use case A, I am hoping UA does not matter much.  For use case B, is it more useful to:

1. Send the device UA (usually Chrome) even though we use Gecko as the engine
2. Send a Gecko UA even though that's not what the device would do
3. It's hard to know what the user wants, so we should make both available

Mike seems to be arguing for 3 (an option to choose the UA as needed).  In bug 1306198, I suggested showing a browser icon next to the device with UA in the tooltip (or something like this) to indicate the UA sent.  This could expand to be a UA menu (separate from the device selector) to choose a specific UA.

Bryan, Helen, any thoughts?

	Mike Taylor [:miketaylr] Reporter
	Comment 2 • 8 years ago

For A, I would think meta viewport would also come into play, but currently RDM doesn't do that, AFAIK. Unfortunately we've seen instances of some UAs being served nice, responsive sites, and others served different content. It's a jungle out there.

(FWIW, I think new RDM is awesome, and look forward to iterations where devs can test their sites while pretending to be Firefox for Android)

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 3 • 8 years ago

I like your suggestion above and in bug 1306198, given that we know sites like gmail will send different JS based on browser this could make RDM a good test tool for comparing responses between UA strings.  

Don't we already have a UA chooser widget?  Can we improve that and bring it in?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 4 • 8 years ago

(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #3)
> Don't we already have a UA chooser widget?  Can we improve that and bring it
> in?

What's this UA chooser you are thinking of?  Did you mean something you've seen before in DevTools / Firefox / Mozilla something somewhere?

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 5 • 8 years ago

I thought I saw :gl do some work on this at one point...

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 6 • 8 years ago

:gl, any idea what :clarkbw is thinking of here?

	Gabriel [:gl] (ΦωΦ)
	Comment 7 • 8 years ago

Sorry, I never worked on a UA chooser.

	Tim Nguyen :ntim
	Comment 8 • 8 years ago

(In reply to Bryan Clark (DevTools PM) [:clarkbw] (out until Jan 2nd) from comment #3)
> Don't we already have a UA chooser widget?  Can we improve that and bring it
> in?

There was an UA input in the old RDM that I've worked on: http://i.imgur.com/o5gLcmR.gif

The new RDM just applies the UA associated with the device: bug 1254386.

I've suggested a possible UI that would somewhat solve the issue: bug 1319944.

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 9 • 8 years ago

> I've suggested a possible UI that would somewhat solve the issue: bug 1319944.

That looks like a pretty good first step to me.  We can try to iterate on that later with some presets for UAs we know are associated with the device.

	Botond Ballo [:botond]
	Comment 10 • 7 years ago

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> One challenge here is the RDM feature set covers two different mindsets:
> 
> A. Checking a responsive site at different sizes (where I would argue screen
> size, dPR are the main factors, and UA would hopefully not be used by the
> site)
> B. Testing a site as a specific device by simulating that device as closely
> as possible (size, dPR, UA, touch events, etc.)
>   * We can only go so far here, since we're always using Gecko at the core

Another use case is testing a Gecko change. For that, it's useful to be able to get RDM to behave as close as possible to how Firefox for Android would on the given device.

	:Harald Kirschner :digitarald
	Comment 11 • 6 years ago

+Martin to look into prioritizing this for the quality work as its a long-standing issue that also affects GeckoView work