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
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
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
This will disable the skeleton UI if we crash while setting it up, and further
the error will propagate up and get reported via telemetry on the next run.
This is important because we don't have anything like the crash reporter set up
by the time we want to start showing the skeleton UI.
Differential Revision: https://phabricator.services.mozilla.com/D102355
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
- Content embedded by SubDialog can define its own focus handler which will be called on SubDialog#focus
- Updated CommonDialog to register custom focus handler
- Moved focus calls from SubDialog to SubDialogManager
- Return early after tab dialog focus on tab switch
Differential Revision: https://phabricator.services.mozilla.com/D102298
