nsTArray was previously used without prior declaration. Including the nsTArray.h
header fixes this issue.
MozReview-Commit-ID: 5FmrbjSmZUD
--HG--
extra : rebase_source : d87fd737d3a15067d7106b4fe4ae1f937d799e10
Calls to fallible need to be prefixed by the mozilla namespace because
it's not declared as globally usable.
MozReview-Commit-ID: CJoAoTjXGUH
--HG--
extra : rebase_source : 81618f26b4f2b16b11998673a6cad67d4bca49d4
Fallible is used in this compilation unit so the corresponding header
needs to be included. The <new> header is also required for new placement
calls.
MozReview-Commit-ID: 2eZ8U1wDYs8
--HG--
extra : rebase_source : 53f17d2ef7f8826ac344a2dc2bb278b7b83cbee5
The Stream class is used in this compilation unit so the Stream.h header needs
to be included.
MozReview-Commit-ID: 54X1UKuydUy
--HG--
extra : rebase_source : 96585c678b163fd7506b60ba3c2390d6f8b51d33
EndianUtils.h include was missing and some function calls required
explicit mention to the mozilla namespace.
MozReview-Commit-ID: CFsr7RJ7IGx
--HG--
extra : rebase_source : 01cde66752d6a71938cd1fe9d5f009158ceb7868
The stagefright namespace isn't used in this file and because it
wasn't previously declared in this compilation unit, a compiler error was raised.
MozReview-Commit-ID: HoYyrmIIXSV
--HG--
extra : rebase_source : 57ac59c06cdc4f54676c86a109ae404072541555
I don't know whether or not another zero initial AudioChunk member value
makes initialization more efficient, but zero for silence is more intuitive
for humans.
MozReview-Commit-ID: JEYv65btMul
--HG--
extra : rebase_source : 3089362ce4773da91c7139a3127e1491cbcf1dc5
This avoids any risk of undefined behavior when evaluating uninitialized
members, during copies for example, and makes it safe to test mBufferFormat
when null.
MozReview-Commit-ID: IMAyZ1CSHbk
--HG--
extra : rebase_source : b02431634732cf63d6fe9ede5eb1400a2baa6308
This is an attempt to figure out why https://github.com/servo/servo/issues/17450 occurs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a179cec2b9c02d0d7ca4bc285e97bb8911f047d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f31020a3188c704eb0c89e971cf8d57572d77881
Webextension-formatted langpacks now store their list of chrome
registry resources in startupData so that those resources can be
registered early in startup.
MozReview-Commit-ID: 80eOiPKLlWu
--HG--
extra : rebase_source : b00abc0484e6b41bfb1d17c543a450dc737a6b30
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
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
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.