On Android we use SurfaceTextures to render content from sources such
as the video decoder. These may have a transform set which is supposed
to be applied to the texture coordinates used to sample the
texture. Webrender (and software webrender), however, do not handle
this correctly, meaning videos may be rendered at the incorrect size
on some devices.
SurfaceTextures should always be rendered with their bottom-left being
their origin, eg vertically flipped. Additionally, the texture
transform returned on most devices seems to be a simple y-flip
transform with no scaling. Webrender currently just ignores the y-flip
due to the texture origin, which cancels out us not handling the
y-flip from the transform, meaning video looks correct on most
devices. Some devices, however, do return a scaling transform which we
must handle.
This patch removes the override of WebRenderTextureHost::NeedsYFlip()
that was causing us to ignore the y-flip due to the texture origin -
since we will now apply the transform we must handle this correctly
too.
It adds a virtual method RenderTextureHost::GetUvCoords(), that
returns the texture coordinates that should be used by webrender to
sample from external textures. In most cases these are simply (0, 0)
and (size.x, size.y), but in RenderAndroidSurfaceTextureHost we
override this function to apply the transformation. This ensures we
use the correct coordinates whenever the texture is rendered by
webrender, eg in both software and hardware webrender when rendering
in the non-compositing-path, and by hardware webrender's draw
compositor. Additionally, the composite.glsl shader requires a fix to
calculate the UV bounds correctly, as the coordinates may now be
inverted.
Lastly, we fix software webrender with the OpenGL
compositor. CompositorOGL already has the required functionality to
apply the texture transformation as it was used back in the layers
days. We must simply ensure that we pass the value of the
mIgnoreTransform flag from the original SurfaceTextureHost, through to
the RenderAndroidSurfaceTextureHost, and finally to the
SurfaceTextureSource which we hand to CompositorOGL.
Differential Revision: https://phabricator.services.mozilla.com/D144306
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Bug 1762475 added a subtest. First party isolation (partioning) is only enabled
in Nightly. Bug 1549587 is the general bug tracking first party isolation.
Differential Revision: https://phabricator.services.mozilla.com/D144439
This patch also adds assertions for breakpoints on the server to the
breakpoints reload tests. This also asserts that the breakpoint is not removed
on the server when related source no longer exists after a reload
Differential Revision: https://phabricator.services.mozilla.com/D142545
It seems that tab creation may sometimes trigger 'status' updates.
It may depend on whether about:newtab is cached or has to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D144285
Make the representation the same between Gecko and Servo code. This will
enable further clean-ups in the future.
Make serialization be correct, serializing as identifier unless it's an
invalid one (in which case we serialize as a string).
This changes our stringification behavior in the specified style, but
now it will match the computed style and be more correct over-all.
Differential Revision: https://phabricator.services.mozilla.com/D144473
No behavior change, just moving and renaming files.
The code in the "queries" module will be shared between @media and
@container.
@media has some other code that container queries doesn't need like
MediaList / MediaType / etc. That remains in the media_queries module.
Differential Revision: https://phabricator.services.mozilla.com/D144435
