There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
Canvas only has one context, and that assumption is pretty baked into
the code, so having an API that pretends otherwise is silly.
Differential Revision: https://phabricator.services.mozilla.com/D88990
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This change enables light tracking of the commands and submissions
that affect a CanvasContext. Upon reaching the GPUQueue, they send
a signal for the parent HTML Element to be invalidated.
We are also invalidating the HTML Element and requesting a new
frame to be built on the creation of the swapchain.
Differential Revision: https://phabricator.services.mozilla.com/D71194
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
--HG--
extra : moz-landing-system : lando
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
--HG--
extra : moz-landing-system : lando
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
--HG--
extra : moz-landing-system : lando
Jeff Muizelaar
Tetsuharu Ohzeki
Andrew Osmond
Iulian Moraru
Noemi Erli
Matt Woodrow
Emilio Cobos Álvarez
Gerald Squelart
Simon Giesecke
Sylvestre Ledru
Butkovits Atila
Andreas Pehrson
Kris Taeleman
Markus Stange
Narcis Beleuzu
Hiroyuki Ikezoe
Kris Maglione
Jeff Gilbert
Dorel Luca
Mihai Alexandru Michis
sanketh
Csoregi Natalia
Botond Ballo
Miko Mynttinen
Dzmitry Malyshau
Cosmin Sabou
Bogdan Tara
Andrea Marchesini
Brindusan Cristian