Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
By passing a weak reference back to the DocumentChannelParent into
DocumentLoadListener for object loads, we are able to handle process switching
loads by asking the content process to create a BrowsingContext, and delaying
the real process switch until it becomes available.
The load then completes as it would before, acting as a normal process-switching
subframe load.
Differential Revision: https://phabricator.services.mozilla.com/D86580
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Depends on D80406
Differential Revision: https://phabricator.services.mozilla.com/D80407
Pass internal content policy type to DLL and switch behavior depending on type
being loaded. This implementation immediately redirects channel back to the
content process for further handling.
Differential Revision: https://phabricator.services.mozilla.com/D80407
We can just use BrowsingContext::BrowserId directly, so it's unnecessary to have
the field on nsFrameLoaderOwner as well.
This also makes it so that we only ever generate browser IDs in
BrowsingContext::CreatedDetached.
Differential Revision: https://phabricator.services.mozilla.com/D80121
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
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
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
This patch adds a `openWindowInfo` XPCOM attribute to the `nsIBrowser` interface
supported by the browser custom element. This attribute is then read by
`XULFrameElement`, and passed to `nsFrameLoader` to ensure the relevant flags
are used for newly opened windows.
This patch does not add support for passing openWindowInfo into mozbrowser
elements.
Differential Revision: https://phabricator.services.mozilla.com/D67052
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
