This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
WindowFeature provides the tokenization and access to the map.
This changes the following behavior:
* "*" value is removed, given it's unused.
* Default width and default height handling is removed,
given there's no callsites
* Some chrome-priv feature handling becomes stricter:
* All substring match is removed and directly checks the item in the map
Also, fixed noopener=0 and noreferrer=0 options to be handled properly.
Differential Revision: https://phabricator.services.mozilla.com/D67725
This method is no longer necessary, as frontend will always make the correct
decisions for the remoteness of the intial content browser by reading
openWindowInfo.
Differential Revision: https://phabricator.services.mozilla.com/D67058
This patch builds on top of part 7.1 by creating this object within
nsWindowWatcher and ContentParent to carry the relevant information through
provider interfaces when creating new content windows. The nsOpenWindowInfo
object is not created for new chrome windows.
This patch does not propagate these flags all of the way through to the
nsFrameLoader. That change is performed in later parts to keep each part
smaller.
Differential Revision: https://phabricator.services.mozilla.com/D67051
This is necessary as, by this point, the BrowsingContext has already been
attached, and can no longer have its nsILoadContext flags updated.
Differential Revision: https://phabricator.services.mozilla.com/D67049
Many of these setters are redundant, and duplicate work done elsewhere. As it is
no longer correct to set nsILoadContext attributes at these times, they're being
replaced with assertions.
Differential Revision: https://phabricator.services.mozilla.com/D67047
This is OK, as all chrome BrowsingContext instances are always in the same
BrowsingContextGroup, so we don't need to have the initial opener avaliable when
creating the BrowsingContext to determine its BrowsingContextGroup.
This is used in part 7.2 to avoid propagating the opener window around when
creating chrome windows.
Differential Revision: https://phabricator.services.mozilla.com/D67044
This could cause issues, as we could incorrectly override the decision made by
nsWindowWatcher, and then override the decision again after the method returns.
This could cause the initial content browser to be configured incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D67043
