That variable, and the function that references it is only used by the openh264
code, so move it there.
Differential Revision: https://phabricator.services.mozilla.com/D9967
--HG--
extra : moz-landing-system : lando
Taskcluster knows where mozharness generates the logs, and can upload them from
there. Thus, mozharness no longer needs to copy the logs to a new directory.
Differential Revision: https://phabricator.services.mozilla.com/D9966
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Probably not the most reliable test to catch this (as it depends on
the font and such) but still fails here and I'd like WPT to have a test-case
for this. I'm looking into adding a WR test-case ATM, though fighting with
it way too much.
Differential Revision: https://phabricator.services.mozilla.com/D8438
1. Drop {Width|MinWidth|MaxWidh}DependsOnContainer() and
{Height|MinHeight|MaxHeight}DependsOnContainer() because they are bogus
after introducing the writing mode. Dropping these functions needs
update nsLineLayout because it is the only one who still use
these functions.
2. There are still some potential assertions and bugs on handling keywords
in the block size, so we should update them as well.
Depends on D9438
Differential Revision: https://phabricator.services.mozilla.com/D9439
--HG--
extra : moz-landing-system : lando
Keywords on the sizing properties in the block axis should behave as
initial values in the flex frame. We store the keywords as enum, instead
of auto or none in nsStyleCoord, so we have to handle it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9438
--HG--
extra : moz-landing-system : lando
Ensure that a PeerConnection is still open before setting the certificates.
Differential Revision: https://phabricator.services.mozilla.com/D10122
--HG--
extra : moz-landing-system : lando
NsresultExt.to_result() is called by Rust code, so it would be more idiomatic for it to return Result<(), nsresult>, i.e. to return Ok(()) when the nsresult is NS_OK. This change makes it do so.
MozReview-Commit-ID: EaMEKfonHhC
Differential Revision: https://phabricator.services.mozilla.com/D10127
--HG--
extra : moz-landing-system : lando
We erroneously reset client IDs on Fennec to a canary client ID.
This is now detected and a new valid and random client ID is set.
This adds a new boolean attribute "wasCanary" to the `state.json` file
generated by ClientID.jsm.
Depends on D9544
Differential Revision: https://phabricator.services.mozilla.com/D9903
--HG--
extra : moz-landing-system : lando
Some events that actors need to listen to are chrome events which are not received by the listener in the window (even with mozSystemGroup = true).
Differential Revision: https://phabricator.services.mozilla.com/D8014
--HG--
extra : moz-landing-system : lando
This patch adds a messaging mechanism to actors that work like this:
If browser.fission.simulate is true, messages handled by ActorManagerChild will only be dispatched to an actor tied to a specific frame, specified either by its frameId (outerWindowId) or by its browsingContextId. Messages that lack the information about the destination frame will be considered meant for the top-level frame.
In addition, a sendMessage API is added to ActorChild that automatically adds the id information to the outbound message, making it easier for it to be handled in the parent.
The frameId support is to ease the transition of some code that is already using outerWindowIds. For new code, it is preferred to use the browsing context ids, together with bug 1496840
Differential Revision: https://phabricator.services.mozilla.com/D7933
--HG--
extra : moz-landing-system : lando
This fixes the addEventListener in ActorChild that I got wrong on bug 1490810, as it was still directly adding the events to the message manager, instead of going through the dispatcher (which can simulate the Fission process boundaries). ActorChild.addEventListener is meant for actors to add more events after they are constructed (that were not declared in nsBrowserGlue or ActorManagerParent)
Differential Revision: https://phabricator.services.mozilla.com/D7932
--HG--
extra : moz-landing-system : lando
Using a startup timeout of 0s should always cause an IOError,
even for builds which startup within 100ms (pgo, Nightly opt).
Further the test should not modify the internal startup timeout
property, but pass the timeout as parameter to "start_session()".
Differential Revision: https://phabricator.services.mozilla.com/D10224
--HG--
extra : moz-landing-system : lando
