ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Added "space-in-parens": ["error"] to eslint for passwordmgr, and fixed the 5 errors found.
Differential Revision: https://phabricator.services.mozilla.com/D17697
--HG--
extra : moz-landing-system : lando
Move prefs from pwmgr_common.js to mochitest.ini and remove redundant calls to set those same prefs.
Differential Revision: https://phabricator.services.mozilla.com/D17589
--HG--
extra : moz-landing-system : lando
Add a scalar 'autoplay_default_blocked' which records a boolean value which indicates whether user is blocking autoplay by default.
Differential Revision: https://phabricator.services.mozilla.com/D17298
--HG--
extra : moz-landing-system : lando
When switching to using a header for the discover pane I forgot
to check for privateness of the window. This patch should apply to both
m-c and beta.
Differential Revision: https://phabricator.services.mozilla.com/D17647
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
extra : moz-landing-system : lando
The aborted-sessions ping is written periodically, even when Telemetry
upload is enabled (and thus the profile has a canary client ID).
On later starts, if this file exists, it is read and send if upload is enabled
(which could have happened in the previous session or by changing prefs.js).
If we now detect that it contains the canary client ID we avoid sending it
and simply remove the file from disk.
Differential Revision: https://phabricator.services.mozilla.com/D17350
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
Instead of relying on an observer for profile-before-change, use the
likely-more-reliable shutdown call from TelemetryController to trigger the
shutdown "event" ping.
Also, add some log lines to make diagnosing timing issues easier in the future.
Differential Revision: https://phabricator.services.mozilla.com/D17412
--HG--
extra : moz-landing-system : lando
This patch fixes the typo in the requiresCleanup getter and adds an additional step
in the automated tests to verify that the scripts created by browser.tabs.removeCSS
are not being added to the content scripts that requires cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D17345
--HG--
extra : moz-landing-system : lando
Add preferences "browser.safebrowsing.features.[feature name].update".
Normally these preferences won't be set so the SafeBrowsing uses features's
enable/disable preferences to decide if it should update the list or
not.
If an update preference is present, then it has higher priority then the
enable/disable one.
This provides a way for the SafeBrowsing consumer to be able to separate
feature toggle and upodate.
Differential Revision: https://phabricator.services.mozilla.com/D17233
--HG--
extra : moz-landing-system : lando
Adds three new scalars for counting the numer of times:
- the default copy action is triggered, regardless of method
- the context menu is shown
- the copy option from the context menu is used
Differential Revision: https://phabricator.services.mozilla.com/D17667
--HG--
extra : moz-landing-system : lando
Recently we use GDK_BACKEND to enable/disable Wayland backend. That's good for testing but bad for distro deployment.
When GDK_BACKEND is set it's propagated to child processes which may not support wayland thus they fail to run. Also when GDK_BACKEND=wayland is set Firefox fails to start when Wayland backend is not available.
To allow easy deployment let's use a specific MOZ_ENABLE_WAYLAND env which means to use a default available GTK backend (x11 or wayland) and don't fail when Wayland is missing.
Differential Revision: https://phabricator.services.mozilla.com/D17607
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
We can't run dump_syms without the DIA SDK binary directory in $PATH
because dump_syms requires the DIA dll from there.
Obviously, the corresponding test can't run if the DIA SDK binary
directory is not known (rather than when the dia2.h header is not found,
since the build system currently relies on WIN_DIA_SDK_BIN_DIR being
given manually).
Differential Revision: https://phabricator.services.mozilla.com/D17892
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
In some setups, MSVC is not found through vc_compiler_path, so we may
need a more complete path. `toolchain_search_path` contains
vc_compiler_path, as well as $PATH (among others), increasing our
chances.
Also, if we fail to find cl.exe that way, fail early, instead of failing
while processing config.status, failing to serialize MIDL_FLAGS because
it contains a `None`.
Depends on D17767
Differential Revision: https://phabricator.services.mozilla.com/D17768
--HG--
extra : moz-landing-system : lando
This turns out to not work at all, because this prevents MIDL itself to
pass -I to the compiler, which then proceeds to fail. We're just lucky
that our MSVC detection doesn't yield any default flags so this is
effectively dead code.
Differential Revision: https://phabricator.services.mozilla.com/D17767
--HG--
extra : moz-landing-system : lando
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
--HG--
extra : moz-landing-system : lando