New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 712819
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Blocked on: View detail
issue 595993
issue 638552



Sign in to add a comment
link

Issue 709838: DevTools: service worker controlling multiple pages uses overridden UA from one of them

Reported by falken@chromium.org, Apr 10 2017 Project Member

Issue description

Reporting a feature request seen internally.

Honor devtools user agent override in service worker contexts

Currently user agent override is per-tab so service worker doesn't pick them up?

Leaving this as Untriaged so DevTools team can triage it, but keeping ServiceWorker component so ServiceWorker team can track it.
 

Comment 1 by pfeldman@chromium.org, Apr 10 2017

Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)

Comment 2 by dgozman@chromium.org, Apr 10 2017

We pick up service workers in the same frontend, and the user agent override should work there.
Are you talking about service worker being inspected in a separate DevTools window?

Comment 3 by falken@chromium.org, Apr 13 2017

I'm not 100% sure. This was reported internally and Jake seemed to know what it's about.

"feature request: SW fetch honors UA overrides in DevTools.  I know that's not possible to do correctly due to the many-to-one relation of documents to workers.  But for the very common dev case of one tab, it would be handy."

"Yeah, I wish those settings were origin-wide"

Comment 4 by hurst@google.com, Apr 13 2017

Repro steps:
- Chrome Linux Version 57.0.2987.133 (64-bit)
- Prepare a page that: 1) twiddles document output based on desktop/mobile UA, 2) routes document requests through a fetch invocation in SW.
- Visit page in normal/desktop mode.  Desktop output is shown as expected.
- In same tab, turn on devtools device emulation for any mobile device.
- Refresh page.

Expected: SW fetch request uses devtools mobile UA override and server responds with mobile page variant.

Actual: fetch request uses normal/desktop UA and server responds with desktop page variant.

Comment 5 by dgozman@chromium.org, Apr 13 2017

Re #c4: could you, by any change, share a specific page with SW to repro on?

Comment 6 by steve.wo...@gmail.com, Apr 18 2017

This bug can be seen on https://usertesting.yellqatest.com (we use adaptive layouts on UA).

The UA appears to be taken from the first window that started the worker, rather than from the devtools instance of that page. The test team over here has multiple windows open and when switching UA they often get the desktop response, rather than the mobile one

Comment 7 by jakearchibald@chromium.org, Apr 18 2017

Reduced test case:

1. Go to https://cdn.rawgit.com/jakearchibald/ac9be9a5e2633e926d14f20fcace858e/raw/41df09c5d24d94f97946c5d941a00766ec265973/
2. Refresh it when it asks.
3. Open devtools & set UA string to be one of the Blackberry ones
4. Refresh page. Observe change.
5. Open a new tab.
6. Open devtools.
7. Set UA to be one of the UC Browser ones.
8. Refresh page. You still get the Blackberry UA.

This is because we set overrides on the page and the service worker which devtools attaches to. The second window isn't attached to the service worker, so it's still applying the Blackberry override.

In similar issues, I've suggested that our overrides should be at an origin level, but I guess that doesn't really help here, if developers want to have a different UA set for different tabs.

Comment 8 by jakearchibald@chromium.org, Apr 18 2017

For anyone else encountering this issue, a workaround is to set up two profiles, and use different UA settings in each.

Comment 9 by dgozman@chromium.org, Apr 18 2017

Summary: DevTools: service worker controlling multiple pages uses overridden UA from one of them (was: Honor devtools user agent override in service worker contexts)
Thanks for clarification. Indeed, having a single service worker with multiple pages leads to uncertainty in which override to use. This is a natural limitation of one-to-many relationship.

We can in theory fix this by plumbing the information about page requested the resource, but that is hard and would bring even more confusion - you can now get different UAs in a single service worker.

re #c6: perhaps, you need to reinstall service worker if it was served with wrong UA first time. "Update on reload" checkbox in DevTools > Application > Service Workers should help here.

Comment 10 by steve.wo...@gmail.com, Apr 18 2017

These don't have the wrong UA, I should be able to change the UA at any time, which is a power that devtools gives me.

I don't think the proposed fix is confusing to the end user - the page loads the version requested with the UA that is set in dev tools. The common scenario here is where the user has the same domain open in another tab and has simply forgotten about it, and without checking the service worker section to see what has focus, they get a response they don't expect.

I've checked this in Firefox 54, and the proposed fix is how it behaves.

Comment 11 by jakearchibald@chromium.org, Apr 19 2017

> in theory fix this by plumbing the information about page requested the resource

This would be incompatible with the fetch spec, which sets the UA header when going to the network (after the request hits the service worker).

Also, if you hack it with some flag on event.request, that will fail in cases like fetch(fetchEvent.request.url).

We could try to make it so changing tabs disconnects that tab's devtools from the service worker, then connects the new tab's devtools to the service worker. Pretty hacky though, and may cause some race conditions with requests in-flight.

I guess the best short-term fix is to show a warning when UA overrides aren't going to be honoured.

> I don't think the proposed fix is confusing to the end user

Which proposal are you talking about?

Comment 12 by jakearchibald@chromium.org, Apr 19 2017

> I've checked this in Firefox 54, and the proposed fix is how it behaves.

I just tested in Firefox 54, and none of the overrides seem to be applying to requests made from a service worker. Surely that isn't the proposal?

Comment 13 by tyoshino@chromium.org, Apr 19 2017

Blockedon: 638552 595993

Comment 14 by tyoshino@chromium.org, Apr 19 2017

Due to the current SW architecture in Chrome, a controlled page generates User-Agent header for requests before they get into SW. In SW, when a request is forwarded the UA header will be dropped and the net stack adds it again.

Maybe you're facing this issue.

Added related issues.

Comment 15 by steve.wo...@gmail.com, Apr 19 2017

>> I don't think the proposed fix is confusing to the end user

> Which proposal are you talking about?

I mean the one in c#9 - "We can in theory fix this by plumbing the information about page requested the resource, but that is hard and would bring even more confusion - you can now get different UAs in a single service worker."

> I just tested in Firefox 54, and none of the overrides seem to be applying to requests made from a service worker. Surely that isn't the proposal?

I tested the Yell example in Firefox 54 in responsive design mode, and I got the correct mobile / desktop page as requested. I have now tested the reduced test case and it doesn't seem to change the UA at all, so something else is going on here.

Comment 16 by bke...@mozilla.com, Apr 19 2017

> I just tested in Firefox 54, and none of the overrides seem to be applying to requests made from a service worker. Surely that isn't the proposal?

Out of curiousity, how are you applying the UA override in FF?  I just tried using a web extension:

https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-revived/?src=search

And I see the overriden UA.  Its possible the result would be different with the old Responsive Design Mode (only shown in single process mode I think) or with a legacy addon.

Comment 17 by dgozman@chromium.org, Oct 4 2017

Owner: allada@chromium.org

Comment 18 by pfeldman@chromium.org, Dec 14 2017

Mergedinto: 712819
Owner: dgozman@chromium.org
Status: Duplicate (was: Assigned)

Sign in to add a comment