Re-enabling the PGO jarlog, which was unexpectedly disabled since Firefox 56
showed a regression on Windows 7, due to the use of mozilla::ReadAhead,
which on Windows 7 does explicit I/O on the caller thread.
While there may be some benefit from doing so, evidence says the
opposite, which is presumably due to the amount of data being loaded not
being relevant in every case: the jarlog is gathered from a first-run,
which has a different jar-loading profile from subsequent runs of
Firefox.
While we may want to improve the situation later on, the immediate thing
we can do is stop doing this explicit read, while keeping the OS
readahead hints on other platforms, which don't imply explicit I/O.
All this does is effectively get us back to the same state as if jarlogs
were disabled like it was since Firefox 56, for Windows 7 only.
aFd not being used anymore, the code could be cleaned up a lot, but we
may reintroduce the readahead later, so keep the status quo for now.
Differential Revision: https://phabricator.services.mozilla.com/D23642
--HG--
extra : moz-landing-system : lando
Android P has a lot of Noto Serif and Noto Sans fonts for several languages.
So we should use it to default font list.
Differential Revision: https://phabricator.services.mozilla.com/D23626
--HG--
extra : moz-landing-system : lando
Chrome has had it enabled for years, we had disabled it originally due to crashes seen on Windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D23656
--HG--
extra : moz-landing-system : lando
This commit also fixes a race in `test_error_reporting.html`, where the
push service would initialize and attach its listeners after
`sessionstore-windows-restored`. Even though the test replaces the real
service with a mock, the former keeps listening for pref changes.
When the test calls `setupPrefs` to enable the push connection, the
real service tries to connect to the push server, which asserts in
automation because non-local connections aren't allowed.
We work around this by ensuring that `replacePushService` and
`restorePushService` always wait for the service to shut down before
replacing it with a mock, or restoring the real implementation.
Finally, this commit removes a test that's no longer relevant, since
we don't need to fetch all subscriptions at startup.
Differential Revision: https://phabricator.services.mozilla.com/D20085
--HG--
extra : moz-landing-system : lando
We want to publish a multi-architecture AAR for GeckoView which includes
a single omni.ja, but we archicture-specific changes in greprefs.js that
prevent this from working. This patch causes us to try to read an
architecture-specific greprefs.js first, which will be provided by the
packaging process for the fat AAR.
Differential Revision: https://phabricator.services.mozilla.com/D22526
--HG--
extra : moz-landing-system : lando
Also, remove a test that's no longer relevant, since we don't need to
fetch all subscriptions at startup.
Differential Revision: https://phabricator.services.mozilla.com/D20085
--HG--
extra : moz-landing-system : lando
clang-cl only acts on five MSVC warning flags: 7219c7e9af/clang/include/clang/Driver/CLCompatOptions.td (L188-L197)
With MSVC now unsupported, most -wdNNNN have no effect and can be removed.
This patch converts the five supported warnings to their clang spellings, as preparation for a subsequent patch that will remove all remaining `[/-]w[edo][0-9]{4}`.
Differential Revision: https://phabricator.services.mozilla.com/D22582
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.
The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.
The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.
To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.
Differential Revision: https://phabricator.services.mozilla.com/D21236
--HG--
rename : dom/xul/XULDocument.cpp => dom/prototype/PrototypeDocumentContentSink.cpp
rename : parser/moz.build => dom/prototype/moz.build
rename : parser/moz.build => parser/prototype/moz.build
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Instead of checking the MOZ_JAR_LOG_FILE for each log entry, only check
it once, and only check whether to log once per archive rather than once
per item.
Differential Revision: https://phabricator.services.mozilla.com/D21655
--HG--
extra : moz-landing-system : lando
