In case anchor and area elements have target=_blank and no rel=opener/noopener,
this patch makes so that rel=noopener is implied. This feature is behind pref
'dom_targetBlankNoOpener_enabled'.
See: https://github.com/whatwg/html/issues/4078
In case anchor and area elements have target=_blank and no rel=opener/noopener,
this patch makes so that rel=noopener is implied. This feature is behind pref
'dom_targetBlankNoOpener_enabled'.
See: https://github.com/whatwg/html/issues/4078
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--HG--
extra : moz-landing-system : lando
Consts aren't used in JS anyways, so there's no reason for them to be
in the IDL.
Differential Revision: https://phabricator.services.mozilla.com/D11715
--HG--
extra : moz-landing-system : lando
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
By replacing nsWebBrowser's implementation of the
nsIBaseWindow.initWindow and nsIBaseWindow.create with a new static
nsWebBrowser::Create method we make it possible to pass arguments
directly when creating an nsWebBrowser, for example the opener
BrowsingContext. As a bonus we can do away with
nsWebBrowser::mInitInfo!
Differential Revision: https://phabricator.services.mozilla.com/D12634
--HG--
extra : moz-landing-system : lando
We only need to expose an intercept controller in SharedWorkers if we're on
the non-parent-intercept version of ServiceWorkers or if e10s is off.
nsDocShell already does this dance and we have to mirror it.
Differential Revision: https://phabricator.services.mozilla.com/D12490
--HG--
extra : moz-landing-system : lando
Implemented the manual linting fixes for docshell/test/navigation, docshell/test/unit and docshell/test/unit_ipc
Depends on D9430
Differential Revision: https://phabricator.services.mozilla.com/D10080
--HG--
extra : moz-landing-system : lando
Enabled ESLint for:
* docshell/test/navigation/**
* docshell/test/unit/**
* docshell/test/unit_ipc/**
Changed .eslintignore to allow for this and ran ./mach eslint --fix on the above directories and checked automatic fixes
Differential Revision: https://phabricator.services.mozilla.com/D9430
--HG--
extra : moz-landing-system : lando
Added a mechanism to register and unregister the DocShells from the CorePS depending
on the state of the profiler. Registering mechanism is straightforward. During
unregistration, if profiler is not active, we remove the DocShell information
immediately. If profiler is active, we don't remove and we keep the profiler buffer
position at that moment. During another DocShell registration we Discard the
unregistered DocShells. If the profiler buffer position is greater than the position
when we captured during unregistration, we delete the DocShell since that means there
can't be any markers associated to this DocShell anymore.
MozReview-Commit-ID: IVuKQ6drvkR
Differential Revision: https://phabricator.services.mozilla.com/D4914
--HG--
extra : moz-landing-system : lando
Implemented the manual linting fixes for docshell/test/navigation, docshell/test/unit and docshell/test/unit_ipc
Depends on D9430
Differential Revision: https://phabricator.services.mozilla.com/D10080
--HG--
extra : moz-landing-system : lando
