After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
After the previous changes there was only one consumer left of the Shmem
version of GetSurfaceData, which could easily be changed to use BigBuffer,
removing the need for that overload.
After that consumer is removed, the interface was also simplified as the
generic logic in the implementation was no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D151854
The ShmemImage type was previously implemented using a Shmem, however due to
the usage patterns, `BigBuffer` is probably a better fit, and allows unifying
more code in nsContentUtils.
Differential Revision: https://phabricator.services.mozilla.com/D151853
The IPCDataTransfer type is used to transfer Clipboard/Drag & Drop payloads
over IPC to allow them to be written to or read from the relevant system
interfaces. Previously, the system which was used was somewhat complex, and
tried to use Shmem in some cases to store buffers out of line. Now that
BigBuffer is available, it can be simplified substantially.
In addition, this change removed the memory buffer overload of GetSurfaceData,
as the only consumer was using it to immediately send the payload over IPC as a
nsCString. It was changed to instead use `BigBuffer` as that is more efficient
in a large buffer situation, and reduces the number of required copies.
Differential Revision: https://phabricator.services.mozilla.com/D151852
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
- Move ShouldRFP(char*), ShouldRFP(docshell), ShouldRFP(Document)
below some utility code.
- Now that we know we should check the CookieJarSettings, using
ShouldRFP(nsIPrincipal) is dangerous. We mark it as dangerous
and annotate the existing uses of it.
- At the same time, an nsILoadInfo has the CookieJarSettings we
want to check, so create a ShouldRFP(nsILoadInfo) that checks
it and cascades to the (marked-dangerous-but-not-dangerous-for-
this-call) principal function.
- We also correct a situation where WorkerLoadInfo does not
initialize the shouldRFP member.
Differential Revision: https://phabricator.services.mozilla.com/D150591
Now that the ShouldRFP member is correctly populated (we hope)
in CookieJarSettings, we can use it in our ShouldRFP methods.
There are two general scenarios:
An exempted domain frames a non-exempted domain.
The inner frame should be non-exempted.
A non-exempted domain frames an exempted domain
The inner frame should be non-exempted.
In the first scenario, CookieJarSettings.shouldRFP member
will be false (exempted.) We clearly cannot blindly rely
on the member, it would be wrong here.
In the second scenario, CookieJarSettings.shouldRFP member
will be true (non-exempted). This is the scenario we really
need CookieJarSettings for.
----
We take the opportunity to add an additional check for the
'exempted domain framed by a non-exempted domain' scenario.
This additional check takes advantage of the first party
isolation key (for FPI) or partition key (for dFPI).
Differential Revision: https://phabricator.services.mozilla.com/D150589
Testing indicated that for a SubDocument, the loading principal
is that of the parent document, but the final channel uri is
the uri of the subdocument. In this situation, use the final
channel uri just as we do for a Document.
Differential Revision: https://phabricator.services.mozilla.com/D150586
In rare cases, we will need to see if we ShouldRFP using
only a URI and OA. (This is already the case for a
top-level load.)
Abstract this check into its own function, but at the
same time explicitly label it as dangerous and require
the developer to provide a justification why they need
to use it to hopefully prevent misuse.
Differential Revision: https://phabricator.services.mozilla.com/D150585
- Reorder ShouldRFP(char* justification) to put it first
- Add a log line about a null dochsell to be consistent
- Significantly alter the ShouldRFP(nsIPrincipal) check:
Before, it was a coarse function, if you weren't system
principal, it just checked the pref.
Now, it has been combined with the ShouldRFP(nsIPrincipal, OriginAttributes)
function, which was fine-grained. That function didn't
need to exist, because we can _get_ the OriginAttributes
_from_ the principal.
Because before we were retrieving the OA from the loadInfo
(and not the principal) we add an assert to ensure they're
the same.
We eliminate the ShouldRFP(nsIPrincipal, OriginAttributes)
function entirely and convert its one caller into just
passing the principal.
One result of all of this is that the ShouldRFP(nsIPrincipal)
check has been turned into a fine-grained check.
Differential Revision: https://phabricator.services.mozilla.com/D146945
There are two bugs in this function, first the function doesn't do
the `is not connected` check correctly as it supposes to use
`IsInComposed()` but rather `IsInUnComposed()`. Second, it
doesn't get the root of the element correctly.
Also this patch converts the function be static so that it can be
reused.
Differential Revision: https://phabricator.services.mozilla.com/D151081
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
As long as they only wrap one principal, we have a meaningful origin to
use for the CORS request.
This is another alternative for the fix.
Differential Revision: https://phabricator.services.mozilla.com/D148396
This does a somewhat-shallow removal of the argument from the implementation
and all call-sites. Removing it from StructuredCloneData's serialization is
handled in the next part, as it is more widely used and complex.
Differential Revision: https://phabricator.services.mozilla.com/D148531
