You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
These functions no longer perform any refcounting, so the existing names are
misleading.
MozReview-Commit-ID: LX55e0bUP8N
--HG--
extra : rebase_source : 89a3da577325286c1d31723acfd4153754f49703
This function captures a common usage pattern, generalizing the existing
IsMember() function.
MozReview-Commit-ID: 5Pt7kqyGD6Y
--HG--
extra : rebase_source : b03e4cc8f5a4a25da9236420f4b64493664b70e0
It seems silly to have a tiny utils class with a single function in its own
module. This patch moves it into nsStaticAtom.h/nsAtomTable.cpp. It also
renames nsAtomListUtils as nsStaticAtomUtils. Finally, it uses templates to
remove the need for the `aCount` parameter at callsites.
MozReview-Commit-ID: DvJVoZFv89c
--HG--
extra : rebase_source : 1f1dd27d56e46c71c30c10102ac6132a721e23d1
All prefs that need to be sent to a new content process are now put into the
shared memory segment, and they are identified by the pref name instead of an
index into a list. The old IPC used at process startup (in XPCOMInitData) is
removed.
Benefits:
- It removes the need for the early prefs list
(dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly
and often trips people up (e.g. bug 1432979, bug 1439406).
- Using prefnames instead of indices fixes some fragility (fixing bug 1419432).
- It fixes the problem of early prefs being installed as unlocked default
values even if they are locked and/or have user values.
MozReview-Commit-ID: FRIzHF8Tjd
The DOMMatrix.cpp changes are because it was sneaking in headers via another
unified file.
MozReview-Commit-ID: GPp9WOywI5D
--HG--
rename : dom/base/nsGenericDOMDataNode.cpp => dom/base/CharacterData.cpp
rename : dom/base/nsGenericDOMDataNode.h => dom/base/CharacterData.h
The nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
Summary: In this case the radiobox is in a SVG <use> subtree.
Reviewers: smaug
Bug #: 1409183
Differential Revision: https://phabricator.services.mozilla.com/D741
MozReview-Commit-ID: Abkg7ahST5t
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
Once we reached the state of STATE_WAITING_TO_FINISH, we just need to wait for
the final MozAfterPaint which is corresponding to flushRendering() after
"reftest-wait" removal.
MozReview-Commit-ID: EJxDYUnqbmr
--HG--
extra : rebase_source : fdb5c30142def4c0138bc6af2c510d85f30ed7f3
Also, fix a bug when copying back the planned limits after
updating it for the first span group. It should only copy
back track sizes that were actaully spanned by those items,
other content-sized tracks' limits should remain at "infinity".
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 8ebb459445cab23288a6c4c86e4e00c6ee611e34
To correctly apply pixel snapping during display list construction we would need to snap each tile of a repeated gradient individually. It's preferrable to do this in WebRender rather than decompose gradients into many display items.
We no longer support legacy extensions with e10s shims, and the only remaining
uses that matter are in-tree test harnesses, which have been fixed. This flag
no longer serves a purpose.
MozReview-Commit-ID: EdCNqF4MttN
--HG--
extra : rebase_source : 0fef334354faa7541628614cb964a29faaa9df41
Now that nsGkAtoms is in xpcom/, we can call nsGkAtoms::AddRefAtoms() from
NS_InitAtomTable(), which removes the need for DefaultAtoms, and also removes a
duplicate static atom.
MozReview-Commit-ID: CyfvnvZomzZ
--HG--
extra : rebase_source : 53ead62323a340038c1b4594b1a3eb225aa19626
PresShell only uses performane.now to track refresh times, and notify internal
observers. We can provide more accurate times by not clamping and jittering
these numbers.
MozReview-Commit-ID: FkDGJhrLeAy
--HG--
extra : rebase_source : 99c571d1e5df53f51b4be0304df3818c161d2972
There are only a handful of them, and two of them are duplicates of atoms
within nsGkAtoms anyway.
MozReview-Commit-ID: Cb90STdeGdK
--HG--
extra : rebase_source : 6ebc6996b129e70907f634e1876725c9e5da41ab
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
The atoms in nsHTMLTags are a subset of nsGkAtoms, which means that
sTagAtomTable[] currently ends up holding duplicate pointers to the same static
atoms.
This patch removes sTagAtomTable[]. The only place that used sTagAtomTable[]
was nsHTMLTags::AddRefTable(). It now instead calls NS_GetStaticAtom() to get
the static atoms registered by nsGkAtoms.
The patch also moves some checking of sTagNames from RegisterAtoms() (which is
removed) to AddRefTable().
All this reduces the number of duplicate static atoms from 148 to 12.
MozReview-Commit-ID: 14qXYeoorFr
* * *
[mq]: foo
MozReview-Commit-ID: AgQbXlcvWrt
The font face set is owned by the document now, and the shell knows about
refresh driver ticks. There's no reason for it to live in the pres context.
MozReview-Commit-ID: I8gtimok7VG
--HG--
extra : rebase_source : a3216a2efe4bdddbbd83751f3ad2299372232409
We flushed the style of the original doc, but not layout, and thus the iframe
resize wasn't noticed, and the style flush on the child presShell wasn't
sufficient.
Do a style flush on the child document instead, so that it flushes layout on the
parent document too if needed.
MozReview-Commit-ID: 5ZhBuxpKIUg
GetBoxShadowRectForFrame is called while we're calculating the visual
overflow bounds for a frame. So it is not valid for it to use the frame's
"current" visual overflow rect (which may be uninitialized or stale).
MozReview-Commit-ID: J52dxIMrMg5
For now, we are going to make _all_ CSS Animations related timer fuzzing
only applicable in Resist Fingerprinting Mode (addressing the last couple
that had not already been configured that way.)
We hardcode their content mix-ins as zero, but leave comments indicating
how they should behave.
MozReview-Commit-ID: KhmV7wO8Pt5
--HG--
extra : rebase_source : 3b087d40b6332d447b442b435ed6fee8993e0145
In nsFrame::ComputeSize and nsFrame::ComputeSizeWithIntrinsicDimensions, the
following expressions
isFlexItem && usingFlexBasisForISize
isFlexItem && !usingFlexBasisForISize
are sometimes compiled by recent gcc/clang in the opposite order, viz
[!]usingFlexBasisForISize && isFlexItem. In this case the transformation is
correct as can be seen by analysing code earlier in these functions.
Unfortunately this causes Valgrind/Memcheck to report a branch on undefined
data which, in this case, is a false positive.
A simple fix is simply to initialise usingFlexBasisForISize to false at its
declaration point.
--HG--
extra : rebase_source : 39877e4ea8ec678288e6b49af120445c96ef8c0a
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
Summary:
Also, make stuff sound in presence of CSSOM and what not.
The dirty: false thing is reverting an accidental change that landed in the
de-XBL stuff, which was harmless, but now wouldn't let me assert stuff properly.
Reviewers: xidorn
Bug #: 1445682
Differential Revision: https://phabricator.services.mozilla.com/D748
MozReview-Commit-ID: K0W2Rv0qK8X
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
When we fail to generate an image key for an image, it is likely because
the image container is empty. This is not a fatal error, it just means
we haven't produced a frame yet. We should be using NOT_READY instead of
BAD_IMAGE as a result. This is important because reftests rely upon
these error codes to know whether or not they should wait; it could
cause intermittent failures.
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
As with an earlier patch in this series, we rename the file_* test content files
to test_*_to_rename.html in this patch, and then in a subsequent patch drop the
_to_rename suffix so that we can trace the history of the test_* files back to
their file_* equivalents.
MozReview-Commit-ID: Jes8xSQzkCF
--HG--
rename : layout/style/test/file_animations_effect_timing_duration.html => layout/style/test/test_animations_effect_timing_duration_to_rename.html
rename : layout/style/test/file_animations_effect_timing_enddelay.html => layout/style/test/test_animations_effect_timing_enddelay_to_rename.html
rename : layout/style/test/file_animations_effect_timing_iterations.html => layout/style/test/test_animations_effect_timing_iterations_to_rename.html
rename : layout/style/test/file_animations_iterationstart.html => layout/style/test/test_animations_iterationstart_to_rename.html
rename : layout/style/test/file_animations_pausing.html => layout/style/test/test_animations_pausing_to_rename.html
rename : layout/style/test/file_animations_playbackrate.html => layout/style/test/test_animations_playbackrate_to_rename.html
rename : layout/style/test/file_animations_reverse.html => layout/style/test/test_animations_reverse_to_rename.html
rename : layout/style/test/file_animations_styles_on_event.html => layout/style/test/test_animations_styles_on_event_to_rename.html
rename : layout/style/test/file_transitions_replacement_on_busy_frame.html => layout/style/test/test_transitions_replacement_on_busy_frame_to_rename.html
These files only use references to string types, e.g. "nsAString&", so they
only need forward-declarations of these types -- not the full definition.
Note that the last file here (nsStyleUtil.h) already has an #include for
nsStringFwd.h, which is why that files change is just a pure removal (of the
unnecessary nsString.h #include).
MozReview-Commit-ID: 9sLSyeBS49M
--HG--
extra : rebase_source : 683a2c621f7b7cae754f129effabd9defe7ba665
nsStyleConsts.h doesn't use anything from gfxRect.h or nsFont.h, so this patch
removes those #includes from it. However, it does need some other headers that
it was pulling in indirectly via those #includes, which I'm now making it
*directly* #include. Specifically, it needs:
- inttypes.h for "uint8_t"
- gfxFontConstants.h for NS_FONT_WEIGHT_BOLD and related constants.
On its own, the above changes cause build errors in nsStyleCoord.h, because
that other header has an #include for nsStyleConsts.h, which it was
inadvertently depending on (very indirectly) to provide some definitions (via
the aforementioned removed #includes). So we need to give nsStyleCoord.h some
new #includes to directly provide what it needs & keep it
compiling. Specifically:
- mozilla/gfx/Types.h for the mozilla::Side type
- nsISupportsImpl.h for the NS_INLINE_DECL_THREADSAFE_REFCOUNTING macro
MozReview-Commit-ID: BDlaIIOQiPE
--HG--
extra : rebase_source : a16f85f030330ff009461c4d48028327cc4ba0cf
Should pass fine.
Was disabled in Bug 1380053, presumably because it asserted or what not at that
point? Who knows.
MozReview-Commit-ID: LSH6ZId9Ezj
--HG--
extra : rebase_source : fb1bfeae35442d2acc65b8f5ceb8ee1f75f33303
This is consistent with most other methods that take a drawTarget parameter r=dholbert
--HG--
extra : amend_source : 77aa7f7d9cb19f9aa08014fff3b209dc151b75f3