I changed the toolbar context menuitem from 'Bookmark All Tabs' to 'Bookmark Selected Tabs' because it is separated from a specific tab and thus it is not clear which tab would get bookmarked if only one is selected. This seemed much clearer to me in my testing. The wording of 'Bookmark Selected Tabs' is already used elsewhere where we have 'Reload Selected Tabs', 'Close Selected Tabs', etc.
Differential Revision: https://phabricator.services.mozilla.com/D7217
I changed the toolbar context menuitem from 'Bookmark All Tabs' to 'Bookmark Selected Tabs' because it is separated from a specific tab and thus it is not clear which tab would get bookmarked if only one is selected. This seemed much clearer to me in my testing. The wording of 'Bookmark Selected Tabs' is already used elsewhere where we have 'Reload Selected Tabs', 'Close Selected Tabs', etc.
Differential Revision: https://phabricator.services.mozilla.com/D7217
Return the document element as the activeElement when there is no body
element, the document is chrome privileged, and the document element
is a XUL element.
MozReview-Commit-ID: JFDLAqOmLTS
Differential Revision: https://phabricator.services.mozilla.com/D6448
Other (internal API) changes besides extension API changes:
- This also introduces support for opening a window with multiple tabs
in a non-default container tab.
- This also adds LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL to the
gBrowser.loadTabs call, unless allowInheritPrincipal is set.
For backwards-compatibility, this flag defaults to true.
Depends on D4928
Differential Revision: https://phabricator.services.mozilla.com/D4929
Other (internal API) changes besides extension API changes:
- This also introduces support for opening a window with multiple tabs
in a non-default container tab.
- This also adds LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL to the
gBrowser.loadTabs call, unless allowInheritPrincipal is set. Currently
there are no callers that set this flag, but in case it's desired,
I added an opt-in via window.arguments[10] in browser.xul/js.
For single-argument URLs, the flag is an opt-out, since there are
multiple callers that rely on principal inheritance (bug 1475201).
Depends on D4928
Differential Revision: https://phabricator.services.mozilla.com/D4929
The container tab indicator should also be set on the tab, not just on
the browser. Otherwise it is possible for the indicator to be missing
when a new window is opened.
And previously, if the URL was an "about:blank" URL, the tab in the new
window would use the default container because of the early return in
_handleURIToLoad. This is fixed by accounting for window.arguments[6]
when initializing the default (about:blank) tab in the tabbrowser.
Unit tests for these code path will be added in bug 1393570.
Differential Revision: https://phabricator.services.mozilla.com/D4920
We're ending up in a case here where document.activeElement is null in
browser.xhtml but it's a <browser> tag in browser.xul.
We'll need more analysis and testing to decide if we want the HTML or XUL
activeElement behavior, and then adjust as needed. But in the meantime,
this unbreaks a bunch of browser.xhtml tests and is a safe null check in
both cases.
Differential Revision: https://phabricator.services.mozilla.com/D4705
replaceTabsWithWindow calls replaceTabWithWindow to create a new window window with a first tab.
But unlike the later function, the former cited function don't take an object param (aOptions) containing informations such as the mouse position (which helps set the new window position).
To adress the issue, we added support for passing an option param to replaceTabsWithWindow which just transferts the param to replaceTabWithWindow.
Differential Revision: https://phabricator.services.mozilla.com/D4735
The "select" event handler workaround was originally added in bug 1379270 to make it
possible to focus and select the URL bar a little bit later. This ugly hack was to
workaround an issue with WebExtensions that override about:newtab with the
chrome_url_overrides property (the issue would be that the URL bar would not be
properly focused and selected if about:newtab was overridden).
Back in the day, this was necessary because the overriding URL was fully displayed
in the URL bar (moz-webextension://...). These days, when about:newtab is overridden,
the URL bar is still empty - we just end up showing the information about the
WebExtension overriding about:newtab to the left of the URL bar.
So I think we can remove the old workaround.
Differential Revision: https://phabricator.services.mozilla.com/D3447
Re-introduces support for setting remote icons provided a loading principal is
passed. Removes some now defunkt code from sessionstore.
Differential Revision: https://phabricator.services.mozilla.com/D3123
Re-introduces support for setting remote icons provided a loading principal is
passed. Removes some now defunkt code from sessionstore.
Differential Revision: https://phabricator.services.mozilla.com/D3123