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
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
`increaseFontSize`, `decreaseFontSize`, `gethtml`, `heading` and `readonly`
commands were disabled for a year in all channels, but no regression reports
have been filed. Therefore, we can delete the commands and the telemetry
probes.
Note that `cmd_getContents` command which is the internal command of `gethtml`
is not used in comm-central too. Therefore, this patch deletes the command
handler, `nsClipboardGetContentsCommand`, and `Command::GetHTML` too.
Differential Revision: https://phabricator.services.mozilla.com/D153720
This patch changes how BrowsingContextGroups track CrossOriginIsolated
status such that it should be more consistently tracked and easier to
assert in the places which depend on it. In the new state of the world,
a flag is stored within the BCG's ID which tracks whether it was
created for cross-origin isolated documents, and that is also checked
when making decisions about how to isolate initial about:blank
documents, and whether to allow certain changes to
CrossOriginOpenerPolicy.
This flag is stashed within the ID, as it needs to be preserved if the
BCG is destroyed and then re-created from the ID (which may be e.g.
round-tripped through JS code). I also considered making the ID be a
string instead, to make it easier to include extra information like
this, and more clear where the information is stored, however :kmag
generally preferred using a bit within the integer ID.
These new assertions should now be less likely to spuriously fail due to
a DocShell disappearing or similar as well, which should help fix the
original issue.
Differential Revision: https://phabricator.services.mozilla.com/D152695
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
Using nsLayoutUtils::TransformPoint instead of going through the widget takes the iframe's
transformations into account.
Differential Revision: https://phabricator.services.mozilla.com/D151995
CookieJarSettings frequently gets populated in a place
where we have ready access to the Document/Channel it
is being constructed for. This lets us populate the boolean
and pass it into CookieJarSetting's constructor easily.
When it is created for LoadInfo, we need to plumb the URI
through by adding it to LoadInfo::CreateForDocument.
Differential Revision: https://phabricator.services.mozilla.com/D150588
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
This patch splits document specific functionality from FontFaceSetImpl
into a new class FontFaceSetDocumentImpl. This will make it easier to
fork FontFaceSetImpl for workers.
Differential Revision: https://phabricator.services.mozilla.com/D147819
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
This patch splits document specific functionality from FontFaceSetImpl
into a new class FontFaceSetDocumentImpl. This will make it easier to
fork FontFaceSetImpl for workers.
Differential Revision: https://phabricator.services.mozilla.com/D147819
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
