gecko-dev/layout/reftests/font-inflation/fixed-width-body-viewport.html

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

27 lines
807 B
HTML
Raw Normal View History

Bug 1428670 - Part 1: Add reftest. r=dbaron The failure mode this test is testing is the following: Apart from the relevant preferences (which cannot change without reloading the page, so they're not relevant in this case), the magnitude of font size inflation for all content governed by a particular font inflation flow root depends on the flow root's effective container width, which is calculated by taking the smaller of the following two values: - The font inflation flow root's calculated NCAIsize. - The ISize of the PresContext's currently visible area. Minimum font size for font inflation then scales linearly with the effective container width. While for a plain document without frames, the visible area normally corresponds to the viewport size, the MobileViewportManager will only calculate the viewport after the "load" event or the first paint, whichever is sooner. This means that the initial reflow will proceed using the current window dimensions (on mobile this is corresponding to the display size) for the currently visible area, which in portrait mode typically means around 300 - 500 px width. After the MVM has done its viewport calculations, we'll reflow again using the new viewport size as our visible area. For non-mobile friendly pages where font inflation is relevant, the standard viewport width is 980 px. If a font inflation flow root is wider than the initial window size, this means that its effective container width is governed by the visible area and will therefore increase during the second reflow, as will correspondingly font inflation's minimum font size. While the font inflation code detects changes in a font inflation flow root's NCAISize, respectively ISize resizes of the top-level (Viewport)Frame, after bug 1308876 it no longer correctly marks all descendants of the affected flow root as dirty. If the text is contained inside an element with a fixed width, which has therefore been unaffected by the viewport width change, this means that we'll skip reflow for that text entirely, so the text gets rendered at the new, increased font size, but continues using the old layout laid out assuming the smaller initial font size. I didn't manage to force the visible area to be larger than the initial window size of 800 px using meta viewport tags, so I'm adjusting browser.viewport. desktopWidth for this test instead. This also more closely mimics the real-life failure case described above, where the viewport width gets set to a value larger than the initial window size through the special desktop page viewport width handling. Differential Revision: https://phabricator.services.mozilla.com/D5579 --HG-- extra : moz-landing-system : lando
2018-10-02 15:23:10 +00:00
<!DOCTYPE HTML>
<!--
Our body is 2000px wide, but the effective container size for font inflation will be clamped to the
viewport width of 1000px (this test uses a custom value for browser.viewport.desktopWidth).
The minimum font size at 20em per line in an 1000px container is 50px. This means we map 0px-75px
into 50px-75px, so 12px gets mapped to 54px.
-->
<html>
<head>
<style>
body {
width: 2000px;
line-height: 1.1;
font-size: 12px;
overflow: hidden;
}
</style>
</head>
<body>
PERSONS attempting to find a motive in this narrative will be prosecuted;
persons attempting to find a moral in it will be banished;
persons attempting to find a plot in it will be shot.<br>
BY ORDER OF THE AUTHOR,<br>
Per G.G., Chief of Ordnance.
</body>
</html>