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.
Specifically on Windows nsIWidget::SetTransparencyMode can result in sync painting.
So we give nsContainerFrame::SyncWindowProperties a sync or async option and use the view manager post pending update infrastructure to flush SyncWindowProperties calls async.
Since bug 960465 patch 14, we've retained finished transitions in order
to handle the issues described in
https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The
code that did this made the assumption that the transition manager is
notified of the full sequence of style changes that happen to an
element. However, when an element becomes part of a display:none
subtree and then later becomes displayed again, the transition manager
is not notified of a style change when it becomes displayed again (when
we do not have the old style context).
This patch introduces code to prune the finished transitions when that
happens.
This really fixes only part of the set of problems described in bug
1158431, which also affect running transitions. However, it's the part
of that set that was a regression from bug 960465, which introduced the
retention of finished transitions, and which makes these issues
substantially easier to hit.
I'd like to fix this part quickly because it's a regression and we
should backport the fix.
Without the patch, I confirmed that the following two tests fail:
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5
With the patch, all the added tests pass.
--HG--
extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
Also renames IsPositioned to IsAbsPosContainingBlock.
--HG--
extra : rebase_source : b412f6291d34e30e8d57e054645bd1e04f43593f
extra : histedit_source : 01a2bd57de4eec4ecf3f3712ee609d70ca14cda4
IOW, drop the requirement that the parent *content* is a <fieldset>,
thus allowing a <legend> to become the fieldset legend also when it's
wrapped in one or more nodes that are styled with display:contents.
IOW, drop the requirement that the parent *content* is a <fieldset>,
thus allowing a <legend> to become the fieldset legend also when it's
wrapped in one or more nodes that are styled with display:contents.
- ScrollbarStyles now carries additional variables to support new
CSS scroll snapping attributes:
- scroll-snap-type / scroll-snap-type-x / scroll-snap-type-y
- scroll-snap-points-x / scroll-snap-points-y
- scroll-snap-destination
- (scroll-snap-coordinate does not apply to the scroll container)
- Simplified the constructor and operator== for ScrollbarStyles.
--HG--
extra : rebase_source : 91377588f8ae6b00f5ec0198000251820d4d2f85
The change to GetAfterFrameForContent prevents the reframe that is part
of the chain of events leading to this bug, and thus fixes the bug on
its own. The change to GetBeforeFrameForContent seems desirable for
symmetry.
Note that patch 6 also independently fixes the reported bug.
This probably needs somewhat careful review. We should examine:
(1) what the rules for calling nsLayoutUtils::GetBeforeFrame and
nsLayoutUtils::GetAfterFrame are, and whether both (or neither)
need to be patched.
(2) What the rules are for which frame the GenConProperty() lives on,
and whether we should adjust nsIFrame::GetGenConPseudos() to either
do something more intelligent, or assert about callers.
(We should probably clean up some of these things in a followup bug.)
Since the symptom of this bug is (once patch 4 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
This patch fixes the assertion on layout/generic/crashtests/600100.xhtml,
though I haven't investigated why.
Infallible new ensures that |item| is always non-null. And even if it didn't,
AppendItem() dereferences |item| before this code is reached.
--HG--
extra : rebase_source : 9abb8704ba03f455d6b77c5735fcb6cde4f8fef8
Known problem:
It would cause infinite loop if there is any line break happens inside
ruby base or annotation, or the width of container is not enough for
the widest pair/span. This might be fixed in bug 1098272.
Fixes the assertion failure with text:
"###!!! ASSERTION: Wrong line container
hint: '!aForFrame || (aLineContainer == FindLineContainer(aForFrame) ||
aLineContainer->GetType() == nsGkAtoms::rubyTextContainerFrame ||
(aLineContainer->GetType() == nsGkAtoms::letterFrame &&
aLineContainer->IsFloating()))', file
/home/sgbowen/builds/mozilla-central/layout/generic/nsTextFrame.cpp, line 1259"
which occasionally appears when opening pages with ruby or when running ruby
reftests.
Updates the manifest for ruby reftests to the current expectations (adjust
assertion counts, etc.)
To account for spacing between bases or text boxes during reflow, the line
layout which manages the bases updates its inline direction coordinate based on
the preferred inline size for the corresponding text boxes. Next, the base is
reflowed at the correct inline coordinate. Each paired text box is then also
reflowed at the proper inline position determined by (1) the current position of
its corresponding base and (2) its own preferred width.
In computing intrinsic widths, accounting for spacing is less complicated. The
minimum intrinsic width is the width of the widest ruby column, and the
preferred intrinsic width is the sum of all the ruby column widths. Each ruby
column width is the maximum width of its base box and text boxes. These
individual widths are determined using GetPrefISize on the base and text boxes.
Ruby base container frames store a list of pointers to the ruby text container
frames in the segment they denote. This list of pointers is created in the ruby
frame reflow method before calling the reflow method for the ruby base
container. The list exists and is used only during reflow of the main ruby frame
and is cleared before returning from reflow.
This isn't actually a problem for this patch series because the root
element can't have an ancestor that's reframed because it has no
ancestors, and reframes of the element itself trigger a restyling
operation that does actually start transitions.
That said, later patches in this bug hook in to ResolveStyleContext, and
other things might as well in the future, thus the FIXME.
