The token verification code path checks the ID token is valid and not expired,
however the ID token and the access token have different expirations, causing
pushes to be rejected by Lando after local verification succeeds. Since
`auth0-python` doesn't provide an access token verification, we decode the
access token and manually verify the token is not about to expire.
Differential Revision: https://phabricator.services.mozilla.com/D190296
Calling ClientWebGLContext::UniformData() many times causes the
command buffer to fill up and we spend a fair amount of time flushing
the old buffer and allocating a new one, as well as serializing the
values.
The uniforms themselves are very small but they add up over a large
number of calls. We already have some code to track whether the
uniform values are dirty to avoid some redundancy, but a) this doesn't
cover every uniform, and b) we invalidate them all when switching
program.
This patch makes us track the value of every uniform that gets set
dynamically, and tracks the values separately for each program
used. It then uses these to avoid calling UniformData redundantly.
Differential Revision: https://phabricator.services.mozilla.com/D190269
Right now we were relying on the OS colors
(-moz-dialog/-moz-dialogtext/ActiveCaption/CaptionText).
The titlebar ones did the right thing but -moz-dialog and co didn't.
This caused two issues:
* With the titlebar checkbox on, we'd use the system colors even
without prefers-contrast. This is specially noticeable on macOS.
* With prefers-contrast. We used -moz-dialog for the background and the
toolbar on macOS. This caused little contrast.
Support the -moz-headerbar colors in all desktop platforms, and use
those on Linux + HCM, and use browser-custom-colors on Windows / macOS
to override the toolbox background explicitly to fix it.
This setup is a little bit more consistent with all other colors.
Differential Revision: https://phabricator.services.mozilla.com/D190200
For initial about:blank, nsSubDocumentFrame::Init might not have an
extant browsing context yet. Some code did deal with that properly
(MaybeUpdateEmbeddedColorScheme for example), but some other didn't.
Consistently propagate data to our browsing context after ShowViewer to
fix this.
Differential Revision: https://phabricator.services.mozilla.com/D190275
Use nsLiteralCstring to store the default instead of an std::string, and
update interface appropriately.
We could go one step further and only use literal string to represent
algorithm instead of storing it in a nsCString at some point, but that
would slightly reduce the flexibility of current interface.
Differential Revision: https://phabricator.services.mozilla.com/D188888
This should be good enough to catch regressions. The main thing is we paint something in the fragments of the iframe on the second and following pages and this should catch it if we fail to.
Fuzz amounts are from an all reftests try run.
Differential Revision: https://phabricator.services.mozilla.com/D190246
After bug 1840478, non-inherited custom properties using their initial
values are represented as absent from `ComputedCustomProperties` in
order to save memory. Wherever the values of such properties are
requested, it is necessary to fallback to any registered initial value.
However, this makes difficult to properly enumerate custom properties
for exposure via the `CSSStyleDeclaration.item()` API and indeed our
current implementation only exposes the properties actually present in
`ComputedCustomProperties`.
Additionally, such a representation conflicts with pre-existent
representation of guaranteed-invalid values as absent values, causing
some issues e.g. bad handling of invalid at computed-value time [1] [2].
This patch changes `ComputedCustomProperties` so that registered initial
values are always stored in the `non_inherited` map, immediately fixing
the issue with `CSSStyleDeclaration.item()` and preparing follow-up
work on guaranteed-invalid values.
To avoid excessive increase of memory usage, the `non_inherited` map
becomes ref-counted. The associated Stylist contains an up-to-date
ComputedCustomProperties with registered custom properties that have
initial values, and the `non_inherited` map can generally just be
shallow-cloned from it.
A new test `get-computed-style-enumeration.html` is added to make sure
custom properties are correctly exposed when enumerating
`CSSStyleDeclaration` as a list. A similar but more restricted version
already exists: `cssstyledeclaration-registered-custom-properties.html`.
Two test cases are also added to `determine-registration.html` in order
to cover some issue previously detected during the review of
`get_custom_property_initial_values`.
[1] https://drafts.csswg.org/css-variables-2/#invalid-at-computed-value-time
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1855946
Differential Revision: https://phabricator.services.mozilla.com/D189999
Use the platform to differentiate x64 and aarch64 builds, not the
symbol. This makes add-on-devel and fuzzing builds match what we're
already doing for shippable and devedition.
Differential Revision: https://phabricator.services.mozilla.com/D190042
In `NewMaybeExternalString` we have a fast path for short Latin1 strings. This case is
very common.
Changing the cache to handle these too is very effective: the `lookupInline` method
has a hit rate of at least 90% on Speedometer 3.
Differential Revision: https://phabricator.services.mozilla.com/D190206
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
Another bug caused by GObject floating references :')
The GVariant returned by builder_end() is floating, and the way
g_variant_builder_add_value works is that it _only_ takes a reference if
floating.
So basically if you have a RefPtr<GVariant> with a floating reference,
then pass it to g_variant_builder_add_value, the reference is "stolen",
but RefPtr doesn't know about it.
It really sucks.
Differential Revision: https://phabricator.services.mozilla.com/D190240
