The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
This new feature will only work in the "MBT", when devtools.browsertoolbox.fission is true.
It is based on yet another preference, devtools.browsertoolbox.scope,
which is meant to be toggle by DevTools UI only (see next patches).
When the new pref is set to "everything", we will observe FRAME and PROCESS targets
and so debug everything running in content processes.
But when it is set to "parent-process", we will only observe WORKER
and be restricted to parent process resources only.
Differential Revision: https://phabricator.services.mozilla.com/D146891
For add-ons installed before the changes introduced by Bug 1757760 ExtensionSettingStorage.getLevelOfControl resolves to "controlled_by_this_extension"
even if the user did not opt-in when prompted (either by never answer the prompt, or by setting No).
The changes landed by Bug 1757760 did make sure that for a newly installed extensions ExtensionSettingsStorage.getLevelOfControl resolves to "controllable_by_this_extension"
until the user actually explicitly opt-in to the default search engine provided by the installed extension, by making sure to initially set as disabled
the defaultSearch setting for a newly installed extension (which will then be enabled if the user does explicitly opt-in).
Unfortunately, that change doesn't have any effect if the extension has been installed in a Firefox version that did not yet include Bug 1757760 changes,
in that case the setting listed in the pre-existing extension-settings.json file in the Firefox profile will still have the setting marked
as enabled even if the user did never opt-in.
This patch includes a new test task that is injecting into extension-settings.json the data needed to recreate the inconsistent state
(level of control set to "controlled_by_this_extension" while the related search engine isn't actually set as default).
In addition to the new test case, this patch is applying the following changes to `chrome_settings_overrides`:
- in the `setDefault` method: if ExtensionSettingsStorage.getLevelOfControl resolves to "controlled_by_this_extension"
but the default search engine currently set is not the one associated to the extension, then explicitly disable the
setting and recompute the level of control (which will resolve to "controllable_by_this_extension" as a side effect
of explicitly disable the setting)
- in the `ensureSetting` method: remove the check on `item?.enabled`, because the result of ExtensionSettingsStorage.getSetting
does actually never have an `enabled` property set, instead it is part of the content of the extension-settings.json file
and it is used internally by ExtensionSettingsStorage without being returning in the format of the object returned by
calling ExtensionSettingsStorage.getSetting
(see https://searchfox.org/mozilla-central/rev/97c902e8f92b15dc63eb584bfc594ecb041242a4/toolkit/components/extensions/ExtensionSettingsStore.jsm#164-177)
Differential Revision: https://phabricator.services.mozilla.com/D146294
This other call to AddonTestUtils.checkMessage is also using a `forbidden` option wrongly set to the regular expression,
and the manual `messages.filter(...)` is definitely a workaround for preventing an intermittent similar to the one
fixed in the other patch. Better to fix this other call even if not strictly related to this bugzilla issue.
Depends on D146935
Differential Revision: https://phabricator.services.mozilla.com/D146936
This introduces a breaking change: the buckets cannot be changed via preferences anymore.
Before landing this patch, we should have a released a new version of the Remote Settings DevTools that is compatible with this new API.
Differential Revision: https://phabricator.services.mozilla.com/D145455
It seems that tab creation may sometimes trigger 'status' updates.
It may depend on whether about:newtab is cached or has to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D144285
And pass a toolbox instead of only the toplevel target.
It helps identify the browser toolbox and easily enable/disable tools for it.
Differential Revision: https://phabricator.services.mozilla.com/D143628
