More accurate mobile-friendliness detection for Mobile-friendly view |
||||||
Issue descriptionVersion: M55 OS: Android Mobile-friendly view on Clank is disabled for pages that are already mobile-friendly, and the mobile-friendliness detection logic can be improved. The current logic is to look for the viewport setting, and it is considered mobile-friendly if and only if it has width=device-width. However, there are false positives and false negatives. Some sites use hardcoded width, like width=320. On most devices, it still looks mobile-friendly, but mobile-friendly view could be wrongly triggered. Even though it is advised for the web sites to fix their pages with width=device-width, we should count hardcoded width as mobile-friendly as well, as long as the width is under a sensible threshold. One example is http://www.memurlar.net/haber/612821/. In other cases, the sites have correct viewport setting, but the CSS messed up the layout. One example is: http://investorplace.com/2016/10/apple-inc-aapl-stock-buy-dow-jones/. The CSS specifies a large width for the article container, which can be fixed by this: document.getElementById('content').style.width='330px' The sample pages are archived in MHTML format and attached.
,
Oct 21 2016
I'd suggest basing on whether meta viewport tag is present at all.
,
Oct 24 2016
For hard-coded width, I'm thinking what we should do for those wider than device-width. The probability of seeing this should be pretty low, but I haven't got time to quantify it. In mobile-friendly view, if there's a trade-off between precision and recall, we prefer under-triggering than over-triggering. In this sense, using presence of viewport tag makes sense. However, other callers of shouldDisableDesktopWorkarounds() might want width <= device-width instead of presence of viewport tag.
,
Oct 25 2016
Hard-coded width should be fixed in https://codereview.chromium.org/2443753002/, which uses presence of viewport tag as the signal, regardless of the width. Desktop layout with viewport tag is trickier. document.body.scrollWidth looks like a good signal, but we might want to allow some tolerance above device-width, since many pages have slightly broken layout that causes scrollWidth to be marginally larger than the width of viewport.
,
Oct 27 2016
document.body.scrollWidth might not be what we want after all. This page looks mobile-friendly, but its document.body.scrollWidth is >1000. http://www.ab-in-den-urlaub.de/lastminute We should use the width of outer viewport (main FrameView) instead. I thought this is the same as body.scrollWidth.
,
Oct 31 2016
The following site returns a desktop-only version when using Pixel XL, whose User Agent string is: "Mozilla/5.0 (Linux; Android 7.1; Pixel XL Build/NDE63N; xx-xx) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/54.0.2840.34 Mobile Safari/537.36". This can be reproduced on desktop with device emulation. http://www.gadgetsnow.com/tech-news/Apple-CEO-Tim-Cook-wishes-Happy-Diwali-shares-Indian-photographers-photos/articleshow/55139077.cms Interestingly, the viewport setting is: <meta id="viewport" content="width=1000" name="viewport"> Using presence of meta viewport wouldn't work for this site. The mhtml snapshot is attached.
,
Dec 6 2016
Did we fix this bug yet? I'm noticing that I can't trigger Reader Mode in dev (but works on Stable) despite being a non-mobile optimized site. I see it has a viewport tag but width is set to 1020. http://www.telecinco.es/salvame/2016/diciembre/06-12-16/Alba-Carillo-Fonsi-Nieto-manutencion_0_2287425356.html
,
Dec 7 2016
I haven't changed the definition of mobile-friendliness yet (still width=device-width). The problem about telecinco is reproducible on 57.0.2943.3 Canary. I'll look into it.
,
Feb 15 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by klo...@chromium.org
, Oct 21 2016