I think this is because this._completeFadeOut is a function but calling it from to handle the event isn't going to have any reference to this so it doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D142821
In case of multiple subdomains without an own cookie permission we need to be able to check the cookie permission
of the domain those subdomains get their permissions from multiple times,
so we can not remove it after the first subdomain.
Differential Revision: https://phabricator.services.mozilla.com/D144573
This patch changes how we handle document loads which are being handled
internally but have Content-Disposition: attachment specified at the
DocumentLoadListener layer. This was done as process switching is
currently the only place during a load where we can change the target
BrowsingContext which the load will complete in.
The only situation where we should currently continue to deliver a
successful request to the default content-viewer despite
Content-Disposition: attachment being specified is when we choose to
handle a downloaded PDF internally, so this shouldn't impact other
cases.
The change is handled by forcing a process switch under the hood, and
opening a new browser window asynchronously to handle the process
switch, similar to how object and embed load upgrades are handled. This
is done using nsIBrowserDOMWindow to attempt to respect the user's
window opening preferences.
A small change to browser.js was also made to try to encourage the new
tab to be opened next to the previous tab, as well as to avoid starting
unnecessary new processes when creating the new browser window.
Differential Revision: https://phabricator.services.mozilla.com/D143675
* Sketch in recently-closed-tabs section and listing
* Add some styles and suggested markup for the page-level sections & headers
Differential Revision: https://phabricator.services.mozilla.com/D143365
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
The tab context menu is designed to not be translated until the user
interacts with the tab strip in some way. However, the tab context menu
is now shared between the tab strip and the "all tabs" panel. So, it's
possible to open the tab context menu without interacting with the tab
strip. This results in the context menu being opened before it is
translated, so the user sees an essentially blank menu. Resolve this
by adding to the all tabs panel an extra initialization step that will
automatically translate the tab context menu.
Differential Revision: https://phabricator.services.mozilla.com/D142850
* Sketch in a page layout and grid to house the tab-pickup region
* Add a tabs-pickup module with custom elements for the deck of cards that is the setup flow
* and a container with placeholder logic to manage the setup flow
* Make myfirefox.js a module, hook up the tabs-pickup element with its controller/manager where we can implement the fxa flow & business logic stuff
Differential Revision: https://phabricator.services.mozilla.com/D142661
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
