When an ActorChild is predefined to listen for DOM events and it
does not implement EventTarget.handleEvent(), a standard JS error is
thrown in toolkit/modules/ActorManagerChild.jsm that the handleEvent
property is missing.
If you have more than one ActorChild this error message is cryptic as
it does not refer to _which_ of the children that is missing handleEvent.
This patch introduces a type check for handleEvent that throws an
error (as before) when it is not implemented.
Differential Revision: https://phabricator.services.mozilla.com/D16578
--HG--
extra : moz-landing-system : lando
Add the fingerprinting and cryptomining tables to the SafeBrowsing
update list.
Leave the preference of blacklist/whitelist tables empty until the
shavar server is ready.
Differential Revision: https://phabricator.services.mozilla.com/D16533
--HG--
extra : moz-landing-system : lando
When we add a table to SafeBrowsing.jsm we need to add related code in
various places. This patch simplify the work by providing a FEATURE
table which defines the data required.
Differential Revision: https://phabricator.services.mozilla.com/D16532
--HG--
extra : moz-landing-system : lando
When the updater is disabled toolkit/mozapps/update/common is not traversed as
part of the build. But toolkit/mozapps/update/common/commonupdatedir.cpp is
included in the toolkit/xre build regardless and GetInstallHash is used. This
makes nsXREDirProvider.cpp able to find the header that defines it.
Differential Revision: https://phabricator.services.mozilla.com/D16582
--HG--
extra : moz-landing-system : lando
This is more consistent with other setters, and lets us handle the null frameLoader
case a bit more simply.
Differential Revision: https://phabricator.services.mozilla.com/D16370
--HG--
extra : moz-landing-system : lando
Alternatively, we could check for mInitialized in `AsyncTabSwitcher.logState` before accessing
the getter. But this matches an existing pattern for other browser getters that rely on the
frameLoader existing, and will support other callers that hit this case.
Differential Revision: https://phabricator.services.mozilla.com/D16368
--HG--
extra : moz-landing-system : lando
Currently, when operating with scalars, if a call to internal_GetScalarByEnum (or its keyed variant) return an error, then a warning will be logged. If one of the requested scalars is expired, this could lead to an unwated flood of logs. With this change, the return of the function is checked, and if it is NS_ERROR_NOT_AVAILABLE (i.e. expired scalar), then no warning is issued.
Differential Revision: https://phabricator.services.mozilla.com/D16392
--HG--
extra : moz-landing-system : lando
Because older versions of Firefox auto-select a profile if there is only one in
the database when running dev-edition which uses its own profile we create a
default for normal channels to use. Currently the browser code is responsible
for doing this but it uses a bad heuristic for deciding when to do that. It's
much easier to do it from the profile manager when the dev-edition profile is
created.
Differential Revision: https://phabricator.services.mozilla.com/D16117
--HG--
extra : moz-landing-system : lando
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
1. This requires exposing radiogroup's focusedItem property to C++.
Unfortunately, there's no existing equivalent in nsIDOMXULSelectControlItemElement.
radiogroup is the only element that needs this, so a new interface has been created for it.
2. Accessibility uses focusedItem instead of selectedItem when setting focus.
3. When an item is focused, accessibility needs to be notified.
This is done using a DOMMenuItemActive event.
Differential Revision: https://phabricator.services.mozilla.com/D15295
--HG--
extra : moz-landing-system : lando
Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it.
Differential Revision: https://phabricator.services.mozilla.com/D16261
--HG--
extra : moz-landing-system : lando
This patch removes the StopWatch code that was used in the first version of
about:performance, and not being used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7453
--HG--
extra : moz-landing-system : lando
If the extension had either default_icon or one of it's property as an empty string, it would show a black icon in the toolbar. With this patch, it checks if any of default_icon property is empty and throws an error on extension load.
Differential Revision: https://phabricator.services.mozilla.com/D16070
--HG--
extra : moz-landing-system : lando
If an extension with the "mozillaAddons" permission is updated, the
permission diffing logic should support restricted schemes.
Otherwise the MatchPattern will throw and prevent the update from being
installed.
`Extension.comparePermissions` is called with the result of
`.userPermissions`, which in turn is equivalent to the result of the
`manifestPermissions` getter. This already filters out restricted
schemes if needed. Therefore we can unconditionally use
`restrictSchemes:false` in `comparePermissions`.
And update the regexp in formatPermissionStrings to support permissions
that start with "about:", since the "MatchPatternUnestricted" type in
toolkit/components/extensions/schemas/manifest.json supports this,
and the lack of "//" in about:-URLs prevents the scheme from being
matched by the existing pattern.
Depends on D14963
Differential Revision: https://phabricator.services.mozilla.com/D14964
--HG--
extra : moz-landing-system : lando
Permission warnings only include the host name (ignoring any scheme),
so the comparison of old and new permissions should ignore schemes too.
Any origin permission has to match the definition of "MatchPattern"
as defined in toolkit/components/schemas/manifest.json.
For normal (non-privileged extensions), this is either <all_urls>, or a
pattern consisting of the "http", "https", "ws", "wss", "file", "ftp"
schemes.
Depends on D5527
Depends on D5527
Differential Revision: https://phabricator.services.mozilla.com/D14963
--HG--
extra : moz-landing-system : lando
The "permissions" array of the raw manifest is not (and should not) be
used for permission checking, so it is not necessary to strip the
"mozillaAddons" permission from it.
This commit moves the validation of the "mozillaAddons" permission to
classifyPermission, so that the "manifestPermissions" getter (that uses
this method too) accurately reflects the supported permissions of an
extension.
New tests has been added to verify the permission warnings for some
combinations of permissions. This also includes tests that verify
that only privileged extensions can use "mozillaAddons" to unlock
unrestricted schemes.
Differential Revision: https://phabricator.services.mozilla.com/D5527
--HG--
extra : moz-landing-system : lando
This also moves the corresponding ASFLAGS from moz.build to python
configure.
Differential Revision: https://phabricator.services.mozilla.com/D16320
--HG--
extra : moz-landing-system : lando
With `ac_add_options --enable-project=tools/crashreporter` in a
mozconfig, `./mach build` builds minidump_stackwalk, dump_syms
and fileid.
One caveat is that due to limitation in how the build system works
currently, it's cumbersome to keep dump_syms as a host program for
Gecko, and to make it a target program for this project. For now,
keep it as a host program. We're not going to use it on automation,
but it's still convenient to have for quick local builds (I've had
to resort to awful hacks downstream).
Differential Revision: https://phabricator.services.mozilla.com/D16299
--HG--
extra : moz-landing-system : lando
MOZ_D3D_CPU_SUFFIX and MOZ_HAS_WINSDK_WITH_D3D are not used in the
build, and nothing includes d3d10.h except some angle code in a
preprocessed branch that is only taken for a macro we never define,
so we don't move the code corresponding to those. We also simplify the
detection code, which is convoluted now that it doesn't search for
multiple different DLLs.
Differential Revision: https://phabricator.services.mozilla.com/D16295
--HG--
extra : moz-landing-system : lando
For simplicity's sake, for now we keep storing only one scroll position per
history entry (bug 1499210), so if we have to choose between the layout and the
visual viewport, the latter is a vastly better choice, as it more accurately
represents the scroll position as perceived by the user, especially when the
page has been pinch-zoomed.
This also means that instead of the normal scroll events, the session store now
has to listen for the corresponding events specific to the visual viewport.
We also extend the scroll position test to check that the scroll position isn't
just properly saved, but also actually properly restored in practice as well.
We only add this test now instead of already adding it beforehand like we did
with the rest of the test
- to avoid having to temporarily extend the checkScroll() helper function to
deal with todo()/todo_is etc.
- because getting that part of the test to complete without timing out (which
would be one of its natural failure modes, because the expected events would
be missing) would require faking even more scroll events
- because we already have the todo() tests that are telling us the we didn't
*store* any scroll position in the first place, so there's no point in trying
to actually restore anything
For the GeckoView saveAndRestoreState test, we now spin the event loop once
before setting the scroll position in order to give APZ opportunity to settle
down after the initial page load.
Differential Revision: https://phabricator.services.mozilla.com/D15690
--HG--
extra : moz-landing-system : lando
Our internal Visual Viewport scroll events are dispatched system group-only, so
this is the only way to catch them.
Differential Revision: https://phabricator.services.mozilla.com/D15686
--HG--
extra : moz-landing-system : lando
