This adds the base64 encoded color profile to the about:support page in
order to allow us to better diagnose and reproduce color management
issues. We can extract this, decode it and load it directly via the
gfx.color_management.display_profile pref.
The Zydis disassembler is a configurable MIT-licensed decoder and
formatter for x64 and x86.
The code comes from two github repositories:
https://github.com/zyantific/zydishttps://github.com/zyantific/zycore-c
In accompanying licensing material (included in this patch) the
authors are identified as these:
Copyright (c) 2014-2019 Florian Bernd
Copyright (c) 2014-2019 Joel Höner
We will use Zydis to disassemble code generated by the Cranelift JIT.
This source has been taken from the master branch of Zydis on github
and incorporated here in the manner described in README.md in this
directory. Effectively: a subset of files have been incorporated and
the files are in new locations in a flatter tree. README.md has
instructions for repeating the job.
The files in the root Zydis directory js/src/zydis are largely
authored by me but in some cases incorporate code from the Zydis
repository on github and are therefore given a Zydis copyright when
appropriate.
--HG--
extra : rebase_source : 80f8559d2052f81461f3396002956d07eb284f2b
extra : source : d26696cdc629bbfdff98face02caeb9c8c956aca
These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
Beta sees a couple more of these same asserts for some reason.
Explanation of logic for bumping these counts can be found in bug 1530190 where we bumped them already before.
Differential Revision: https://phabricator.services.mozilla.com/D32384
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
This makes our video controls bindings check on loadedmetadata events whether or not to display
the toggle.
Differential Revision: https://phabricator.services.mozilla.com/D32365
--HG--
extra : moz-landing-system : lando
