Add importableLogins autocomplete items that show for a site when there's chromium-based logins, no saved logins, and appropriate experiment state. Default behavior is unchanged with default "" pref value, and new behavior can be turned on with "import" pref value.
Differential Revision: https://phabricator.services.mozilla.com/D72096
This adds a multi-e10s variant for geckoview-junit tests. With bug 1622944
resolved, the test suite passes, so we allow this variant to be tier-1.
Differential Revision: https://phabricator.services.mozilla.com/D66676
We need to move these tests to their own class so that we can add a `@Before`
function to set up the expected start conditions.
We also need to allocate the second session in such a way that it is
hosted by the same content process as `mainSession`.
The previous scheme of waiting on each `GeckoResult` independently caused
deadlocks if the results are resolved in a different order, so I replaced those
two waits with a `GeckoView.allOf` result that will Just Work (TM).
Note that this scheme works both in single-e10s and multi-e10s
configurations.
Differential Revision: https://phabricator.services.mozilla.com/D67067
When the full zoom changes, it affects the layout viewport, and thus
RefreshViewportSize(false) gets called via PresShell::ResizeReflow, so
it's not needed.
This is in preparation to firing FullZoomChange only in the browser
element.
Differential Revision: https://phabricator.services.mozilla.com/D72711
Depends on D71035
When F12 is disabled, if the user presses this key we show a notification hanging below the Firefox Hamburger menu.
This anchor was chosen because this is where the users can normally find the Web Developer menu.
Note that they could also open DevTools via another keyboard shortcut, even if it's not mentioned in the message.
Pressing on F12 again hides the message. The message will be displayed again if the user presses F12 again (ie, F12 is a toggle and the message is not just a one shot)
{F2136447}
Differential Revision: https://phabricator.services.mozilla.com/D71036
In this changeset, we add a preference that will simply disable F12 when it is set.
UI and tests are in followup patches
Differential Revision: https://phabricator.services.mozilla.com/D71035
This is in preparation for running the tail dispatcher off
nsIThreadObserver callbacks, which only work during regular
event processing.
Differential Revision: https://phabricator.services.mozilla.com/D72264
This is how it used to be, before the Quantum DOM stuff. We use
nsIThreadInternal because that supports thread observers, which we
leverage in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D71709
Linking Rust code against the updatecommon library is not well supported by our build system, but it should be possible. The changes to updatecommon's moz.build will cause updatecommon.lib to be created, which Rust can link against. The build.rs script tells cargo which shared Windows libraries are needed for linking, and where updatecommon.lib can be found. The change to config/recurse.mk enforces the dependency of the update agent on updatecommon, so that we do not attempt to link the agent before updatecommon has been built.
Differential Revision: https://phabricator.services.mozilla.com/D70207
It's no longer needed with the recent fix to how rectangle prim
and clip rects are stored. It's also a performance win, reducing
the amount of work done when comparing primitive dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D72794
This warning dates from bug 910487, which was 7 years ago. Since joining Mozilla I have *always* gotten this warning, and as far as I can tell since I never had a pre-2019 version of Visual Studio on my dev machine, the VS90COMNTOOLS variable was *never* set. Moreover, the "hack" is written in such a way that it does nothing *unless* you have `VS{100,110,120}COMNTOOLS` set, which I never have on my machine either, as you might expect since I only have the one version of Visual Studio installed.
The [latest public build documentation](https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites) recommends that you install the Community edition of Visual Studio 2019, and as of 2019 the variable that's being used is `VS160COMNTOOLS`, so the only way someone would get value out of this hack is if they're using a substantially older version of Visual Studio than we recommend anyway.
Since 1) I *suspect* the hack is not doing anything for the large majority, if not all, of the people currently running builds on Windows on a day-to-day basis and 2) even if the hack continues to do something useful under some hypothetical scenarios, the content of the hack as well as the corresponding warning is so outdated that it should be updated anyway, I propose deleting it entirely.
Differential Revision: https://phabricator.services.mozilla.com/D72925
- changed test URL to match the dev server
- changed output.py in several places to fix new test names, dict keys, to cover all tests
- added amazonaws.com to manifest.json file to fix the loading issue for benchmark.js file
- added all raptor tests
- changed the constants for measure and alert_on
Differential Revision: https://phabricator.services.mozilla.com/D62546
In particular this will pick up any hit-test flags set on individual items
inside a blob, and ensure the hit-test info emitted to APZ for the blob includes
those flags.
Differential Revision: https://phabricator.services.mozilla.com/D69205
This patch adds support for tests metadata. A test script parser is added as
well as a new "doc" flavor that can be used to display the script info in the
command line. This parser will be the basis for building automated docs and
scripts verifications if we want to do this.
Differential Revision: https://phabricator.services.mozilla.com/D72800
This patch changes the lazy loading mechanism to explicitly create a "lazy" object
that can be used to load modules. It makes it so that TypeScript can understand what
is going on with the lazy loading. I couldn't find a solution to make the Object.define
mechanism work for the global object.
I briefly considered using the Object.define() method on the returned "lazy" object,
as this could be typed correctly, but I felt magically accessing properties was less
clear compared to calling a function that has the side effect of maybe loading a
module for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D59208
This patch takes the approach from mossop on pre-defining ChromeUtils.import
paths, so that they don't need to be defined where they are used. Perhaps in
the future we could automate this more, but for now this will make the current
approach more ergonomic for consumers of the types.
Differential Revision: https://phabricator.services.mozilla.com/D59206
Jean-Yves Avenard
Narcis Beleuzu
Ed Lee
Myeongjun Go
Aaron Klotz
Emilio Cobos Álvarez
Julian Descottes
Matt Woodrow
Bobby Holley
jayati
emcminn
Brindusan Cristian
Kirk Steuber
Glenn Watson
Kershaw Chang
Marco Bonardo
Andrew McCreight
Ricky Stewart
Morgan Reschenberg
Marian Raiciof
Eitan Isaacson
Mats Palmgren
Yura Zenevich
Kartikaya Gupta
Andrea Marchesini
Tarek Ziadé
Dão Gottwald
Greg Tatum
Erik Nordin
Jon Coppeard