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
This misspelling was introduced in bug 1125767, changeset b9951cca6d1f.
MozReview-Commit-ID: KQNlLelY2Kn
--HG--
extra : rebase_source : 7b2b8379da23b06737b462dd4c316b5758d807a9
This includes, for example :hover.
Also removes the call to IsStyledByServo() in the document constructor, it's not
only unnecessary, but also we call UpdateStyleBackendType() too early.
MozReview-Commit-ID: 4YfCdmLoSxu
We can use nsBlockFrame to render summary elements.
This change undoes "Bug 591737 - Add SummaryFrame" and remove
summaryFrame usage in DetailsFrame and nsCSSFrameConstructor.
MozReview-Commit-ID: 4aJvHVPfsBb
--HG--
extra : rebase_source : 8e197fa61cfcbaf066a8a510aef7c92adddd30f2
These new enum values are added with same behavior as their modern flexbox
equivalents -- they're hooked up to NS_NewFlexContainerFrame, and they're
listed alongside the modern flexbox enums in 'switch' & 'if' statements.
There's one exception, which I call out with a comment at the end of the patch:
we don't treat -webkit-box the same as flexbox in IsFlexOrGridDisplayType(),
because that method is used to determine whether we should blockify
inline-level children of a flex/grid container, and we don't want to blockify
any children of a -webkit-box. (Instead, we want to wrap them in an anonymous
flex item. That happens in the next patch.)
MozReview-Commit-ID: 9BB4Ib2KpvE
To retain backward compatibility, <details> tags should not collapse its
children when dom.details_element.enabled = false.
--HG--
extra : rebase_source : 6b47e64672720ffecd23f670c31de1c7d92bee8c
This patch makes methods of FramePropertyTable and FrameProperties to be
simple template wrapper functions. Then it converts all references to
FramePropertyDescriptor to use "void" parameter to simulate the current
unsafe behavior.
SmallValueHolder is used for storing small values like int32_t, float,
which can fit in the size of a pointer directly, and thus no lifetime
management is needed.
--HG--
extra : source : 88b2723cddf119d73d8a442d8238b50406e9d604
layout/base/nsCSSFrameConstructor.cpp:12067:12: warning: will never be executed [-Wunreachable-code]
layout/base/nsPresContext.cpp:2861:10: warning: will never be executed [-Wunreachable-code]
layout/generic/nsFrameSetFrame.cpp:730:11: warning: will never be executed [-Wunreachable-code]
layout/generic/nsFrameSetFrame.cpp:725:11: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:268:62: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:269:66: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:270:68: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:271:75: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:272:73: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:273:81: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:274:69: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:275:60: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:276:68: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:277:68: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:279:18: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:290:62: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:291:66: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:292:68: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:293:75: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:294:73: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:295:81: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:296:69: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:297:60: warning: will never be executed [-Wunreachable-code]
layout/generic/nsSelection.cpp:5657:7: warning: will never be executed [-Wunreachable-code]
layout/mathml/nsMathMLmrootFrame.cpp:405:5: warning: will never be executed [-Wunreachable-code]
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
When nsDisplayListBuilder doesn't build caret, we need to skip building
AccessibleCaret frames. We check that the content of the frame has
"moz-accessiblecaret" class.
