Requesting desktop version of site works bad with WebVew
Reported by
a...@wisebits.com,
May 15 2018
|
||||||
Issue descriptionSteps to reproduce the problem: 1. Set desktop userAgent in WebView 2. Navigate to wikipedia.org or cnn.com What is the expected behavior? Desktop version of site should be loaded What went wrong? Mobile version of site is loaded Did this work before? N/A Does this work in other browsers? N/A Chrome version: 63.0.3239.111 Channel: n/a OS Version: 7.1.1 Flash Version: Note, that a lot of sites works correctly (i.e. desktop version is loaded), but a lot of sites still loads in mobile version. Looks like, the reason is: in this function: WebPreferences RenderViewHostImpl::ComputeWebkitPrefs() { ... if (delegate_ && delegate_->IsOverridingUserAgent()) prefs.viewport_meta_enabled = false; ... I.e. if we override UA, viewport_meta is disabled. But, in the end of ComputeWebkitPrefs there is this call: GetContentClient()->browser()->OverrideWebkitPrefs(this, &prefs); which in case of WebView goes to AwContentBrowserClient::OverrideWebkitPrefs, then to AwSettings and in among other functions AwSettings::PopulateFixedWebPreferences function is called. PopulateFixedWebPreferences(WebPreferences* web_prefs) { web_prefs->shrinks_standalone_images_to_fit = false; web_prefs->should_clear_document_background = false; web_prefs->viewport_meta_enabled = true; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } the last line turn viewport_meta ON always w/out verifying DESKTOP/MOBILE UA
,
May 16 2018
,
May 16 2018
@alex: Thanks for the report!! Could you please share the sample file or .apk or where you're seeing this issue, details of device and if possible attach a screencast as well for further triaging? Thanks!!
,
May 19 2018
This can be reproduced in WebView shell. Modify WebView shell to use a Desktop user agent (see my patch [1]).
---
Request Desktop Site works correctly in Chrome. The difference is window.visualViewport:
* Chrome for Android: VisualViewport {width: 980.0000610351562, height: 1436.6990966796875, ...}
* WebView shell: VisualViewport {width: 412, height: 587, ...}
This is because wikipedia uses the viewport meta tag:
<meta name="viewport" content="initial-scale=1,user-scalable=yes">
I believe this was the aim of aelias@'s CL for Chrome: https://codereview.chromium.org/1785953002/
---
That being said, I don't think WebView has a real "Request Desktop Site" feature. We can't safely assume that a non-default user-agent is a desktop user agent. That leaves us with some options:
1. Don't offer full Request Desktop Site support (wontfix this bug)
2. Add an API to Request Desktop Site (this should be on the condition that the app doesn't try to override user agent)
3. If the app doesn't put "Android" in the user-agent, assume the app wants to "Request Desktop Site"
I think approach 2 is overkill. I'll try uploading a CL for #3.
[1] https://paste.googleplex.com/4683981949763584
,
May 21 2018
There is no request desktop site feature in webview. Webview embedder is allowed to control viewport settings and user agent independently. Upside is flexibility, and downside is embedder can easily do the wrong thing. Definitely don't put random hidden behavior depending on what the user agent is.
,
May 22 2018
I'm trying to implement "Request Desktop Site" in WebView shell (http://crrev/c/1066282) right now. I think this would be a good feature for WebView shell to demonstrate. Bo and I chatted, and we think this should be achievable with WebSettings APIs. I'll update this bug when I make progress with that approach. Also, because I don't believe we've ever explicitly supported this, I'm triaging this as a low-priority feature request.
,
Aug 16
I don't think WebView can support "request desktop site," sorry. This would require three things: 1. Desktop user agent 2. Ignore <meta name="viewport"> 3. Report a desktop-sized width & height when using CSS media queries We sort of support (1) (you must construct the desktop user agent manually), and support (2) with WebSettings#setUseWideViewPort. We don't have good support for (3), making this presently impossible. I don't have bandwidth to work on this. If this is a big issue, let me know. But, given this has been untouched for so long, I don't think we can provide a proper fix. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, May 15 2018