and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
--HG--
extra : moz-landing-system : lando
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
--HG--
extra : moz-landing-system : lando
1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
1. Add successorId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Depends on D4731
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
There are cases when we asynchronously handle tab events, and therefore try to
attach an ID to a tab after it's already been removed. In practice, this will
typically only affect tests, since it requires the tab to be removed
immediately after a related event is dispatched, but in those cases, it causes
a leak, since there's no way for the tab to be removed after the map after
that point.
We should ideally get rid of those weird async hacks, but either way, we
should ensure that we never add a tab to the map after it's already been
removed. This patch does that.
Differential Revision: https://phabricator.services.mozilla.com/D6435
--HG--
extra : rebase_source : 9b6bea993f6261596f2c6283d6569632d395d68b
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
