Zoom instead of autosizing for desktop sites.

Source/web/PageScaleConstraintsSet.cpp

Index: Source/web/PageScaleConstraintsSet.cpp
diff --git a/Source/web/PageScaleConstraintsSet.cpp b/Source/web/PageScaleConstraintsSet.cpp
index 5d82c4b91d5618f7ead84fd03176d3eb871f1465..8ecc556d4b64fc96e674ce343f7f216e20579bfc 100644
--- a/Source/web/PageScaleConstraintsSet.cpp
+++ b/Source/web/PageScaleConstraintsSet.cpp
@@ -200,4 +200,14 @@ void PageScaleConstraintsSet::adjustForAndroidWebViewQuirks(const ViewportDescri
     m_pageDefinedConstraints.layoutSize.setHeight(adjustedLayoutSizeHeight);
 }
 
+void PageScaleConstraintsSet::applyDeviceScaleAdjustment(const ViewportDescription& viewportDescription, float deviceScaleAdjustment)
+{
+    // If possible, reduce the layout width instead of applying text autosizing.
+    // But don't reduce below the minimum fallback width and don't reduce if explicitly specified by the page author.
+    if (!viewportDescription.isSpecifiedByAuthor()) {

[johnme, 2013/11/11 15:49:38]

Actually, I think we should also reduce the viewport width if the page author
specifies width=device-width (meaning their site renders well at any reasonable
width).

For example, consider a partially sighted user who sets fontScaleFactor to 200%.
When they browse the web on an 8" tablet, they should get the phone UI of every
site, scaled up by 200%.

Such a UI would render perfectly, with no layout issues (unlike any other
possible way of applying a 200% zoom without adding horizontal scrolling - and
of course horizontal scrolling isn't a suitable solution, since with wide
paragraphs it often means you have to scroll back and forth for every line of
text).

As for whether the fudge factor gets applied this way as well, I'm less certain,
as I buy your arguments about it being strange that device-width behaves
differently in Chrome and Chrome-powered WebView for example. Though applying
different amounts of Text Autosizing to the two is probably no better...

[kenneth.r.christiansen, 2013/11/19 16:32:52]

I am not sure that is a good idea.

People who add width=device-width do so because they want one CSS pixel to be
equal to one UX pixel, ie they know that they toolbars will have the same size
of native toolbars etc and this would break that promise.

On the other hand if authors add width=device-width and their text is too small
to be readable, well they it is their fault as they did it on purpose.

+        FloatSize& layoutSize = m_pageDefinedConstraints.layoutSize;
+        layoutSize.setWidth(std::max(viewportDescription.minWidth.value(), layoutSize.width() / deviceScaleAdjustment));

[johnme, 2013/11/11 15:49:38]

I'm a bit concerned that this patch is going to have strange side-effects.

On desktop we use browser zoom (full page zoom), and on mobile we use page scale
(pinch zoom). This patch essentially allows us to use a little bit of browser
zoom in addition to page scale (which is great!).

But it's doing it in quite an indirect manner, which means other parts of Blink
won't know the page is zoomed. For example http://crrev.com/23000005 and
http://crrev.com/23192002 made window.devicePixelRatio and the corresponding
@media queries take into account the amount of browser zoom.

You want the same thing to happen here, for example if you have a
background-image:-webkit-image-set("xs.jpg" 1x, "s.jpg" 1.5x, "m.jpg" 2x,
"l.jpg" 2.5x, "xl.jpg" 3x) on a page with no meta viewport on a landscape Nexus
10 (2560x1600 @ 2x with a fontScaleFactor of 1.3), we'll make the page max(980,
2560 / (2*1.3)) = 984.6px wide. That means, the devicePixelRatio (the ratio
between unzoomed CSS pixels and physical screen pixels) will be 2560/984.6 =
2.6x; hence the browser (assuming no bandwidth constraints) should download
either l.jpg or xl.jpg as those are the closest to 2.6x, and hence will give the
crispest image. Ditto with anything the page does themselves based on
window.devicePixelRatio or the MQs.

It still seems to me that the cleanest way of doing this patch would be to
modify the deviceScaleFactor used throughout the browser. I believe everything
would "just work" then.

Alternatively if it's possible to more explicitly tie this patch into the
browser zoom machinery (such that Frame::pageZoomFactor would be 1.3 in the
example above, and hence Frame::devicePixelRatio would be 2.6 in the example
above), that might make sense.

However I recognise that there are additional constraints here, such as the
(sensible) desire for this zoom not to reduce page width below 980px on desktop
sites, so it does make sense to tie it into viewports (though modifying
deviceScaleFactor should have the same effect). Either way, please make sure
that this zoom is taken into account in Frame::devicePixelRatio, to match our
behavior on desktop.

+    }
+}
+
 } // namespace WebCore