r?njn for the profiler parts
r?jrmuizel for the ELF parsing parts
Depends on D7020
Differential Revision: https://phabricator.services.mozilla.com/D7021
--HG--
extra : moz-landing-system : lando
This will be used to conditionally compile the rust code for ELF binary parsing,
which will be used by the profiler to dump symbols from system libraries on
Android.
Ideally I'd like to make this only apply to Nightly + Beta configurations, and
not to Release, but there doesn't seem to be an easy way to differentiate
between Beta and Release and doing so might be frowned upon. So now it's going
to be built on all channels on Android, even Release, even though developers
won't be profiling Release channel builds much, and the extra code size isn't
all that valuable for our users.
We definitely need this code to be included on the Beta channel, though, because
Firefox Focus Nightly uses GeckoView from the Beta channel, and we want to get
good profiling information from Focus.
Differential Revision: https://phabricator.services.mozilla.com/D7020
--HG--
extra : moz-landing-system : lando
This is faster. It does drop support for skipping non-XUL-namespaced radiogroup
tags, but we don't have or plan to have HTML namespaced radiogroups in the same
document as a XUL-namespaced radiogroup.
Differential Revision: https://phabricator.services.mozilla.com/D7255
--HG--
extra : moz-landing-system : lando
They are unnecessary for most every element, and we load multiple dummy.xul
documents even in clean profiles.
Differential Revision: https://phabricator.services.mozilla.com/D7112
--HG--
extra : moz-landing-system : lando
We need to sign parts of the contents of the archives, so the mar's that we
ship get built as part of the repackage task. Thus, there is no reason to also
create and upload as part of the build, just to throw them away.
Differential Revision: https://phabricator.services.mozilla.com/D6213
--HG--
extra : moz-landing-system : lando
Our current prioritization mechanism doesn't account for tab
warming, or for the fact that the current tab should be
deprioritized. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D7205
--HG--
extra : moz-landing-system : lando
Delaying the loading of some OS.Constants.Path members to reduce startup
IO is breaking the test_system_delay_update.js test, because it leaves
tmpaddon-* files in the user's temp directory. As far as I can tell this
is okay (please correct me if wrong) - but the error in AddonTestUtils
was being avoided because the OS.Constants.Path.tmpDir value was being
read before we override TmpD for the test. So now we are leaving them
to be ignored in the TmpD directory we specified, rather than leaving
them to be ignored in the user's temp directory.
Depends on D6080
Differential Revision: https://phabricator.services.mozilla.com/D6081
--HG--
extra : moz-landing-system : lando
In bug 1388134 we're lazifying some members of OS.Constants.Path
to avoid the extra startup IO. userApplicationDataDir is ripe for
being made lazy, except it's read early in CrashManager.jsm. This
defers that until it's used, and adjusts the affected tests.
Depends on D6079
Differential Revision: https://phabricator.services.mozilla.com/D6080
--HG--
extra : moz-landing-system : lando
These calls to GetPathToSpecialDir are performing some unnecessary IO
during early startup which we'd like to defer. Simply adding the
required ones to the list in osfile_async_front.jsm should mostly get
us there.
Differential Revision: https://phabricator.services.mozilla.com/D6079
--HG--
extra : moz-landing-system : lando
Some oauth services require the redirect uri be configured on their service,
and the reject the redirect_uri param if we send it. Chrome works fine in this scenario,
but we have been requiring the redirect_uri be provided. This addresses that requirement
by using our own default redirect url, which would be the url used to configure the
oauth service.
Differential Revision: https://phabricator.services.mozilla.com/D6945
--HG--
extra : moz-landing-system : lando
All implementations of these methods fail immediately. This patch removes them,
and replaces their call sites with failures. Code coverage indicates these
locations aren't hit by any of our tests.
--HG--
extra : rebase_source : 3c44ac20213af97865ad0316e65bfe49b9e5818c
When bug 1494765 adds support for conversion between nsCOMPtr<>s to
related types, code using nsMaybeWeakPtr fails to compile due to
ambiguous constructors. I'm not sure exactly why this is, but it seems
like we only really need to support two ctors: T* and
nsCOMPtr<nsIWeakReference>, for the cases of a strong and weak
reference, respectively.
The operator= overloads are needed for the branches in
AppendWeakElement.
Differential Revision: https://phabricator.services.mozilla.com/D7222
--HG--
extra : moz-landing-system : lando
The test used to assume that the load event didn't matter and so
the expected values had to be updated to match the new behavior.
A new "slowIFrame" test was added to capture what was previously
tested by the "badIFrame".
Differential Revision: https://phabricator.services.mozilla.com/D7031
--HG--
extra : moz-landing-system : lando
This patch adds a few guards to the DOM elements the videocontrols holds as
properties. Any future changes that attempt to access the blacklisted layout
properties of the DOM elements will throw.
Depends on D6725
Differential Revision: https://phabricator.services.mozilla.com/D6726
--HG--
extra : moz-landing-system : lando
Given that the videocontrols UA Widget initializes when the DOM is inserted
(as opposed to the XBL binding only when the element is visible), the code should
not be tapping into layout until it updates.
Differential Revision: https://phabricator.services.mozilla.com/D6725
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
The new permission is added to make it easier to audit the usage of the
API. It is an optional permission, in case we ever decide to introduce
a permission warning for it.
Differential Revision: https://phabricator.services.mozilla.com/D6771
--HG--
extra : moz-landing-system : lando
Normalize errors thrown by extension API implementations in content
processes to ensure that extension code can read the error message
if the error is an instance of ExtensionUtils.ExtensionError.
This code path is triggered in browser_ext_menus_replace.js and
browser_ext_menus_replace_menu_permissions.js.
Depends on D6625
Differential Revision: https://phabricator.services.mozilla.com/D6626
--HG--
extra : moz-landing-system : lando
Split nsHostRecord into AddrHostRecord and TypeHostRecord for standard address dns queries and queries by-type.
Differential Revision: https://phabricator.services.mozilla.com/D6130
--HG--
extra : moz-landing-system : lando
If the pref browser.fission.simulate is true, the event dispatcher in ActorManagerChild will not dispatch events to actors that aren't associated with the same window as the event's target.
In addition, when that pref is on, the actors associated with sub-frames will have their content property bound to the correct content window, that might differ from the message manager's window (which is always related to the top level).
Then, in order to write Fission-compatible code, that specific actor will need to be declared with allFrames = true, meaning that it wants to be instantiated for every frame, and not just top-level ones
Differential Revision: https://phabricator.services.mozilla.com/D6358
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
My understanding of Web Animation API was wrong in bug 1449532. If a running
animation is pending, playing a new (reversed) animation will cause it to
play from the beginning of the new animation, instead of having the new animation
to play, in reverse, from the current position.
This has caused the user to see a fade out animation that shouldn't take
place when the video loops, i.e. going from "seeking" to "seeked".
The code now probe into the state of the animation instance and cancel
the pending animation, reverse the running animation, or start the new
(reversed) animation accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D6704
--HG--
extra : moz-landing-system : lando
Add env var MOZ_DISABLE_EXCEPTION_HANDLER_SIGILL so that the crash
reporter will not register a handler for SIGILL when the env var is set.
This is needed to work around a conflict with the Oculus Mobile runtime
that uses the SIGILL signal to trap the back button on the controller.
Differential Revision: https://phabricator.services.mozilla.com/D6696
--HG--
extra : moz-landing-system : lando
Changed the validation function for PageInfo to use a more general validateItemProperties.
This changes the error message being thrown. Changed the respective test cases to accomodate the change.
Differential Revision: https://phabricator.services.mozilla.com/D5831
--HG--
extra : moz-landing-system : lando
