We no longer want to collect email data in crash reports, so we no longer need
to potentially solicit the user for it in the content process crash dialog.
This removes the disabled code for collecting email data.
Differential Revision: https://phabricator.services.mozilla.com/D105496
PDF files can embed some js code in order to validate, format, ... the data entered by a user in a PDF form.
So in order to safely execute this js code, we create a Cu.Sandbox with only what we need/want to expose to the scripts.
Differential Revision: https://phabricator.services.mozilla.com/D91746
With "Close Tabs to the Right" having moved into a submenu in r533105,
it's only logical to offer this functionality as well for having feature parity.
Differential Revision: https://phabricator.services.mozilla.com/D104317
The urls where an OpenSearch engine can be loaded from are already limited in LinkHandlerChild. This is cleaning up and simplifying what the OpenSearchEngine allows, and as a result allows the load path handling to be greatly simplified.
The test changes are due to no longer allowing chrome or file protocols. For future, we probably want to move away from OpenSearch for most of these, but the changes will make it easier to find the places to update.
Differential Revision: https://phabricator.services.mozilla.com/D104010
In bug 1580003 I missed two calls that still use isLastMultiSelectChange.
This parameter has no effect and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D104427
This change adds a new mochitest-only helper called `AppTestDelegate`. This
helper will provide primitives that are not normally available at the toolkit
level.
Each app can implement the `AppUiTestDelegate` API to provide the primitives.
This is done so that we can ensure compatibility of the Extension API across
implementations.
The initial set of APIs is as follows:
```
class TestDelegate {
clickPageAction(window, extensionId);
closePageAction(window, extensionId);
clickBrowserAction(window, extensionId);
closeBrowserAction(window, extensionId);
awaitExtensionPanel(window, extensionId);
// Returns a unique identifier for the tab
openNewForegroundTab(window, url, waitForLoad);
// tabId must be the identifier from openNewForegroundTab
removeTab(tabId);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D99170
Currently the default value of buttons is set to
MOUSE_BUTTONS_NOT_SPECIFIED, which defers calculation of the value to
the DOMWindowUtils GetButtonsFlagForButton function. This calculates a
default value based upon the value of the button key.
By specifying a default button value of 0, which has a meaning of
ePrimary, the buttons value is calculated as the
ePrimaryFlag (1), suggesting that a button was pressed.
This patch changes the behaviour to set the value of buttons based on
the original value of button before the default was applied. The value
of buttons also considers the event type to ensure that a mousedown
event has a default value calculated by DOMWindowUtils.
With the new behaviour:
- if a value was explicitly set for buttons, this is used
- if a value was explicitly set for button, then the not-specified
constant is used to defer calculation to DOMWindowUtils
- if an event type was specified and that event type was not the
'mousedown' event, then the no-button constant is used
- if an event type was not specified or it was for the 'mousedown'
event, then the not-specified constant is used to defer calculation to
DOMWindowUtils
Differential Revision: https://phabricator.services.mozilla.com/D101690
- Moved aboutaddons.html at the root of the about:addons page
- renamed aboutaddons.js `initialize` global function to `initializeView` (and renamed `show` and `hide` global functions accordingly)
- Simplify initial load logic a bit more:
- remove gCategories
- moved responsability of the CategoriesBox initialization to the `initializationView` function
- replaced initialization logic based on `gPendingInitializations` and `notifyInitialized` with
a `promiseInitialized` global resolved when `initializeView` method has been called and its return value resolved
- Fix test helpers and test failures
- InlineOptionsBrowser: take into account that browser-custom-element does opt-in the delayedConnectedCallback behavior
and browser.loadURI may throw if called while the document is still loading.
Differential Revision: https://phabricator.services.mozilla.com/D96472
This revision introduces helpers for determining whether or not dialogs opened with TabDialogBox show the checkbox for allowing focus (tab switching). The approach for showing the checkbox follows the pattern similar to how its handled for TabModalPromptBox:
First, when a prompt is opened, the "DOMWillOpenModalDialog" event is fired from `PromptParent.jsm` on the browser tab. The browser then determines if the tab the event is dispatched on is the current selected tab. If the dialog was opened from another tab, then we check if the content prompt principal permission "focus-tab-by-prompt" is allowed for the URI the dialog was opened for and store its prompt principal on the tab prompt's `_onNextPromptShowAllowFocusCheckboxFor` property. This presence for this value is ultimately what determines whether or not the checkbox is shown. Everything after that, the prompt's UI component is responsible for handling the checkbox's state and setting a handler for setting the permission when it's checked.
Implementing this for TabDialogBox makes it so we also store the prompt principal on the dialog box. We then process this value and send some information (such as explicitly setting a `checkLabel` value) via the `args` object for common dialog to process. And finally, we set the "focus-tab-by-prompt" permission for that URI via a closing callback for the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D102076
This change adds a new mochitest-only helper called `AppTestDelegate`. This
helper will provide primitives that are not normally available at the toolkit
level.
Each app can implement the `AppUiTestDelegate` API to provide the primitives.
This is done so that we can ensure compatibility of the Extension API across
implementations.
The initial set of APIs is as follows:
```
class TestDelegate {
clickPageAction(window, extensionId);
closePageAction(window, extensionId);
clickBrowserAction(window, extensionId);
closeBrowserAction(window, extensionId);
awaitExtensionPanel(window, extensionId);
// Returns a unique identifier for the tab
openNewForegroundTab(window, url, waitForLoad);
// tabId must be the identifier from openNewForegroundTab
removeTab(tabId);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D99170
This revision introduces helpers for determining whether or not dialogs opened with TabDialogBox show the checkbox for allowing focus (tab switching). The approach for showing the checkbox follows the pattern similar to how its handled for TabModalPromptBox:
First, when a prompt is opened, the "DOMWillOpenModalDialog" event is fired from `PromptParent.jsm` on the browser tab. The browser then determines if the tab the event is dispatched on is the current selected tab. If the dialog was opened from another tab, then we check if the content prompt principal permission "focus-tab-by-prompt" is allowed for the URI the dialog was opened for and store its prompt principal on the tab prompt's `_onNextPromptShowAllowFocusCheckboxFor` property. This presence for this value is ultimately what determines whether or not the checkbox is shown. Everything after that, the prompt's UI component is responsible for handling the checkbox's state and setting a handler for setting the permission when it's checked.
Implementing this for TabDialogBox makes it so we also store the prompt principal on the dialog box. We then process this value and send some information (such as explicitly setting a `checkLabel` value) via the `args` object for common dialog to process. And finally, we set the "focus-tab-by-prompt" permission for that URI via a closing callback for the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D102076
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
