Issue metadata
Sign in to add a comment
|
[Chrome Apps] webview.setUserAgentOverride() doesn't work
Reported by
yoichiro...@gmail.com,
Jun 20 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36
Steps to reproduce the problem:
1. Start a Web Server on the local PC on the port 8080.
2. Extract the attached file, and register the app to the Chrome Beta.
3. Launch the app. Then, the webview opens the URL "http://127.0.0.1:8080/?[random numbers]".
4. Confirm the access log of the local Web Server.
What is the expected behavior?
The access should be recorded in the access log like the following:
[Tue Jun 20 2017 19:07:20 GMT+0900 (JST)] "GET /?1497953240279" "foobar"
In the above sample log, the user agent string is "foobar", because the app overrides the user agent string by the following code:
var webview = document.getElementById("wv");
webview.setUserAgentOverride("foobar");
webview.src = "http://127.0.0.1:8080/?" + (new Date()).getTime();
What went wrong?
The webview.setUserAgentOverride() doesn't work. Thus, the original user agent is recorded in the access log like the following:
[Tue Jun 20 2017 19:35:31 GMT+0900 (JST)] "GET /?1497954930876" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36"
Did this work before? Yes Chrome 59.0.3071.104 Stable on macOS
Does this work in other browsers? Yes
Chrome version: 60.0.3112.32 Channel: beta
OS Version: OS X 10.10.5
Flash Version:
This issue might not be reproduced, but we can reproduce this after several restarting. When you can reproduce this issue, the webview.setUserAgentOverride() doesn't work all times after the restarting last.
,
Jun 21 2017
The condition to reproduce this issue was insufficient in the description above. The points of this issue are the following:
* The 1st webview.setUserAgentOverride() call is successful. That is, the first request has the overriden user agent by the setUserAgentOverride() method.
* When navigating to the next page by clicking a link of <a> tag (that is, since 2nd request sending...), the webview doesn't use the overriden user agent. Instead, the original user agent is sent.
To confirm the behavior above, you can use the following HTML:
[http://127.0.0.1:8080/index.html]
<html>
<head>
</head>
<body>
Hello!<br>
<a id="link" href="/">Reload!</a><br>
<div id="ua"></div>
<script type="text/javascript">
window.addEventListener("load", function() {
var ua = document.getElementById("ua");
ua.innerHTML = navigator.userAgent;
var link = document.getElementById("link");
link.href = "/?" + (new Date()).getTime();
});
</script>
</body>
</html>
When the index.html is opened in the webview, you see the overriden user agent strting ("foobar"). In Chrome Beta and Canary, when clicking the "Reload!" link, the same page is reloaded, and you should see the original user agent string. I think that the correct behavior is that the overriden user agent is always shown at every clicking the "Reload!" link.
,
Jun 21 2017
,
Jun 21 2017
As this issue is secific to web server on the local PC. Hence adding TE-NeedsTriageHelp label for further traiaging. Thanks!!
,
Jun 21 2017
In addition, of course, not only to local web server, but this issue is also reproduced in case of the remote web server. As my test, I used the URL below which is opened in the webview: https://www.eisbahn.jp/test/change_ua.html
,
Jun 21 2017
,
Jun 21 2017
Camille, can you take a look or reassign? This bug only happens when PlzNavigate is enabled. I used the repro steps on comment #2.
,
Jun 21 2017
I used the attached web server to repro. To use: 1. extract somewhere. 2. run 'python serve.py' 3. the user-agent will be printed on the console for every request. 4. ctrl+c to exit
,
Jun 21 2017
lfg@, thank you for quickly setting up web server to reproduce this issue. Good Build: 60.0.3112.24 Bad Build: 60.0.3112.32 Change Log: https://chromium.googlesource.com/chromium/src/+log/60.0.3112.24..60.0.3112.32?pretty=fuller&n=10000 jam@, can you please look into this change (https://chromium.googlesource.com/chromium/src/+/dccd667e6f787a2ef0d123ee9b873732d723d76f) ? Also there was a discussion (https://bugs.chromium.org/p/chromium/issues/detail?id=727517#c36) about disabling 'PlzNavigate' feature in M60, can you please look into this? Thank you!
,
Jun 21 2017
Adding Proj-PlzNavigate-Blocking, so we can discuss whether this is a blocking bug. Also, it seems it might be similar to issue 734772 , where the "Request Desktop Site" bit isn't preserved on navigations. It can be tested with the mostly ready fix at https://chromium-review.googlesource.com/c/541277.
,
Jun 21 2017
This issue exists only in Canary#61.0.3137.0 & Beta#60.0.3112.32 because of 'PlzNavigate' experiment. PS: On Dev the experiment has been disabled and on Stable it never turned on.
,
Jun 22 2017
jam@, can you please look into this?
,
Jun 22 2017
I can confirm that the fix for bug 734772 which Nasko linked to above also fixes this.
,
Jun 23 2017
Ok. I will check the issue 734772 . At least, I hope that the 60 stable version with this issue will be NOT released. Thank you for the confirmation.
,
Jun 29 2017
I have just confirmed that this issue isn't reproduced on Chrome 61.0.3143.0（Official Build）canary (64 bit) for macOS. Thank you, all!
,
Jun 29 2017
Have we merged the fix to beta? This issue is known to break some popular Chrome apps.
,
Jun 30 2017
Yes the fix was merged. See comment 16 in issue 734772 . |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by yoichiro...@gmail.com
, Jun 20 2017