Only difference with current versions is the ability to use the crates
with stable rust without setting RUSTC_BOOTSTRAP globally ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D7679
--HG--
extra : moz-landing-system : lando
If we're waiting on an interrupt, then our child items haven't been totally
reflowed and our measures would be bogus.
This will probably regress performance in the cases bug 1209697 fixed, so we
should probably add an interrupt check somewhere in nsFlexContainerFrame to
avoid keeping reflowing flex containers indefinitely.
We could probably just bail out from our reflow if any kid reflow was
interrupted.
Filed bug 1495532 to consider that.
Differential Revision: https://phabricator.services.mozilla.com/D7288
--HG--
extra : moz-landing-system : lando
On about:preferences, if a user enters "doh" or "trr" in the search, it brings them to the Connection Settings panel.
Differential Revision: https://phabricator.services.mozilla.com/D7363
--HG--
extra : moz-landing-system : lando
The crash is happening because we may not have a full node tree when
looking at a particular node; in that case we may not be able to find
the root node. This patch makes us keep track of the root node from the
beginning, so we always know what the root node is.
Differential Revision: https://phabricator.services.mozilla.com/D6758
--HG--
extra : moz-landing-system : lando
Update auto-fill info when selecting tabs. Also for auto-fill focus and
page events, only handle those events for the foreground tab, so
events from background tabs don't inadvertently affect auto-fill for the
foreground tab.
Differential Revision: https://phabricator.services.mozilla.com/D6757
--HG--
extra : moz-landing-system : lando
This brings us into line with Chrome's behavior. Like Chrome, we check the
32-bit view first and check HKEY_CURRENT_USER before HKEY_LOCAL_MACHINE.
This patch only adds code affecting HKEY_LOCAL_MACHINE because the registry
does not use a 32-bit view in the HKEY_CURRENT_USER\Software key.
Differential Revision: https://phabricator.services.mozilla.com/D7779
--HG--
extra : moz-landing-system : lando
The animation in this reftests runs on the compositor. In the mean time,
reftest harness waits for the state where there is no pending paint in the
initial phase (STATE_WAITING_TO_FIRE_INVALIDATE_EVENT, i.e. before sending
a MozReftestInvalidate event). So if the animation starts running on the
compositor before a MozReftestInvalidate event is received, it means that
the reftest harness has to wait for the 'no pending paint' state until the
animation finishes because the reftest harness keeps flushing styles in the
initial phase which means the animation causes a paint on every flush.
To avoid above situation, we start the animation in question after we get a
MozReftestInvalidate event.
Differential Revision: https://phabricator.services.mozilla.com/D7681
--HG--
extra : moz-landing-system : lando
Previously, the <radio> constructor just nulled out the _radioChildren of the <radiogroup>.
This leads to some issues that existed before the Custom Element migration to <radiogroup>,
in which state wouldn't get synchronized between an already-appended radiogroup and a newly
add radio (i.e. the [disabled] attribute on the radiogroup wouldn't copy down to the new radio,
and the [value] attribute wouldn't get moved up onto the radiogroup if the new radio is [selected]).
In addition to that, the Custom Element migration introduced a worse bug, in which the
XBL constructors on radio elements sometime haven't run when the radio is connected. This
means the radiogroup doesn't recognize any children, and the selectedItem / value is wrong.
This patch makes it so that the radio will notify the radiogroup when it is constructed,
and if necessary, the radiogroup can make sure all the state is consistent.
Differential Revision: https://phabricator.services.mozilla.com/D7760
--HG--
extra : moz-landing-system : lando
This is the same as the other patch, except that it is applied to the
case where the QI returns an nsresult.
In addition, I marked the WithError helper class as being stack-only.
Depends on D7553
Differential Revision: https://phabricator.services.mozilla.com/D7554
--HG--
extra : moz-landing-system : lando
This patch adds a static assert to enforce that do_QueryInterface is
not used to go from a class to a base class, because that can be done
more efficiently via a static_cast. This is done by putting the type
of the source into the nsQueryInterface type. Once that is done, it is
easy to check the source and destination type. This has to be done
carefully so that in non-DEBUG builds, where NSCAP_FEATURE_USE_BASE is
defined, we don't generate any additional code.
The first step is to rename nsQueryInterface to
nsQueryInterfaceISupports. In DEBUG builds, I then add a new subtype
nsQueryInterface<T>, where T is the type of the object we are going to
QI. This class is a thin wrapper around nsQueryInterfaceISupports that
only forwards operations to the base class.
The main bit of trickery here is PointedToType<T>, which is needed to
get the type parameter for nsQueryInterface. This dereferences the
type, gets the address of it, then does RemovePointer. This is needed
because a wide variety of pointer types are passed in to
do_QueryInterface, including RefPtr<>, nsCOMPtr<>, raw pointers, and
OwningNonNull<>. PointedToType<RefPtr<T>> is equal to T,
PointedToType<T*> is equal to T, and so on.
In NSCAP_FEATURE_USE_BASE builds (opt), we only use
nsQueryInterfaceISupports, but in debug builds we use
nsQueryInterface<> where possible. The latter is also used for the
nsCOMPtr<nsISupports> overload, because we can always QI to
nsISupports, because that is sometimes used for canonicalization.
Another gross bit is that Assert_NoQueryNeeded can no longer use
nsCOMPtr<>, because it works by QIing T to T, which is banned by the
static analysis. Instead I had to reimplement it by hand.
Depends on D7527
Differential Revision: https://phabricator.services.mozilla.com/D7553
--HG--
extra : moz-landing-system : lando
The symantec distrust should now ride-the-trains in Firefox 64 Beta and Release.
Set security.pki.distrust_ca_policy to 2.
Differential Revision: https://phabricator.services.mozilla.com/D7745
--HG--
extra : moz-landing-system : lando
Depends on D7405. The adb-addon module fires events whenever the
addon state changes, so Devices.jsm should be able to simply reuse this
module to update its internal state, rather than having adb-addon set
something on Devices.jsm directly.
On a sidenote, we really should not propagate the adb status via Devices.jsm
but since WebIDE relies on this, I decided to keep the code as is for now.
We will remove it from Devices.jsm when WebIDE is removed.
Differential Revision: https://phabricator.services.mozilla.com/D7406
--HG--
extra : moz-landing-system : lando
Depends on D7404. The install method should not hardcode "webide"
for the addon manager telemetry info
Differential Revision: https://phabricator.services.mozilla.com/D7405
--HG--
extra : moz-landing-system : lando
Depends on D7403
The getADBAddon/forgetADBAddon is not removing listeners or doing
anything useful since the next call to getADBADdon will just recreate an
instance of ADBAddon. We can expose a singleton and use lazy requires to
achieve the same effect
Differential Revision: https://phabricator.services.mozilla.com/D7404
--HG--
extra : moz-landing-system : lando
Depends on D7402. Moving the module to a shared older. Following
patches will cleanup the implementation to remove WebIDE couplings.
Differential Revision: https://phabricator.services.mozilla.com/D7403
--HG--
rename : devtools/client/webide/modules/addons.js => devtools/shared/adb/adb-addon.js
extra : moz-landing-system : lando
There is only one addon to manage in WebIDe, removing the concept
of available addons will make it easier to move the ADBAddon module to a
shared folder.
Differential Revision: https://phabricator.services.mozilla.com/D7402
--HG--
extra : moz-landing-system : lando
Per example in the spec https://drafts.csswg.org/css-multicol-1/#column-span
... the bottom margin of the second spanner does not collapse with the top
margin of the subsequent element.
Likewise, in the test file multicol-span-all-margin-bottom-001.xht, the
bottom margin of the black spanner <h4> should not collapse with the top
margin of the orange non-spanner <h4>.
Differential Revision: https://phabricator.services.mozilla.com/D7670
--HG--
extra : moz-landing-system : lando
Several tests of RDM use the helper function waitForViewportResizeTo. This patch changes that function to check the viewport size, not the content size, and to wait on either the content-resized event or the newly-defined viewport-resized event, which is fired on resize when viewport override is active.
Differential Revision: https://phabricator.services.mozilla.com/D7202
--HG--
extra : moz-landing-system : lando
If the process quits externally (shutdown by itself or via kill),
the poll method still returns None, even with the process not
existent anymore.
To fix that, the poll method should at least try to join the reader
thread once before checking if it is still alive. Otherwise it will
continue to run, and never stop.
Also the attribute existence check for "returncode" on the process
instance has to be removed because this property always exists.
Instead a check for the "returncode" property of the ProcessHandler
class is necessary.
Depends on D7396
Differential Revision: https://phabricator.services.mozilla.com/D7398
--HG--
extra : moz-landing-system : lando
The assumption that when a handle is present for the process handler
on Windows doesn't mean that the process is still alive. It could
have already been externally killed, crashed, or closed itself.
The patch makes sure to check the process exit code, and run
clean-up steps if the process is already gone.
Depends on D7395
Differential Revision: https://phabricator.services.mozilla.com/D7396
--HG--
extra : moz-landing-system : lando
Calling "check_for_detached()" doesn't make sense if the process
hasn't been started yet, and as such has to raise a RuntimeError.
Depends on D7393
Differential Revision: https://phabricator.services.mozilla.com/D7394
--HG--
extra : moz-landing-system : lando
Instead of an AttributeError a RuntimeError has to be thrown if
the underlying process hasn't been created yet.
Depends on D7392
Differential Revision: https://phabricator.services.mozilla.com/D7393
--HG--
extra : moz-landing-system : lando
Marionette currently doesn't handle restarts of Firefox that well,
and as such needs a fix on bug 1433873. Sadly this patch cannot be
landed until the mozprocess issues on bug 1433905 have been fixed.
This patch temporarily disables the test for opt/pgo Windows builds
only. Re-enabling is tracked via bug 1495667.
Differential Revision: https://phabricator.services.mozilla.com/D7392
--HG--
extra : moz-landing-system : lando
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
