If a non-null value is stored in this property, its contents (which
must be json serializable) are stored in addonStartup.json and are
then passed to the addon's bootstrap startup() method. This is meant
for data that must be available synchronously during browser startup.
Of course addonStartup.json is read synchronously during startup so
this should be used sparingly.
MozReview-Commit-ID: ALS1CcYbH92
--HG--
extra : rebase_source : 2469fda13f82c3e3837123f75afb5bc6029ed55c
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
The patch adding support for specifying theme icons had a bug in the CSS: it
added styles for the action in a menu-panel depending on theme, but missed out
the theme pseudo-class selectors. Therefore the dark text icon was always used
since it was last in the CSS.
Additionally, the menu panels can't be styled, so still have light backgrounds
and dark text even in light text themes. If a light icon is used in the menu
panel in a light text theme it will be hard to see.
Thus, this patch adds the pseudo-class for dark text themes, but removes the
selector entirely for light text themes.
MozReview-Commit-ID: AmKVDYwGGKj
--HG--
extra : rebase_source : 3e88af5b0ad27b22e5b4456ee980fd60b6498c8a
Currently if there is no default icon at the specified size, the default icon
falls back to the light text icon at that size. This is wrong in two ways:
First, the default theme uses dark text, so it should fallback to the dark icon
Secondly, authors expect the unsized default_icon to be used if specified
This patch fixes both of these issues, so that the default icon first falls back
to the unsized default_icon, and then only if that is not specified falls back
to the dark icon
MozReview-Commit-ID: C3RRTKhYq6r
--HG--
extra : rebase_source : dc10f5c65c763412edbe467bb75aeb4fbcd32ffc
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Before this patch, if a user set their TLS version range preferences to only
allow TLS 1.3, any connections made with the BE_CONSERVATIVE flag or via the
telemetry studies flags would fail because we would attempt to set an
inconsistent TLS version range (the minimum was greater than the maximum). This
fixes that by setting the minimum to the flag-configured maximum. This
intentionally overrides the user's preferences because it is in the context of
browser-critical services (i.e. update servers) or telemetry studies.
MozReview-Commit-ID: 1kKE5nOVQz8
--HG--
extra : rebase_source : 047aa03f401d75aba3f6c5f4c572d2cc451a329e
The PRFileDesc* returned by PR_PopIOLayer must be used rather than a preexisting
pointer to the layer in question.
MozReview-Commit-ID: 8PsCA5npaj6
--HG--
extra : rebase_source : 7488d70ffd428b103ae51d1ebcf15745acd9bf12
When SplitNode returns nullptr, GetAsText causes crash. So we should check
error before casting by GetAsText.
MozReview-Commit-ID: 8E1OPSRZ2x5
--HG--
extra : rebase_source : 48a067bd080e7a68e9d469c07d3b744508dae91f
As explained in the extended comment in this patch, for Servo we want to post
restyles when creating new animations so that we run a second animation
restyle and incorporate the result of new animations into style immediately.
(Gecko does everything in the one restyle, and although this causes other bugs
related to triggering transitions, at least it means it does not require
restyles to be posted here).
It turns out that we normally end up posting a restyle anyway in
CSSAnimation::SetAnimationIndex. Bug 1332958 was supposed to drop that but it
never landed.
However, CSSAnimation::SetAnimationIndex only posts a restyle when there is
a change to the animation index. It turns out that, by chance, there normally
*is* a change to a CSSAnimation's animation index when it is created. Initially
it takes its animation index from Animation::sNextAnimationIndex which is
incremented each time it is assigned to an animation.
If the first Animation we create for a given content process is a CSSAnimation
then sNextAnimationIndex will be zero and so we will initially assign an
animation index of zero. If that CSS animation is also the first in the list
of animations in animation-name, when we call SetAnimationIndex we will pass
zero as the index to use, and when we go to update the animation index we will
detect that there is no change, and will NOT post an animation restyle.
As a result the target element's style will NOT reflect the animated style.
To fix this we need to ensure that *new* CSS animations trigger a restyle.
For *changes* to animations, the corresponding calls to SetKeyframes and
SetSpecifiedTiming post restyles so the behavior should be correct in those
cases.
For *removed* animations I observed that in at least some cases we successfully
post a restyle. However, this appeared to be as much by chance as anything so
this patch also posts a restyle for removed animations. (Note that the
EffectCompositor will ignore redundant restyle requests so this is ok.)
This patch deliberately does not expose Animation::PostUpdate and call that
because the code introduced here is intended to be temporary. Long-term we
should remove the Gecko style backend and allow the calls to PlayFromStyle,
PauseFromStyle, CancelFromStyle etc. to post restyles just like calls to Play,
Pause, and Cancel do. At that point this code can also be removed.
MozReview-Commit-ID: 4c3vJdLBqeY
--HG--
extra : rebase_source : 684cb483562709161b2d5635e173e55319509a70
The != tests actually pass, but this is hard to express in the failures.list
pattern matching, so we just mark them all as random.
MozReview-Commit-ID: 2qr8a1isSEV
--HG--
extra : rebase_source : 14d2756ea044065579e1b3937d8417a3ef004317
I think that trying to slice this up by feature is just going to lead to complications down the line,
so to keep it simple I've moved this to the launch code for all sandboxed children, not just when the
Alternate Desktop is enabled.
This also, similar to chromium, only adds them to the blocklist if they are loaded in the parent.
Andrew Swan
Tom Ritter
Andrea Marchesini
Nicholas Nethercote
Kris Maglione
vincentliu
Boris Zbarsky
Ian Moody
Brian Stack
Sebastian Hengst
Thom Chiovoloni
Mike de Boer
David Keeler
Henrik Skupin
Edouard Oger
Nevin Chen(:nechen)
Makoto Kato
J. Ryan Stinnett
Brian Birtles
Alexis Beingessner
Dale Harvey
Markus Stange
Petr Sumbera
André Reinald
Bob Owen
Jan de Mooij
Benjamin Bouvier
Robert Longson
Lars T Hansen
Phil Ringnalda