This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
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
Unfortunately this means that we need to export a couple more headers, but that
should be ok.
In particular, we have to export some headers that are #included by
nsCSSFrameConstructor.h, because nsCSSFrameConstructor.h itself will now be
included in more places outside of layout/, by .cpp files that don't necessarily
have the ability to indirectly #include its other headers, unless we export
them.
MozReview-Commit-ID: 2n9KHW6Yjrd
In particular, even when there are no frames, we may have used the rule
cascades / stylist data (for different stuff, like font-feature-values, thus the
regressing bug).
Using the old rule cascades / stylist data without knowing it has changed is
wrong, thus the bug.
Now that media query change stuff is async and has a well-defined processing
point, we should be able to just call it without too much worry.
Also note that at the point the extra hints are passed, if there's no root frame
/ elements are not styled / etc, we'll optimize away the change hint.
The test-case intermittently fails without this patch, but I didn't manage to
make a better one, unfortunately :(
MozReview-Commit-ID: LY2HRIlAKHX
This fixes a bug where EnsureEventualDidPaintEvent needs to be called separately for each transaction id, but we skip it since mFireAfterPaintEvents is still true from the previous paint.
We now track the equivalent state by checking for the presence of mTransactions[aTransactionId], and correctly schedule an eventual didpaint for each id.
MozReview-Commit-ID: JnRTycGEyom
In particular, even when there are no frames, we may have used the rule
cascades / stylist data (for different stuff, like font-feature-values, thus the
regressing bug).
Using the old rule cascades / stylist data without knowing it has changed is
wrong, thus the bug.
Now that media query change stuff is async and has a well-defined processing
point, we should be able to just call it without too much worry.
Also note that at the point the extra hints are passed, if there's no root frame
/ elements are not styled / etc, we'll optimize away the change hint.
The test-case intermittently fails without this patch, but I didn't manage to
make a better one, unfortunately :(
MozReview-Commit-ID: LY2HRIlAKHX
This fixes a bug where EnsureEventualDidPaintEvent needs to be called separately for each transaction id, but we skip it since mFireAfterPaintEvents is still true from the previous paint.
We now track the equivalent state by checking for the presence of mTransactions[aTransactionId], and correctly schedule an eventual didpaint for each id.
MozReview-Commit-ID: JnRTycGEyom
Much in the spirit of bug 1434474.
We right now call MediaFeatureChanges sync or async pretty randomly. This has
caused bugs in the past like bug 1413143.
Unify media feature changes, and only post them async, and flush them from
FlushPendingNotifications.
This also fixes a pre-existing problem where style wasn't flushed correctly from
getComputedStyle when there were pending media feature values.
MozReview-Commit-ID: H9S1M8fk5H4
Everything that needs them up-to-date will call flush appropriately, there
should be no need to do it manually.
This way we coalesce all the stylist updates until the next style flush in the
best case, or until one of the consumers actually needs them.
MozReview-Commit-ID: BVsxXxhtcKL
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
I'm pretty sure this is not a problem now, since we don't mutate the DOM from
painting, and we don't have legacy extensions anymore.
Just to confirm, I did a try run with a RELEASE_ASSERT(!CheckDOMModified()), and
it passed.
MozReview-Commit-ID: HTekD8tsz9v
Returning a zero-sized viewport in the case there's no shell / pres context.
For now, no other change yet. After this we can start tweaking the ShadowRoot
Stylist setup, and even try to return computed styles without a document \o/.
MozReview-Commit-ID: 3cT2PKQISri
This EnsureEventualDidPaintEvent() creates software timer. But this timer will
bring several intermittent tests fail. For example, if we want to check the
compositor animation property. If test receives MozAfterPaint of the timer,
there doesn't have animation property on compositor, as result of this, a test
will fail.
I think we don't need to create this timer each time since current painting is
happening synchronously under the refresh driver.
[1] https://searchfox.org/mozilla-central/rev/919dce54f43356c22d6ff6b81c07ef412b1bf933/layout/base/nsPresContext.cpp#189
MozReview-Commit-ID: Hb7UEITer5t
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
These functions are now dead code. And really, they were already dead code
even before this patch-stack -- they were only called in never-evaluated
(and now-deleted) #else clauses.
MozReview-Commit-ID: AeY6Z3ybmsv
This patch drops all MOZILLA_INTERNAL_API checks (and the bodies of any
associated "#else" clauses) from these files. The basic assumption here is
that MOZILLA_INTERNAL_API is #defined in all (supported) compilation units that
#include these files, so the checks are superfluous and the #else clauses are
dead code.
(If this assumption is mistaken and there is some .cpp file in our codebase
that #includes this header and yet does not have MOZILLA_INTERNAL_API, we will
find out via bustage on treeherder.)
MozReview-Commit-ID: 8dHJFBDVHwT
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
