When a reframe happens on the parent of a pseudo element which has animations,
we need to grab style for the pseudo element that includes the animations'
style and also *replace* old style context (that does not include animations'
style) with it. Otherwise, we will use the old style context that has *no*
animations style, as a result, we will see a flicker right after the reframe.
Two reftests in this patch fail without this fix. One is for CSS transitions,
the other one is for CSS animations.
MozReview-Commit-ID: 6pCdnQ1DGUY
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
We don't need to reparent when moving things in/out of anonymous boxes and using the stylo backend.
MozReview-Commit-ID: 8C6ScqTuR9z
--HG--
extra : rebase_source : 0f180647a39a051e2a5aabe642031134852bf95b
This removes the two calls to `FlushPendingLinkUpdates` in nsCSSFrameConstructor
and GeckoRestyleManager, which appear to have no effect.
Looking through what the pending link code is attempting to do:
* When a new anchor is bound in `BindToTree` we do:
1. Link::ResetLinkState(false, Link::ElementHasHref());
* Set link's mLinkState to default (either unvisited or not link)
* Set element's link mState bits to default (either unvisited or not link)
2. doc->RegisterPendingLinkUpdate(this);
* Schedules idle dispatch to run `FlushPendingLinkUpdates` within 1 sec
* In `FlushPendingLinkUpdates`:
* For each pending link, call element->UpdateLinkState(link->LinkState());
1. Register link for async history update to get potential future visited
state
2. mLinkState is still unvisited / not link until we hear from history, so
element state is unchanged
Thus, there seems to be no need to call `FlushPendingLinkUpdates` outside of
`BindToTree`, since visited state is always applied async anyway (so it doesn't
work as an optimization to avoid restyling if visited, since that will trigger
later).
MozReview-Commit-ID: KbFuKve1KUi
--HG--
extra : rebase_source : fdc098397d2fe9963ff82566f7a6b7c8c4656d63
(This makes it behave a bit more like a normal CSS block, and it ensures that
it can provide a float manager to its descendants.)
MozReview-Commit-ID: FmnQYjzD2eD
--HG--
extra : rebase_source : fe5bc96985b0e13a805b014653c422a83b27cfc0
Previous to these patches, the style resolution happening on [1] made the style
data stick on the element, so we'd never think it was the initial style, even if
it was.
This was wallpapering the fact that, if that was the initial style, we'd never
have another chance of traversing the document when [2] kicked in.
This somehow just happened to work, but is a very fishy way to get it to work.
Instead, call StyleDocument() properly _before_, and rely on the fact that it
will stop when it has a non-null binding, and only if it fails explicitly style
the children.
This fixes the few XBL test-cases with this patch series that exercise
-moz-bindings on the root element without the root being styled, and makes the
-moz-binding code more consistent in both places of the frame constructor.
[1]: http://searchfox.org/mozilla-central/rev/5dadcbe55b4ddd1e448c06c77390ff6483aa009b/layout/base/nsCSSFrameConstructor.cpp#2526
[2]: 3330653dc8/components/style/traversal.rs (L439)
MozReview-Commit-ID: HbjsD6nYsvX
--HG--
extra : rebase_source : 0f9be9665faf6a5e32f527c12dbd00f35a89b986
In case of removing summary element, we need to check details *frame* children
instead of details *element* children since the summary element has been
already removed from details element children list.
MozReview-Commit-ID: GEzDId9CYf9
--HG--
extra : rebase_source : 50834606413b916a3c0d6074a7a52e8bdbe845a0
Considering the case where the summary element has position:absolute, we need
to use inFlowFrame and its parent instead of aFrame itself.
MozReview-Commit-ID: Ds8xxyBuyO5
--HG--
extra : rebase_source : 6254dae16e0371c55ae469390a5aaafa300b740c
The child anon box may be an nsHTMLScrollFrame, a nsRootBoxFrame, or a
nsSimplePageSequenceFrame. nsHTMLScrollFrame already knows how to deal with
its anonymous box kids, nsRootBoxFrame doesn't have any, and the next changeset
will deal with anon box kids of nsSimplePageSequenceFrame.
MozReview-Commit-ID: 2ZV061EhRmc
--HG--
extra : rebase_source : 43084315454284fc6d7353ccdb20137611b2ee46
Delete the NS_WARNING because it's not needed once this bug is fixed.
MozReview-Commit-ID: Ht3ayjSvYW8
--HG--
extra : rebase_source : 457f011ac64fcd511ec2f15ea2b8ce24a88b0d84
As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
If a frame doesn't have that bit then skip mCounterManager.DestroyNodesFor()
when the frame is destroyed because it's definitely not known by
the CounterManager.
MozReview-Commit-ID: Ky3575QvZME
When the counter style in the style struct changes, CalcDifference
would return ReconstructFrame, which should cause corresponding use
node to be reconstructed. That means a use node with retired counter
style should always be destroyed in the next flush, so it makes no
sense to reset them anymore.
However, we would still need to mark counter lists dirty because
otherwise their content may not get update when there are changes to
counter styles which are still valid.
MozReview-Commit-ID: FnBPx81StzG
--HG--
extra : rebase_source : 2adf7b64484746a5f416b7902df2ac718a3fdeab
And propagate the new flag to servo if mRestyleForCSSRuleChanges is set.
MozReview-Commit-ID: HRZ5duYgciF
--HG--
extra : rebase_source : 65528ea0dfa21e84bb9184a849c72a5c322e306b
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
This also happens to fix other bugs, like making display: contents pseudos
animatable, which weren't before.
MozReview-Commit-ID: LhwTPNbFvSZ
--HG--
extra : rebase_source : 785105b08d6bfa15ad257e61b769a263c6810ad0
Probably GetAnimationCollection itself should assert against it, but that's a
bigger task right now...
MozReview-Commit-ID: JxFWXtgMAXy
--HG--
extra : rebase_source : 90ffd33e56dd8d285765bc7a06572b0ae229b5e7
If we append children to an element inside a display:none tree and we
decide not to do lazy frame construction, StyleNewChildren will assert.
It's also unnecessary, anyway, since we want to keep the descendants
of the display:none element free of ElementData.
MozReview-Commit-ID: 19tuzAzAIDp
--HG--
extra : rebase_source : 457a2c037a02ff50647eed84f51cbee29f737ecd
It wasn't clear to me whether the existing check for whether we are
under a restyle was sufficient to cover all cases of reconstructing
frames, so this patch makes it more explicit by passing that state
into ContentAppended and ContentRangeInserted.
MozReview-Commit-ID: HjlDCzJv97n
--HG--
extra : rebase_source : 8ce4ba097f706e3d9a1f1292515dca64fb8765ab
Note that this removes the useless (because this anon box is never absolutely
positioned) "clip: inherit" style.
MozReview-Commit-ID: iJJdv5VL06
--HG--
extra : rebase_source : d7a8697a89391eb6a80683dcbe8e3fa6f76c6a41
::first-letter is not support by stylo yet. (bug 1324618)
MozReview-Commit-ID: KwQk2jhn53c
--HG--
extra : rebase_source : 9bafad53a38fd11aae7be09780ee7680d9a40e1c
The relevant frame classes are:
SubDocumentFrame
ListControlFrame (only when used for (non-e10s?) comboboxes)
PluginFrame
ViewportFrame
MenuPopupFrame
The view is now created in the frame's Init() method, except for
ViewportFrame which has its view assigned by the frame constructor
via a SetView() call.
MozReview-Commit-ID: 4O7Hm1yqwIp
Views are used for PluginFrame which inherits nsFrame, not nsContainerFrame,
so it's more appropriate that these methods should live in nsIFrame/nsFrame.
MozReview-Commit-ID: 87EgCnkF5YT
