Clank reader mode uses this signal for mobile-friendliness detection.

This probably doesn't need to be Restrict-View-Google?

ymalik@ is this something you can comment on?

I am not sure how to differentiate non-mobile friendly sites from sites that are mobile-friendly and want to be zoomed. Maybe a true mobile-friendly site is one that has the viewport tag and disables zoom? I don't have enough background in this area.

bokan@ specializes in this.

This is largely working as intended.  We already have a workaround for this type of mistake where we zoom out if the page width is forced to expand past the specified size during page load, and also the double-tap zoom enabling policy is based on width, so users don't really experience much visible difference from the webauthor having made this mistake.

The main symptom is the likely reason you filed this, "optimize page to mobile-friendly" infobar doesn't show up, so renaming this bug appropriately.  (The return value of shouldDisableDesktopWorkarounds is an implementation detail, not a bug per se.)

If you want to alter your triggering logic to make the infobar appear even on desktop pages that accidentally have a viewport tag, you can consider switching to the same or similar policy that double-tap support uses: see IsMobileOptimizedFrame() in https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/renderer_host/frame_metadata_util.cc .  There is a risk of overtriggering however: it's common to have mobile sites that have one large image expanding the width of the page, so tread carefully.

Although, on second thought, DOM distiller would not even benefit this page since it's not paragraphs of content, so I'm not sure why we should go out of our way to change this, so tentatively WontFixing.  My personal opinion is that this infobar shows up too often and you should be focusing on reducing triggering to only news-style pages, rather than trying to increase triggering further.

Thanks for the feedback, and the pointer of IsMobileOptimizedFrame(). As far as I can remember, over-triggering also exists on shouldDisableDesktopWorkarounds() if a large image expands the width.

The site http://tw.beanfun.com/ was discovered when I did a scan on a scrawled corpus to compare the mobile-friendliness signal with the width of document. This page doesn't contain an article, and we correctly classified this as non-article, so the symptom that I care is not exactly "DOM distiller infobar doesn't appear on tw.beanfun.com".

The bug is more on what heuristics we should use to determine whether a page is considered mobile-friendly. There might be other non-mobile-friendly articles wrongly classified as mobile-friendly, if they specify the viewport this way. The percentage of pages getting this wrong is small, so we could argue that getting around user error isn't worth the effort.

About infobar showing too often, it's tracked in  issue 587974 . Do you feel it's still over-triggering on non-article pages ?

OK, thanks.  My impression that the infobar overtriggers is probably out of date; I'll complain on the bug if I still run into such a case on a current version of Clank.

> As far as I can remember, over-triggering also exists on shouldDisableDesktopWorkarounds() if a large image expands the width.

That's not overtriggering; it's correct triggering.  The logic intended to still identify such pages as mobile means that we overtrigger in the "mistaken viewport tag" case.

> The percentage of pages getting this wrong is small, so we could argue that getting around user error isn't worth the effort.

Yeah, that's my inclination right now, so I WontFixed it.  We can reopen if you find more relevant cases.