зеркало из https://github.com/mozilla/gecko-dev.git
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
8b4d584087
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 |
||
|---|---|---|
| .cargo | ||
| .vscode | ||
| accessible | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| db | ||
| devtools | ||
| docshell | ||
| dom | ||
| editor | ||
| embedding | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| python | ||
| security | ||
| services | ||
| servo | ||
| startupcache | ||
| storage | ||
| taskcluster | ||
| testing | ||
| third_party | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe/appshell | ||
| .arcconfig | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .cron.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .flake8 | ||
| .gdbinit | ||
| .gdbinit_python | ||
| .gitignore | ||
| .hgignore | ||
| .hgtags | ||
| .lldbinit | ||
| .mailmap | ||
| .taskcluster.yml | ||
| .trackerignore | ||
| .yamllint | ||
| .ycm_extra_conf.py | ||
| AUTHORS | ||
| CLOBBER | ||
| Cargo.lock | ||
| Cargo.toml | ||
| GNUmakefile | ||
| LEGAL | ||
| LICENSE | ||
| Makefile.in | ||
| Pipfile | ||
| Pipfile.lock | ||
| README.txt | ||
| aclocal.m4 | ||
| build.gradle | ||
| client.mk | ||
| client.py | ||
| configure.in | ||
| configure.py | ||
| gradle.properties | ||
| gradlew | ||
| mach | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| old-configure.in | ||
| package-lock.json | ||
| package.json | ||
| settings.gradle | ||
| test.mozbuild | ||
README.txt
An explanation of the Mozilla Source Code Directory Structure and links to
project pages with documentation can be found at:
https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure
For information on how to build Mozilla from the source code, see:
https://developer.mozilla.org/en/docs/Build_Documentation
To have your bug fix / feature added to Mozilla, you should create a patch and
submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at:
https://developer.mozilla.org/en/docs/Creating_a_patch
https://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
If you have a question about developing Mozilla, and can't find the solution
on https://developer.mozilla.org, you can try asking your question in a
mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups
are accessible on Google Groups, or news.mozilla.org with a NNTP reader.]
You can download nightly development builds from the Mozilla FTP server.
Keep in mind that nightly builds, which are used by Mozilla developers for
testing, may be buggy. Firefox nightlies, for example, can be found at:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly