This is easy to test:
Green tick marks (gcli_sec_good.svg) and Red Crosses (gcli_sec_bad.svg):
1. Go to https://csp-evaluator.withgoogle.com/
2. Shift+F2
3. security csp
I couldn't find a way to show the Orange Minus (gcli_sec_moderate.svg) but the path is changed in line with the other images and I did test it programatically so it will be fine.
MozReview-Commit-ID: 5897IV7epax
--HG--
rename : browser/base/content/gcli_sec_bad.svg => devtools/client/themes/images/gcli_sec_bad.svg
rename : browser/base/content/gcli_sec_good.svg => devtools/client/themes/images/gcli_sec_good.svg
rename : browser/base/content/gcli_sec_moderate.svg => devtools/client/themes/images/gcli_sec_moderate.svg
extra : rebase_source : b550cd4184f2c9e77b1d5df2cf5c67c1296b8ade
We invalidate if FrameAnimator::UpdateState marks the composited frame as valid, but we fail to do so if FrameAnimator::RequestRefresh does so.
The other place that sets the composited frame as valid is RasterImage::Decode. This call is actually redundant because the UpdateState call will do the same.
Even though we will invalidate when the decode produces results we could still draw incorrectly if something else invalidates. In which case we would only draw the part of the image that was invalidated. But that should actually be impossible as explained in the comment.
Flushing the cache at startup is already handled automatically by the
AppStartup code, which removes the entire startupCache directory when
necessary. The add-on manager requires being able to flush the cache at
runtime, though, for the sake of updating bootstrapped add-ons.
MozReview-Commit-ID: LIdiNHrXYXu
--HG--
extra : source : 8f4637881ddc42a948c894e62c8486fe8677a938
extra : histedit_source : e69395a2b87b2b0edb394686ed6ee24731ba9fb8
One of the things that I've noticed in profiling startup overhead is that,
even with the startup cache, we spend about 130ms just loading and decoding
scripts from the startup cache on my machine.
I think we should be able to do better than that by doing some of that work in
the background for scripts that we know we'll need during startup. With this
change, we seem to consistently save about 3-5% on non-e10s startup overhead
on talos. But there's a lot of room for tuning, and I think we get some
considerable improvement with a few ongoing tweeks.
Some notes about the approach:
- Setting up the off-thread compile is fairly expensive, since we need to
create a global object, and a lot of its built-in prototype objects for each
compile. So in order for there to be a performance improvement for OMT
compiles, the script has to be pretty large. Right now, the tipping point
seems to be about 20K.
There's currently no easy way to improve the per-compile setup overhead, but
we should be able to combine the off-thread compiles for multiple smaller
scripts into a single operation without any additional per-script overhead.
- The time we spend setting up scripts for OMT compile is almost entirely
CPU-bound. That means that we have a chunk of about 20-50ms where we can
safely schedule thread-safe IO work during early startup, so if we schedule
some of our current synchronous IO operations on background threads during the
script cache setup, we basically get them for free, and can probably increase
the number of scripts we compile in the background.
- I went with an uncompressed mmap of the raw XDR data for a storage format.
That currently occupies about 5MB of disk space. Gzipped, it's ~1.2MB, so
compressing it might save some startup disk IO, but keeping it uncompressed
simplifies a lot of the OMT and even main thread decoding process, but, more
importantly:
- We currently don't use the startup cache in content processes, for a variety
of reasons. However, with this approach, I think we can safely store the
cached script data from a content process before we load any untrusted code
into it, and then share mmapped startup cache data between all content
processes. That should speed up content process startup *a lot*, and very
likely save memory, too. And:
- If we're especially concerned about saving per-process memory, and we keep
the cache data mapped for the lifetime of the JS runtime, I think that with
some effort we can probably share the static string data from scripts between
content processes, without any copying. Right now, it looks like for the main
process, there's about 1.5MB of string-ish data in the XDR dumps. It's
probably less for content processes, but if we could save .5MB per process
this way, it might make it easier to increase the number of content processes
we allow.
MozReview-Commit-ID: CVJahyNktKB
--HG--
extra : source : 1c7df945505930d2d86a076ee20807104324c8cc
extra : histedit_source : 75e193839edf727874f01b2a9f6852f6c1f087fb%2C3ce966d7dcf2bd0454a7d673d0467097456bd782
This also adds assertions to ensure attributes and state don't change during
layout or frame construction.
MozReview-Commit-ID: BANcpxnRsYS
--HG--
extra : rebase_source : 5d1bc424d3ed90fda3047d3c92c09251346b7bec
In Fennec scenario, the package registration we should be monitoring for is different than "global".
OverrideLocalePackage handles the package overrides and gives us the right package name.
MozReview-Commit-ID: 44Nzd64CTq1
--HG--
extra : rebase_source : 848e98beae2222bce335f37ae87c60994ab6b0f9
Because of bug 1338651, we need to stick to BBB macosx64 builds for now.
MozReview-Commit-ID: AwQc5r6ikUN
--HG--
extra : transplant_source : %97%1B%95H%D8L1%87%84h%F4%89%0D%283w%98%7E%2C%F4
Now all properties in nsCSSProps::kMozAppearanceKTable are in
keyword list of -moz-appearance.
This is a PR of https://bugzilla.mozilla.org/show_bug.cgi?id=1361632
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because it's for stylo
Source-Repo: https://github.com/servo/servo
Source-Revision: 83020ffe291846ac425925da1dd4a3da9eb7cbad
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 41a11da87f4c3be15e6d297a40d5b9f024d38a48
In our current setup, in which links with an href attribute always match either
:link or :visited, no matter whether that attribute's value is a valid URI,
changes to the attribute always put the element into either the "match nothing"
state or the "match :link" state, via calls to Link::ResetLinkState.
The only thing FlushPendingLinkUpdates is needed for is (lazily, in case it
turns out to not be needed because the element got removed from the DOM anyway)
registering a history observer to switch the link state to :visited as needed.
This means that selector matching consumers that would never expose :visited
state to start with don't need to worry about calling FlushPendingLinkUpdates.
Video fails to play on Sony Z3C when the media server is in a state that no hardware codec can be created unless reboot. Fallback to software codec when that happens to workaround the issue.
MozReview-Commit-ID: AaRIw7KPaF3
--HG--
extra : rebase_source : d5106d5c75c4430450a81bbe9cfd536f01ef4df9
<!-- Please describe your changes on the following line: -->
Bug 1359787 - Stylo: Unite the implementation of background-image/ mask-image and border-image-source in {background|svg|border}.mako.rs
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 896a920ff53f683cdaac8bc6b2f796633a436a7f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9b64f6b658b04f16cdb1a4ee88075f3f0f41971d
<!-- Please describe your changes on the following line: -->
See https://github.com/servo/rust-mozjs/issues/343#issuecomment-294513870
Heap::new() constructor is unsafe. Heap should be set after reflect_dom_object call in order to prevent potential GC crashes.
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: e8aa3759bd8f74f7a962e421bd0cbf2a0a3e35da
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 1f7e2346a5f25efa3e055ff02cd6b9090de23837
Cameron McCormack
Gabriele Svelto
Manish Goregaokar
Michael Ratcliffe
Iris Hsiao
Carsten "Tomcat" Book
Timothy Nikkel
Kris Maglione
Robert Longson
Michael Brennan
Phil Ringnalda
Masatoshi Kimura
Gijs Kruitbosch
Xidorn Quan
Andreas Pehrson
Emilio Cobos Álvarez
Zibi Braniecki
Mike Taylor
Wander Lairson Costa
ffxbld
Ehsan Akhgari
Hiroyuki Ikezoe
Boris Zbarsky
David Major
Brian Grinstead
Sebastian Hengst
John Lin
cku
Imanol Fernandez
Daosheng Mu
Glenn Watson
Rob Thijssen