If we don't increment the reference count for the Atom in servo side, it's
possible to try to release the Atom in servo side even if we have already
released in gecko side. When it happens, nsIAtom::mKind is no longer reliable.
MozReview-Commit-ID: GrxbcYxowRB
--HG--
extra : rebase_source : 94e054e3357b31e398e8e5e81522dab3019c561c
…ic atom for will-change.
If we don't increment the reference count for the Atom in servo side, it's
possible to try to release the Atom in servo side even if we have already
released in gecko side. When it happens, nsIAtom::mKind is no longer reliable.
https://bugzilla.mozilla.org/show_bug.cgi?id=1401809
<!-- Please describe your changes on the following line: -->
---
<!-- 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
Source-Repo: https://github.com/servo/servo
Source-Revision: 581f0bf09a8ec35dadd5de207777f79138255e1a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b8daadff800d3af1378b2d93707e6a222533bdb7
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
The previous patch was ineffective, because the noted transform over-wrote
the yml configuration.
MozReview-Commit-ID: ICENT0DGzxy
--HG--
extra : source : e024769dac36e22935f1e64a328bb15334d6bdef
In order to let necko postpone the load of favicon, we have to set request context ID to the http channel that is created to load favicon.
This patch starts with passing a request context ID to nsContentUtils::LoadImage and makes other necessary changes to set the request context ID to the channel.
This patch covers two cases when loading a favicon:
1. Get the request context ID of the document load group, when <link rel="icon"> is found in the page.
2. Use the top level document's request context ID when using the default favicon.
Some moz.build files need to import in-tree Python modules in order to
parse test manifests. While bug 1402010 details a better solution
to remove this requirement, the easy fix is to expand the sparse
checkout to include the missing files.
MozReview-Commit-ID: FSx6u6r2XfE
--HG--
extra : rebase_source : 6e406dd76b4f78521cbbdc40110d0610c75e2b08
extra : amend_source : f68341a14f50c8ff6e7b62214fa455b75eabe908
I missed doing this in the original patch because my mozconfig defined the
CFLAGS globally to include -fsanitize-coverage.
MozReview-Commit-ID: 4QdiIgdfAm2
--HG--
extra : rebase_source : bfd1ef5097b91c23913c0349a04154f18f60eef5
Defining get() in the declaration of nsThreadManager implicitly sticks
an "inline" on the function, which is not what we want: inlining it
spreads around a lot of static initialization code. Providing an
out-of-line definition is much better in terms of code size.
The sizemodechange event is not strongly connected to the
visibilitychange event that the WPT minimize_window.py test is now
using to ascertain whether the window has been successfully iconified.
Because Marionette uses the sizemodechange event it is causing
intermittents such as https://bugzil.la/1397007. You can also read a
lengthy summary I did on the problem in https://bugzil.la/1397007#c11.
The fix for the problem is to wait for the visibilitychange DOM
event content.
MozReview-Commit-ID: B6i33Ee5iMC
