This makes its ownership a bit clearer - it's now encoded in the type system
that nsPageSequenceFrame is the owner of this object, and we can reason about
the implications of that for the other frames that retain a pointer to this
object. (Fortunately all those other frames will be destroyed before the
nsPageSequenceFrame that owns their nsSharedPageData, because they're
descendants of that frame.)
Differential Revision: https://phabricator.services.mozilla.com/D84463
A newer version of Glean is needed to take advantage of the recent "optional version" change.
Pins glean to 31.5.0 to avoid breaking changes, such as to the YAML schema.
Differential Revision: https://phabricator.services.mozilla.com/D84566
It seems win7 sometimes displaces it slightly. We've hit this in the
past and it's not the point of the test so just get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D84597
Before my patches the background images in table-background-print didn't
seem to load on time.
I tried to make the images* tests non-fuzzy, but the <svg:image> really
ruined the deal. A bit of a shame that they fall into a subpixel
boundary because of page margins. So allow a bit of fuzz there rather
than spending another few days trying :)
Differential Revision: https://phabricator.services.mozilla.com/D84516
We need to set the original document ASAP so images triggered from the
clone use the right service worker.
It is a bit unfortunate to have the static document checks twice, but we
may get to Document::GetClientInfo before the cloned doc has a window,
so it's not 100% clear to me how we could avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D82081
Otherwise my test fails intermittently on CI. We need to block on all
the load blockers because stuff like responsive images doesn't fire the
load directly but they do that as a micro task (blocking the load
event).
Differential Revision: https://phabricator.services.mozilla.com/D81989
This, along with the previous patches, allow lazy-loaded images to show
up in print, even if they haven't been loaded otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D81780
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 creates a new set of optimization strategies
(taskgraph.optimize:project.autoland) to use with autoland. Among other things,
it also means there's no need for the 'test-try' optimization as the autoland
strategies are no longer the default behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D79705
Creates a new utility function in 'taskgraph.util.taskcluster' to return task
definitions from a task group. Also refactors the existing
'list_task_group_incomplete_tasks' function to use it.
Differential Revision: https://phabricator.services.mozilla.com/D74407
More leftover stuff from the document splitting effort. I'm leaving in the
corresponding APIs in webrender_api in case other consumers of WebRender
are using it.
Differential Revision: https://phabricator.services.mozilla.com/D84590
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
The Chromium-derived IPC code was, as far as I can tell, originally
designed for Windows and assumed that channels would be named pipes,
managed and connected to via `std::wstring` paths. The port to Unix,
however, used unnamed `socketpair()` and passed them directly from
process to process, so it has no use for these channel IDs... but it
still computes and propagates them, even though they're not used, using
deprecated wide-string APIs.
This patch introduces a typedef for an abstract channel ID, which is a
`wstring` on Windows and an empty struct on Unix, to allow removing the
string code where it's not needed without needing to completely redesign
the channel abstraction.
Differential Revision: https://phabricator.services.mozilla.com/D72260
Chromium's fix for CVE-2011-3079 added an optional prefix parameter for
channel IDs, but we've never used it and have no plans to. (Chromium
itself doesn't appear to have used it except with the prefixes "gpu"
and "nacl", and the code has since been removed completely in favor of
Mojo.) So let's simplify things and remove it.
Differential Revision: https://phabricator.services.mozilla.com/D84276
This "create a pipe" operation has a mode where, on Unix, it doesn't
create a new transport but rather uses a hard-coded fd for the initial
IPC channel in a child process. (It was originally written for Windows
and the assumption of using named pipes and pathnames for everything.)
That seems like a footgun, so this patch checks for trying to "create"
that pipe twice. However, it doesn't check for accidentally calling it
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D72259
The PipeMap class tries to simulate the Windows channel model (named
pipes that the client opens by a pathname) on Unix. However, it's
effectively dead code -- the map is empty except in some unit tests that
we never imported.
What we do is generate a "channel ID" with string formatting, then don't
pass it to the child or ever insert anything into the map, then the child
looks up an empty string and doesn't find it, so it uses the hard-coded
fixed fd for the initial channel.
Basically, it does nothing except maybe confuse unfamiliar readers, so
let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D72258
scattered GPU updates use data transfers most efficiently, since
they need a single slice of a buffer to do all the updates per frame, instead
of uploading each small section of a row independently.
Differential Revision: https://phabricator.services.mozilla.com/D78342
Found during a review of RTCDtlsTransport, mWindow is not needed here
because RTCDTMFSender inherits from DOMEventTargetHelper.
Differential Revision: https://phabricator.services.mozilla.com/D84571
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547
This makes it possible to download the capture from the artifacts of the
CI job. It would be nicer if the capture were written to a tarball/zipfile,
but having to download the files individually is better than nothing.
Depends on D84422
Differential Revision: https://phabricator.services.mozilla.com/D84423
This just makes it easier to instrument a talos test to request a WR capture
for those occasions when one is desired for debugging. This can be done by
modifying the test's html to pull in TalosPowersContent.js and then calling
the TalosPowersContent.wrCapture() method.
Differential Revision: https://phabricator.services.mozilla.com/D84422
Narcis Beleuzu
Andrew Halberstadt
Daniel Holbert
Steve Fink
Mitchell Hentges
Robert Helmer
prathiksha
Emilio Cobos Álvarez
emcminn
Kartikaya Gupta
Rail Aliiev
Nathan Froyd
Jed Davis
Zibi Braniecki
Kagami Sascha Rosylight
Dzmitry Malyshau
Michael Froman
Butkovits Atila
Sylvestre Ledru
Simon Giesecke
Luca Greco
Geoff Brown
Jonathan Almeida [:jonalmeida]
Andi-Bogdan Postelnicu
Alexander Surkov
Neil Deakin
Ricky Stewart
Matthew Noorenberghe
Sebastian Hengst
Eitan Isaacson