This pref controls whether or not the platform looks for and trusts enterprise
roots (currently only available on Windows). Adding it to security-prefs.js will
make it appear in about:config, which is a much more straightforward user
experience (previously users would have to add it manually). It is still
disabled by default.
MozReview-Commit-ID: 6pQkh2gTNTF
--HG--
extra : rebase_source : 5479492f3a9f802d1fc02c6d3fdc3d54c81f8fe9
instead of using the context belonging to a widget.
Only the style context is cached, instead of the whole widget.
Using the style context from a widget meant that rendering displayed the
initial appearance of animations after state changes, but there was no
invalidation to trigger the final rendering in the animations.
Style contexts constructed from paths do not incorporate animations.
(See gtk_css_path_node_update_style() in GTK.) Therefore they provide the
appropriate rendering for Gecko's model, which is not expecting animations.
There is no mechanism available to display animations when using style
contexts constructed from paths, but the GtkWidget animation design is also
not suitable for rendering potentially multiple elements each in a different
state of their animation.
This contexts-from-paths approach can be extended also to other widget types,
but this is a smaller change intended for uplift to other branches to address
a regression in menuitem rendering.
MozReview-Commit-ID: EFV7swWQtm4
--HG--
extra : rebase_source : 689f7340007c889ce0eaeb3b4acd228d45ad0d6d
CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
--HG--
extra : rebase_source : ad161eef11e0dc70c8a487c204f109eceac3b1c4
This is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: 6Rwinr4AY8l
--HG--
extra : rebase_source : 930a501b3ecd5f124631e3f96fd6ca7611d078ff
The GtkContainer border-width property defaults to zero. It is not influenced
by theme CSS. While theme engines can theoretically modify default values for
properties of any class, I don't think that is something that needs to be
supported.
Removing this code is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: IxgM8qjfK3a
--HG--
extra : rebase_source : c5c94c19227d7e7d31c4a094bb4fb68f094ddb50
Following bug 1311116 which reduces the Marionette log verbosity for local
builds, this increases it on on all try jobs through passing the `-vv`
(very verbose, equating to `Log.Level.Trace`) flag to the Marionette
test harness.
MozReview-Commit-ID: ELGgJph6QZo
--HG--
extra : rebase_source : 1e3d957ef6c6f058f06f21b32bfb3bd3f1d8a38d
Job tasks are tasks that are not tied to a specific build or test. As such, they cannot be scheduled
with the regular -p/-u try syntax options. There exists a -j try syntax option, to schedule them, which
defaults to running "all" of them if not specified.
However, there is a bug here where they will only default to "all" if a try syntax exists in the commit
message. They will not be considered if a developer pushes to try without a try syntax. This happens
because self.jobs is initially initialized with '[]' and we use None to determine when to schedule "all"
later on.
I want to move towards a world without try syntax, so we should start improving the UX of the no try
syntax use case.
Note: When I say "schedule" here, I mean added to the target set. They may still be optimized away.
MozReview-Commit-ID: 4TrC84RGiaL
--HG--
extra : rebase_source : 8fd50113c37745bc10181e1311cc62d75485723a
This patch updates the available speed for user from 8 different speeds to 40.
MozReview-Commit-ID: DZXIhqQERIv
--HG--
extra : rebase_source : d2546c672e8bbd5cb9f38328c23e5b5311fa6d85
The mochitest harness on Windows sets MOZ_GMP_PATH to paths with a mixture of
Windows and UNIX dir separators, and the NS_NewLocalFile() call in
GMPServiceParent::AddOnGMPThread() fails on this input.
We've had this problem before, and if we fixed the test harness to give us
input with platform specific line endings somebody would likely just break this
again someday and have this issue again, so just make the GMP service normalize
the paths it's given to have consistent dir separators.
This makes test_peerConnection_basicH264Video.html pass when run
locally on my Windows machine.
MozReview-Commit-ID: 88hSvTdZuWg
--HG--
extra : rebase_source : 2cf63ccd1155e59f9745163cf4a28d3bdb7012ba
The other fields, spec, array, and nullable, are set in some places.
Also remove a dead chunk of code with a FIXME that refers to a bug
that was WONTFIXed in 2010.
--HG--
extra : rebase_source : 184d001a1233e9c035af070bc920c8cbeabc27cc
MessageId has the production "'~' ID", but if you use it, it produces
an error. This error was added in 2009, in bug 525342. I doubt anybody
expects it to work any more, so it should just be a regular parse
error. This is the only usage of the literal ~ so it can now be
removed from there.
MozReview-Commit-ID: AivlLE8Nubv
--HG--
extra : rebase_source : 66f76d1528f0bcf624af97b9437834874e537eb8
GCC and Clang will colorize compiler output automatically if stdout is a
TTY. Unfortunately, when the build backend is invoked via `mach`,
stdout is not a TTY.
6e9a4c0b9cd8 (bug 1315785) changed mach so it exports an environment
variable indicating whether mach's original stdout is a TTY. This was
later used to add color flags to `cargo` invocations.
Building on that work, this patch adds color flags to compiler
invocations if the compiler supports color and a mach TTY is
detected. The result is that compiler output from `mach build`
will be colorized automatically if Clang or a modern version of
GCC is used.
The only issue I see with this is that Clang doesn't "unset" its color
sequences when printing a newline. As a result, mach's time line
prefixing can sometimes inherit "bold" or other stylings. AFAICT this is
only a minor cosmetic concern. GCC does not exhibit this issue.
MozReview-Commit-ID: 5Icu6aXGZBL
--HG--
extra : rebase_source : 5b2bf5a287fdf8075b3d7dde36b91f3c65b60728
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
This allows the GLContextProviderWGL to be created on the compositor
thread, which is something we need for webrender integration.
MozReview-Commit-ID: DtBe9nUTdK7
--HG--
extra : rebase_source : b31973542beca75255b64f350f47df16435a60e3
