Instead, use NS_ReleaseOnMainThread. This requires exactly the same number of
special-cases, but let me know if you instead want a separate
MainThreadSurfaceRef which implements RefPtrTraits and releases on the main
thread or something...
Depends on D90398
Differential Revision: https://phabricator.services.mozilla.com/D90399
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
* 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
The current API name is bad: we want it to be read "some background
thread", but it could just as easily be read "a singular background
thread", which would lead people to assume that for:
```
NS_DispatchToBackgroundThread(...);
NS_DispatchToBackgroundThread(...);
```
the dispatched tasks will necessarily run in the order they are
dispatched, which is not the case.
Let's try to head off that interpretation by renaming this function.
Differential Revision: https://phabricator.services.mozilla.com/D51703
ImageEncoder::ExtractDataInternal takes a `const nsAString&` for its
options, but flattens it into a null-terminated `nsString` so callees
can take a `char16_t*`. But nearly all of those callees eventually wind
up calling ImageEncoder::GetInputStream, which just constructs an
`nsDependentString` from the passed character pointer.
There's no reason to do all this extra work. We can just pass the
original options reference all the way through the stack and avoid
needless conversions.
Differential Revision: https://phabricator.services.mozilla.com/D26353
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
