Mobile viewport check missing cases that cause tap delay

[brendankenny]

#15394 fixed the issue where an initial-scale of less than 1 was treated as "mobile optimized" (#15266), but there are still double-tap-to-zoom(DTZ)/tap-delay cases it misses.

The FID changelog mentions skipping DTZ "when the viewport meta tag specifies width=device-width or initial-scale>=1.0"". What may have been unclear in the discussion of #15266 is that width and initial-scale have three states: unset, invalidly set, and validly set. The "or" only applies if one is set correctly and the other is unset; if they're both set, they must both be correctly set. Currently width isn't subject to that.

Chrome's mobile viewport check is here, which is a lot clearer than writing it out in prose:

bool is_device_width = viewport.max_width.IsDeviceWidth();
bool is_zoom_at_least_one = viewport.zoom >= 1.0 || viewport.min_zoom >= 1;
widget_base_->LayerTreeHost()->UpdateViewportIsMobileOptimized(
    (is_device_width && is_zoom_at_least_one) ||
    (is_device_width && !viewport.zoom_is_explicit) ||
    (viewport.max_width.IsAuto() && is_zoom_at_least_one));

To change:

• If set, width needs to be checked that it matches the device width. Technically if it's set to a pixel value that matches the current device pixel value it would pass Chrome's check, and technically that could be done dynamically, but maybe Lighthouse should be stricter and require device-width (and maybe some of the relative CSS units) so it's not just accidentally correct in the test environment?
• probably less of an impact, but missing: implicitly-valid zoomed cases won't get a DTZ either (from the FID changelog: "for example in minimum-scale=1.5, maximum-scale=2"; Chrome checks viewport.min_zoom >= 1)

Possible change(s):

• From looking at the Chrome code, it appears that on viewport size changes the mobile-optimized check re-runs, so it's possible if the page allows scales of < 1 and the user zooms out DTZ may become enabled. Should Lighthouse recommend/enforce a minimum-scale of ≥ 1 so users can't create extremely long tap delays for themselves?

[adamraine]

Fixing this condition in Lighthouse makes sense in the short term, but in the long term this audit may make more sense as an inspector issue. Instead of reimplementing the mobile viewport check, we could just use Chrome's mobile viewport check directly.

This would surface the issue in DevTools directly, and maintain good consistency across Chrome, DevTools, and Lighthouse.