Re-order calls in SessionStore.jsm to invoke the side-effect-free logic
before triggering observable events.
Clear (likely) stale value of the cached currentURI when lazy browsers
are swapped.
And while I was at it, I also fixed a bug that caused a lazy browser to
eagerly be unlazified because the unneeded mute() call on a lazy browser
unlazifies it (discovered when I added complete test coverage for this
change).
Differential Revision: https://phabricator.services.mozilla.com/D108260
`swapBrowsersAndCloseOther` calls `SessionStore.setTabState`, but the
latter may trigger several tab events before the tab has fully been
restored. This results in duplicate tabs.onUpdated events and in
unexpected access to properties of the tab/browser (which in turn
triggers the reported bug).
Fix this specific case by ignoring events that happen while the tab is
amidst a restoration.
Differential Revision: https://phabricator.services.mozilla.com/D108259
The SpinEventLoopUntilOrShutdown is interrupted in the main process only at stage "xpcom-shutdown", which is too late. In a content process instead we interrupt it early enough, at "content-child-will-shutdown".
This patch removes the current observer logic in nsThreadManager in favor of a current shutdown phase state machinery in AppShutdown and renames SpinEventLoopUntilOrShutdown to SpinEventLoopUntilOrQuit. It also ensures that SpinEventLoopUntilOrQuit breaks early (at "quit-application" in the main process).
For a further possible cleanup around shutdown state in child and parent process please refer to bug 1697745.
We have no automated test for this edge case, but we have diagnostic telemetry that will tell us if it helps.
Differential Revision: https://phabricator.services.mozilla.com/D107619
Unfortunately, it seems that `F7` key handling in `tabbrowser.js` cannot
replaced with using XUL `<key>` element because it works with
`ShortcutUtils.getSystemActionForEvent` for mapping `F7` is a toggle key of
caret browsing mode.
Therefore, this patch exposes some raw information of `WidgetEvent` related
to cross process event propagation and makes `tabbrowser.js` check it and
request reply event if it's required.
So, when a remote content has focus, `tabbrowser.js` will do nothing for both
`keydown` and `keypress` of `F7` key with original events, then, will request
a reply event if its default is not prevented. Finally, reply `F7` keypress
event will toggle caret browsing mode if the event is fired and not consumed.
Differential Revision: https://phabricator.services.mozilla.com/D106591
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
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
This removes observation of the 'disabled' attribute from the macOS
full screen menu items, because removing the attribute doesn't work
correctly. This is a scenario that, as far as I can tell, didn't
happen elsewhere until now. On other OSes we use a single item which
gets disabled state directly from the command attribute (ie without
an 'observes' child) which appears to work fine.
It also exempts the editing commands from being disabled, but it
appears that at least on macOS, undo history is lost anyway. It's
not clear to me why this is the case, but I don't think it needs
to block an initial landing of this work.
Differential Revision: https://phabricator.services.mozilla.com/D103389
This removes observation of the 'disabled' attribute from the macOS
full screen menu items, because removing the attribute doesn't work
correctly. This is a scenario that, as far as I can tell, didn't
happen elsewhere until now. On other OSes we use a single item which
gets disabled state directly from the command attribute (ie without
an 'observes' child) which appears to work fine.
It also exempts the editing commands from being disabled, but it
appears that at least on macOS, undo history is lost anyway. It's
not clear to me why this is the case, but I don't think it needs
to block an initial landing of this work.
Differential Revision: https://phabricator.services.mozilla.com/D103389
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
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
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
- Added a new permission panel managed by the gPermissionPanel object
- Updated identity-box to separate identity and permission section
Differential Revision: https://phabricator.services.mozilla.com/D99892
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
- 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
- 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
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Removing multiple tabs via extensions now calls `gBrowser.removeTabs()`
once for each window that has tabs being removed. Also adds automated
browser tests for removing one tab or multiple tabs.
Differential Revision: https://phabricator.services.mozilla.com/D93438
Removing multiple tabs via extensions now calls `gBrowser.removeTabs()`
once for each window that has tabs being removed. Also adds automated
browser tests for removing one tab or multiple tabs.
Differential Revision: https://phabricator.services.mozilla.com/D93438
