User agent not set as expected when create window from WebChromeClient.onCreateWindow
Reported by
anthonyo...@gmail.com,
May 26 2016
|
|||||||
Issue descriptionSteps to reproduce the problem: 1. set supportMultipeWindows to true. 2. when window created from WebChromeClient.onCreateWindow (like when opening a link at news.google.com) set user agent of new WebView. 3. expected user agent not set when new webview loads from WebViewTransport What is the expected behavior? New WebView should keep the user agent that was set. What went wrong? New WebView apparently sets user agent to null when it receives the WebViewTransport message. Did this work before? Yes before Android KitKat Chrome version: 51.0.2704.61 Channel: n/a OS Version: 6.0.1 Flash Version: n/a See: https://code.google.com/p/android/issues/detail?id=64275
,
Jun 3 2016
Good point. Probably nothing from WebSettings makes to the pop up..
,
Jun 6 2016
I guess we should check what the old behaviour was - did it maybe propagate all the websettings?
,
Jun 8 2016
I would not expect the settings to propagate, actually. What I am saying is that if you set the user agent before loading via WebViewTransport, that user agent is set to null by WebViewTransport. I do not think WebViewTransport should be changing WebSettings on its own.
,
Jun 8 2016
> that user agent is set to null by WebViewTransport That's not what's happening. It's simply that all changes to WebSetting is ignored in this case, and the default user agent value is null, which means use the default user agent in webview
,
Jun 9 2016
> I guess we should check what the old behaviour was - did it maybe propagate all the websettings? Yes. I'll just paste function names since there is no public code search for old android code (afaik) CallbackProxy.createWindow -> WebViewCore.initializeSubwindow -> WebViewCore.initialize -> WebSettingsClassic.syncSettingsAndCreateHandler Also to my surprise, and if I'm reading the code correctly, app had to respond to the callback synchronously.
,
Jun 9 2016
And looking at chromium code, I don't know what's wrong anymore. We do update settings at the correct place: receivePopupContents -> setNewAwContents -> AwSettings.setWebContents -> updateEverythingLocked. Hmm...
,
Jun 9 2016
anthonyorciuoli: Is the issue that the first navigation made by the pop up having the wrong user agent. What about follow up navigations?
,
Jun 9 2016
,
Jun 9 2016
@ #8: Follow up navigations retain the null UA. I also tried this: 1) set desktop UA 2) click link at news.google.com [US|Biden Calls Victim in Stanford Rape Case a 'Warrior'] ( http://www.nytimes.com/2016/06/10/us/biden-calls-victim-in-stanford-rape-case-a-warrior.html ) 3) in new window, set desktop UA then do WebViewTransport to open page but it opens in mobile as specified above ( http://mobile.nytimes.com/2016/06/10/us/biden-calls-victim-in-stanford-rape-case-a-warrior.html ) 4) after new window is open, maually set UA to desktop 5) click link in new window [the judge’s sentencing] ( https://www.nytimes.com/2016/06/08/us/judge-in-stanford-rape-case-is-being-threatened-who-is-aaron-persky.html ) 6) it still goes to the mobile site ( http://mobile.nytimes.com/2016/06/08/us/judge-in-stanford-rape-case-is-being-threatened-who-is-aaron-persky.html ) @ #5: OK, I did not look at chromium source. I meant that I set the UA and the outcome is the same as if the UA is subsequently set to null. Sorry for confusion.
,
Jun 9 2016
What if the follow up navigation is through loadUrl rather than clicking a link? Does toggling other settings in WebSettings work for the pop up? Maybe try setBuiltInZoomControls(true), that should enable zooming, so effect should be obvious. Thanks for doing this work btw.
,
Jun 11 2016
Clicking a link is the problem. When using loadURL, the UA setting is obeyed. setBuiltInZoomControls(true) works for the popup.
,
Jul 8 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 30 2017
Any updates on this? Is there any additional information or similar you need then perhaps I can provide it.
,
Sep 15 2017
,
Sep 25 2017
Hmm... I tested setUserAgent() and setBuiltInZoomControls(), and it seems that we do not inherit any of the settings from parent WebSettings. In ICS, we were copying most of the settings one by one. http://androidxref.com/4.0.4/xref/external/webkit/Source/WebKit/android/jni/WebSettings.cpp We can do something similar in AwContents#receivePopupContents(), and call AwSettings#get... and AwSettings#set... at the time popup window is created. but now I'm afraid that we may inadvertently break other apps. boliu@, would it be ok to copy most of what the user set in WebSettings?
,
Sep 25 2017
> Hmm... I tested setUserAgent() and setBuiltInZoomControls(), and it seems that we do not inherit any of the settings from parent WebSettings. parent as in the webview that created the pop up window? but app supplies the webview for the new window, so WebSettings is entirely in app's control. Seems odd that if we just then blow away any settings that was set by app before it's used as the pop up how did webview classic behave?
,
Sep 25 2017
talked in-person. there was no copying between parent and popup webview. the issue once again is probably because webview classic implemented this synchronously (ie blocks the webkit thread), so app has opportunity to affect the first navigation of the pop up, whereas in chromium, first navigation in pop already happened even before app got notified with onCreateWindow proper fix will be the need to replicate webview classic behavior, somehow..
,
Mar 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c1134a866cccc8b77837bb9d05d75f7ee824ffb1 commit c1134a866cccc8b77837bb9d05d75f7ee824ffb1 Author: Changwan Ryu <changwan@google.com> Date: Wed Mar 07 02:10:14 2018 Allow user agent to be overridden in popup webview creation When a webview-embedding app creates another webview inside WebChromeClient#onCreateWindow(), the navigator does not have a current entry nor pending entry yet, but decides not to override user agent nevertheless, in creating navigation request. Therefore, the intent to override the user agent is ignored in creating navigation request. This can be fixed by looking up the delegate as a fall-back. BUG= 614951 Change-Id: I00fe0a26e67116517f59452e89297018a09ffa8e Reviewed-on: https://chromium-review.googlesource.com/846713 Commit-Queue: Changwan Ryu <changwan@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Reviewed-by: Bo <boliu@chromium.org> Reviewed-by: Ted Choc <tedchoc@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Cr-Commit-Position: refs/heads/master@{#541287} [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/android_webview/browser/aw_settings.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/android_webview/javatests/src/org/chromium/android_webview/test/AwActivityTestRule.java [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/android_webview/javatests/src/org/chromium/android_webview/test/PopupWindowTest.java [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/chrome/browser/prerender/prerender_contents.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/chrome/browser/sessions/persistent_tab_restore_service_unittest.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/chrome/browser/sessions/session_restore_browsertest.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/chrome/browser/ui/browser_commands.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/chrome/browser/ui/browser_tabrestore.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/android/content_view_core.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/frame_host/interstitial_page_impl.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/frame_host/interstitial_page_impl.h [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/frame_host/navigator_delegate.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/frame_host/navigator_delegate.h [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/frame_host/navigator_impl.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/web_contents/web_contents_impl.h [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/browser/web_contents/web_contents_impl_browsertest.cc [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/content/public/browser/web_contents.h [modify] https://crrev.com/c1134a866cccc8b77837bb9d05d75f7ee824ffb1/extensions/browser/guest_view/web_view/web_view_guest.cc
,
Mar 7 2018
,
Mar 26 2018
Uploading a sample app I was working with for test verification. You'll notice the useragent change before and after 67.
,
Mar 26 2018
verified on pixel 2 xl vs 67.0.3379.0 |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by rsgav...@chromium.org
, Jun 3 2016