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
I did manual testing for ::-moz-dropdown-list. Unfortunately, the only way I
know to test it is to have a combobox in a non-e10s window and dynamically
change its background color, then drop down the dropdown and see whether it
picked up the changed background color.
MozReview-Commit-ID: B2RkW4otv4s
This changeset is intended to revert the logic from "Bug 1269045 part 3" [1],
*specifically* for legacy "-webkit-box"/"-webkit-inline-box" flex containers.
[1] https://hg.mozilla.org/mozilla-central/rev/707b2ab5879d
MozReview-Commit-ID: vc4TuAoLai
--HG--
extra : rebase_source : 3cc143055fc46851e882d48df2bd913ca1487793
This patch doesn't affect behavior at all -- it just refactors the
sanity-checking function "FrameWantsToBeInAnonymousItem()", so that the next
patch in this series can give it a new special case that checks a state bit on
the container frame.
This patch renames "parent" to "container" in this function's variable-names,
for clarity, because when this function returns true, the flex/grid container
is actually NOT expected to be the parent of aFrame. Rather, it's expected to
be the grandparent, and the anonymous flex/grid item would be the parent. So,
"aContainerFrame"/"containerType" is a bit more accurate (representing the
flex/grid container for aFrame).
Also worth mentioning: this patch makes FrameWantsToBeInAnonymousItem() perform
its own local GetType() call, instead of accepting an already-queried GetType()
result from the caller (as it previously did). Technically this could cause a
slight perf hit, but it doesn't really matter since this is in "#ifdef DEBUG"
sanity-checking code anyway. We could keep the nsIAtom* as an additional arg
to avoid this new call, but it seems better to fall on the side of simplicity &
just look up GetType() independently, rather than complicating the function
signature with an extra arg.
MozReview-Commit-ID: 4oJFkQMuH9c
--HG--
extra : rebase_source : 3b5d60d8c15e69470f450168698b855e353486d3
I noticed that our current behavior in ContentRangeInserted is incorrect. Unlike
ContentInserted (where this code lived originally), ContentRangeInserted takes a
start and end element. I'm not sure if we ever take that path for new content that
needs style, but it seemed sketchy. And generally, it seems nice to just always
style new content the same way (though we still need to style NAC by the subtree
root, since it hasn't been attached to the parent yet).
For situations where there is indeed only one unstyled child, the traversal
overhead should be neglible, since we special-case the single-element in
parallel.rs to avoid calling into rayon.
Being more explicit about what we want here also makes us more robust against
the other handful of callpaths that can take us into
nsCSSFrameConstructor::{ContentRangeInserted,ContentAppended}. Currently we
can call StyleNewSubtree on an already-styled element via RecreateFramesForContent,
which triggers an assertion in the servo traversal.
MozReview-Commit-ID: DqCGh90deHH
Note that at the callsites in nsCSSFrameConstructor.cpp, we have to also check
the frame type (since the frame state bit is in a range of bits whose meaning
differs depending on frame type). The first change in this patch is the
addition of a convenience fucntion that checks both the frame type as well as
the frame state bit.
MozReview-Commit-ID: DEOThTX5NAO
--HG--
extra : rebase_source : 95e86eec663b3ef2e7bb86214871fcd3ea86057c
The class PresShell doesn't have ns-prefix, so it's better to drop ns-prefix
in the file names to avoid confusion.
MozReview-Commit-ID: IljxsF5CVjh
--HG--
rename : layout/base/nsPresShell.cpp => layout/base/PresShell.cpp
rename : layout/base/nsPresShell.h => layout/base/PresShell.h
extra : rebase_source : e73a6873f360a7223d87bd22d9854fc9603c499f
Bug 1259889 Part 2 [1] cannot be reverted cleanly, so I manually undo those
changes in this patch. That is, remove the ability for html.css to
invalidate dynamically since it was added specifically for details element.
Although reftest-stylo.list explicit mentions "DO NOT EDIT!", but I still
remove details pref from the file, since it doesn't harm to edit it anyway.
[1] https://hg.mozilla.org/mozilla-central/rev/30aaf3805b56
MozReview-Commit-ID: FsyTGQTxujh
--HG--
extra : rebase_source : 25e5a05a8a5a47642772da69f427631fa07e232d
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
The major change to the Iterator is due to the fact that the end of a
LinkedList is represented by nullptr.
Also delete the type conversion functions which are no longer needed.
MozReview-Commit-ID: 2lYtFW9pSon
--HG--
extra : rebase_source : c822e937679e57a9f2d3ab034e5147fc3aea9e8e
Change the logic that moves the main summary to the front from operating
on generated frames in DetailsFrame::SetInitialChildList() to operating
on frame construction item list in AddFrameConstructionItemsInternal()
so that it will be correct when cooperating with ::first-line.
The root cause of the bug reported is because when specifying
::first-line on details element, the first frame of summary element,
which is generated due to ib-split, will be wrapped in nsFirstLineFrame.
The original code fails to find the summary frame in the wrapper frame
and triggers assertion because of the second ib-split summary frame. To
fix that, we need to descend into the child list of wrapper frames when
checking the main summary.
Add original test case as a crashtest as well as reftests to clearly
reproduce the issue.
Note that in the reftest, the blue color in ::first-line is applied
incorrectly to the second line in the summary due to bug 520605.
MozReview-Commit-ID: Bv4Vcvxp6pY
SummaryFrame had been removed in bug 1258657, so now HTMLSummaryElement
is always rendered as an ordinary inline or block frame. Therefore, the
check in FindHTMLData is not needed anymore.
MozReview-Commit-ID: Ikxla6QoNLT
Per bug 1299753 comment 20, SetFlags() is designed for flag propagation
to continuations during block reflow. To avoid misuse, I expand
SetFlags() directly in the only reasonable caller nsBlackFrame::Init(),
and replace other usages by AddStateBits().
MozReview-Commit-ID: GsbE2Z0Rps1
--HG--
extra : rebase_source : 72a64e9218870d638f67d1b586f533cd7d16c491
nsCSSFrameConstructor::ConstructNonScrollableBlock() has logic to
determine whether to create a block formatting context for a block
frame. I refactor the function to make it reusable by
nsCSSFrameConstructor::ConstructDetailsFrame().
Also, make NS_NewBlockFrame() accept two arguments as other frame
factory functions so that it could be pointed by BlockFrameCreationFunc.
NS_NewBlockFormattingContext is changed accordingly.
The construction for a scrollable DetailsFrame will be further revised
in Part 3.
MozReview-Commit-ID: 8TwG9YMyGva
--HG--
extra : rebase_source : fffdd974df81a809a607491d2534aa8dd2d13ab1
The main renaming was generated with the following python script:
```
import sys
import re
CAMEL_CASE_REGEX = re.compile(r"(^|_|-)([A-Z])([A-Z]+)")
DISPLAY_REGEX = re.compile(r"\bNS_STYLE_DISPLAY_([^M][A-Z_]+)\b")
def to_camel_case(ident):
return re.sub(CAMEL_CASE_REGEX,
lambda m: m.group(2) + m.group(3).lower(), ident)
def constant_to_enum(constant):
return "StyleDisplay::" + to_camel_case(constant) + ("_" if constant == "NONE" else "")
def process_line(line):
return re.sub(DISPLAY_REGEX,
lambda m: constant_to_enum(m.group(1)), line)
lines = []
with open(sys.argv[1], "r") as f:
for line in f:
lines.append(process_line(line))
with open(sys.argv[1], "w") as f:
for line in lines:
f.write(line)
```
And the following shell commands:
```
find . -name '*.cpp' -exec python display.py {} \;
find . -name '*.h' -exec python display.py {} \;
```
MozReview-Commit-ID: 91xYCbLC2Vf
It will be called in the next flush, so no need to do it eagerly.
MozReview-Commit-ID: 1B8pzn0dqBO
--HG--
extra : rebase_source : 79a4203d13a2b9d48cd9c9d6fa5c5e08974d4765
extra : source : 162b17483adb18d3d05d866853fb8f841dee846d
