This patch includes the workaround mentioned in Bug 1748808 comment 25 as a short term workaround to prevent the test from
failure due to the position where a previous test may have moved the mouse to.
The short term test-only workaround would become unnecessary once we have landed a proper longer term fix
from Bug 1780008, and so:
- if this patch landes before Bug 1780008, as part of Bug 1780008 we should also remove this short term workaround
- if Bug 1780008 got already signed and pushed to autoland before this one, then this patch can be just dropped
and the related bug marked as fixed by Bug 1780008.
Differential Revision: https://phabricator.services.mozilla.com/D152090
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
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
