The mechanism was added in bug 1168705 for fullscreen, and is only used
for this since then. The spec now has a specific step for this in the
event loop, so specialize this mechanism to match the spec closer.
This patch also changes the caller type of the fullscreenchange event
from non-system to system (via using DispatchTrustedEvent rather than
EventTarget::DispatchEvent(Event&)).
Differential Revision: https://phabricator.services.mozilla.com/D5235
--HG--
extra : source : 179f5fbd9db08518804b613f5e3fefa659c1e0a2
ColumnSetWrapperFrame is needed to implement column-span. Patches in bug
1421105 will utilize this frame.
Co-authored-by: Neerja Pancholi <npancholi@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D5092
--HG--
extra : moz-landing-system : lando
Some methods were not overrides and were never overridden, so they could simply
be non-virtual.
Others were overrides but were not overridden, so they could benefit from being
final to hopefully lead to devirtualized calls.
Though some of these are not strictly necessary because they are inside 'final'
classes, I think they're worth adding anyway, because:
- The 'final' keyword becomes more obvious when looking at methods without the
wider context in sight (e.g., in reviews or searchfox).
- If one day any of these classes becomes non-final, it would keep the final
attribute on these methods by default, and force the programmer to explicitly
reflect before removing 'final' from the methods that need to be overridden.
Depends on D5020
Differential Revision: https://phabricator.services.mozilla.com/D5021
--HG--
extra : moz-landing-system : lando
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
This patch:
- removes GetTransactionAtIndex(), because getTransactionAtIndex() can be used
instead;
- renames a lot of things;
- updates some comments.
--HG--
extra : rebase_source : 845a1c1d5fe7f84eaa03db39a344d98fd5784afd
The pagehide handler has been as dead as a doornail for a while now,
but the side-effect of forcing the creation of an about:blank document
in non-remote windows was implicitly relied upon by some tests.
This removes the dead code and fixes up some tests.
Differential Revision: https://phabricator.services.mozilla.com/D4962
--HG--
extra : moz-landing-system : lando
Otherwise the ShadowRoot for <use> or other internal ones may not get cloned
properly.
Differential Revision: https://phabricator.services.mozilla.com/D4756
--HG--
extra : moz-landing-system : lando
AccessibleCaretEventHub is an nsISelectionListener of Selection whose type is
"normal". This is added only when nsFrameSelection::Init() is called and
accessible caret is enabled. Additionally, nsFrameSelection::Init() is
always called immediately after creating nsFrameSelection.
Therefore, when AccessibleCaretEventHub is installed to Selection, this is
always second selection listener and won't be installed multiple times. So,
Selection can store pointer of AccessibleCaretEventHub directly only when
it's enabled and the Selection needs to notify it of selection change.
This patch makes Selection stores AccessibleCaretEventHub with RefPtr, then,
makes Selection::NotifySelectionListeners() call its OnSelectionChange()
immediately after AutoCopyListener.
Unfortunately, this patch includes making of MOZ_CAN_RUN_SCRIPT_BOUNDARY and
MOZ_CAN_RUN_SCRIPT a lot since some methods of AccessibleCaretEventHub are
marked as MOZ_CAN_RUN_SCRIPT and including AccessibleCaretEventHub.h into
Selection.h causes compile the compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D4733
--HG--
extra : moz-landing-system : lando
Otherwise the ShadowRoot for <use> or other internal ones may not get cloned
properly.
Differential Revision: https://phabricator.services.mozilla.com/D4756
--HG--
extra : moz-landing-system : lando
In many places, nsTArray::IndexOf is followed by accessing that element
(hopefully with `Elements() + index`, which skips unnecessary bounds checks.)
But this pattern introduces operations that could be avoided:
- IndexOf converts the address of the found element into an index,
- The caller must test for a special `NoIndex` value,
- On success, accesses convert that index back into the original address.
This patch introduces new 'ApplyIf...' functions that combine all these
operations in a more efficient ensemble: If the sought element is found, it is
passed by reference to a given callable object (usually a lambda); if not
found, another callable is invoked.
Depending on what they need, the first callable may take one of these parameter
lists: (), (size_t), (maybe-const elem_type&), (size_t, maybe-const elem_type&).
On top of removing the pointer->index->pointer operations in most cases,
invoking callables directly from ApplyIf is safer, as the array is guaranteed to
be untouched at this time.
Also, being templates taking function objects, in most cases the compiler should
be able to inline and optimize the search and its callables' code.
This patch gives example uses in nsTArray::Contains, and in
FrameProperties::GetInternal, SetInternal.
And FrameProperties::Has now calls Contains, which is more efficient because
the former code would compute an index (or NoIndex), and then convert that index
to a bool; whereas the new code directly produces a bool from within the search
algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D2758
--HG--
extra : moz-landing-system : lando
When CSS rules change, we usually do this implicitly from FlushUserFontSet & co.
However there's a code path that dirties the stylist but not the CSS rules, and
that's when the compat mode changes and we're an SVG document.
I don't think that can get hit (easily, at least?), but it's pretty easy to do
so and I think this is cleaner too.
This fixes that case so the stylist can't assert in that case either, and so
that we still rebuild the cascade data so that the hash maps use the right keys
for a given quirks-mode.
Differential Revision: https://phabricator.services.mozilla.com/D4361
We usually rely on this call happening soon enough that it doesn't
matter, but from document.write it can matter actually. This is the call that
makes this work the same way as other sheet addition / removals. This would fix
cases where counter styles / @font-face rules in quirk.css wouldn't get
properly updated in some cases. Hopefully we don't have any of those.
Differential Revision: https://phabricator.services.mozilla.com/D4360
We implement the layout part of offset-path. Now we don't have
offset-distance, so use the default value, 0%, for it.
Note: rename mCombinedTransform as mIndividualTransform, which only
stores the combined individual transforms. We apply the individual
transforms, motion path transform, and specified transform in
ReadTransforms. (We have to follow the order, so we don't combine the
specified transform in FinishStyle.)
Differential Revision: https://phabricator.services.mozilla.com/D2968
Use it to implement FindFirstBlock() and FindFirstNonBlock(). This is a
demonstration on how Find() is used. The usage of them will be overhauled in
Part 2 and 3.
Differential Revision: https://phabricator.services.mozilla.com/D3642
We can't call nsWindow::SetSelectionDragState in the child process so
check for the parent process first.
Differential Revision: https://phabricator.services.mozilla.com/D3561
--HG--
extra : moz-landing-system : lando
Prepare for scrollbar-width which should trigger the same kind of change.
MozReview-Commit-ID: 1n9Y9bobBkJ
--HG--
extra : rebase_source : 520b78dec4daca5050e0cc7fff4ec68fa36663c5
Gecko supports resizers of <img> elements and <table>, <td>, <th> elements and
has UI to remove existing table row or column in default. However, the other
browsers don't have such UI and web apps need to disable this feature with
calling both:
document.execCommand("enableObjectResizing", false, false);
document.execCommand("enableInlineTableEditing", false, false);
for avoiding conflicting with their own features to edit such elements.
Therefore, it doesn't make sense to keep enabling them in default only on
Gecko. If web apps want to keep using these features, they should call:
document.execCommand("enableObjectResizing", false, true);
document.execCommand("enableInlineTableEditing", false, true);
at initializing the editor.
And also this patch fixes bugs of
document.queryCommandState("enableObjectResizing") and
document.queryCommandState("enableInlineTableEditing"). They always return
false even after calling document.execCommand(..., false, true) since
nsSetDocumentStateCommand::GetCommandStateParams() sets bool value as
STATE_ATTRIBUTE. However, nsHTMLDocument::QueryCommandValue() which is the
caller referring STATE_ATTRIBUTE doesn't treat it as bool value. And also
those commands are related to state of document. Therefore, they should be
return as bool value of STATE_ALL instead. Then,
nsHTMLDocument::QueryCommandState() returns the state as expected. Note that
those commands are supported only by Gecko. So, we don't need to worry about
the compatibility.
Finally, this patch rewrites 2 existing tests to check basic behavior of
resizers and appearance of resizers.
Note that this patch does not add new tests to test inline table editor
since it's difficult to test the behavior with current API. Perhaps, we
should add an API to nsIHTMLEditor to retrieve each anonymous elements in
another bug since it requires to add wrapping API of SpecialPowers.
MozReview-Commit-ID: 1FhYo5vcV60
--HG--
rename : editor/libeditor/tests/test_objectResizing.html => editor/libeditor/tests/test_resizers_appearance.html
rename : editor/libeditor/tests/test_bug640321.html => editor/libeditor/tests/test_resizers_resizing_elements.html
extra : rebase_source : a707de5a64ef1f8ce974cdf1be093d1b4f61c7bc
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
We force a repaint from ContentStateChangedInternal if visited links are
disabled, and that's observable. Let's cut it off as early as we can to avoid
timing attacks even when :visited is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D3304
Avoid processing anon content in nsCanvasFrame, then getting more anon content
via AccessibleCaretEventHub::Init. Instead call Init before creating the custom
content container. We could also throw a script runner at it I guess, but this
prevents the reentrancy issue.
Avoid cloning nodes during layout, just use the same node (already cloned in
InsertAnonymousContent) instead.
The RemoveChild in GetAnonymousContent to handle the reframes instead of cloning
around is a bit hacky, but I don't think it's really worth extending
PostDestroyData for this special case.
Differential Revision: https://phabricator.services.mozilla.com/D1889
The regressing bug made RepaintSelectionRunner do nothing for any
nsISelectionListener that wasn't a PresShell.
Differential Revision: https://phabricator.services.mozilla.com/D2846
--HG--
extra : moz-landing-system : lando
The basic change here is making nsCSSFrameConstructor::ConstructInline
use the function nsIFrame::IsAbsPosContainingBlock rather than testing
for only one of the conditions in it (being relatively or absolutely
positioned). The rest of the code changes follow from that change.
I tested locally that the added test fails without the patch and passes
with it (either with or without the next patch).
Note that this causes a regression of three web-platform-test reftests:
testing/web-platform/tests/css/css-contain/contain-paint-002.html
testing/web-platform/tests/css/css-contain/contain-paint-011.html
testing/web-platform/tests/css/css-contain/contain-paint-012.html
which will be fixed in patch 4, since that fix is easier to write after
patch 2.
Differential Revision: https://phabricator.services.mozilla.com/D2813
--HG--
extra : rebase_source : 0d374628207c234bcd7cf4e320188994fc2680b8
It's write-only.
Looks like this became unused in bug 501847 when we changed how ib splits work
and no longer needed this information.
Differential Revision: https://phabricator.services.mozilla.com/D2521
MozReview-Commit-ID: GDwcheP3bV4
It was needed presumably because XBL could override the tag name and what not.
But I removed that capability for elements other than XUL elements, so we can
just poke at the content directly.
Differential Revision: https://phabricator.services.mozilla.com/D2520
MozReview-Commit-ID: B5Ihu0gaNd8
Copy over non-rule font faces to the static clone document that is used
during printing.
MozReview-Commit-ID: 8ggNrCcVpEK
--HG--
extra : rebase_source : 27e270edd28c3ecf19a99f4df5398a89e6c53e6a
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
This change also renames several related functions, as well as fields,
and the header is moved into EXPORTS.mozilla given it is defined under
mozilla namespace.
MozReview-Commit-ID: LqCdcW8fmUN
--HG--
rename : layout/base/ScrollbarStyles.cpp => layout/base/ScrollStyles.cpp
rename : layout/base/ScrollbarStyles.h => layout/base/ScrollStyles.h
extra : rebase_source : 8933f3bca88d5db4b9508e3947f695ecf7511b3e
The applying change hints are the same as what we apply for transform style
changed from something to 'none'.
All test cases pass with this fix fail without the fix.
MozReview-Commit-ID: 7HStU26lRPq
--HG--
extra : rebase_source : 701361d477ab7954ab15fde75fd40d98724e47b3
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
It's not needed anymore, since we tag the pseudo-elements at creation time for
styling.
Differential Revision: https://phabricator.services.mozilla.com/D2330
MozReview-Commit-ID: 7j4DVEHXYIC
We verify the flattened tree is correct in VerifyFlatTree (in RestyleManager),
plus the post-condition still holds of course.
Differential Revision: https://phabricator.services.mozilla.com/D2331
MozReview-Commit-ID: 7ayEC2gSvYS
Using references helps to see when stuff can and cannot be null.
I removed useless aTag / aNamespaceId arguments which are useless now that XBL
can't override them (bug 1450617), so FindXULData is the only one that keeps
them alive.
Also, I took the liberty of renaming a few fooComputedStyle variables to just
fooStyle, and clarify naming in some pseudo-element-related functions to say
originating element (the spec term) and avoid confusing it with the generated
_moz_generated_content_before / _moz_generated_content_after element.
Note that this is a partial state, more stuff will come in the future.
Differential Revision: https://phabricator.services.mozilla.com/D2326
MozReview-Commit-ID: 39B30doREUH
Including refactoring mDirtyRoots into nsIPresShell to avoid virtual call.
MozReview-Commit-ID: KxST8FMsZl9
--HG--
extra : rebase_source : 1be1a8065815bb1e67293c7839c6e9189fc693bc
Once we've determined an index for the frame property, we don't need to
pay the overhead of checking whether that index is in bounds for the
array again on the next access. It would be nice if we could avoid that
overhead for removal, too, but since there's no API for that, we'll just
remove the overhead for accesses.
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
NS_STYLE_COLUMN_COUNT_UNLIMITED is unused, so I remove it.
MozReview-Commit-ID: HLHLn9ZbkUY
--HG--
extra : rebase_source : 9bf00e1db00051c4454719e205633717fabde050
Summary:
This fixes a couple fuzz bugs and prevents special-casing <svg:use> even more in
bug 1431255.
Unfortunately not as many hacks went away as I'd have hoped, since we still need
to match document rules, see the linked SVGWG issues.
But blocks_ancestor_combinators goes away, which is nice since it's on a very
hot path.
Test Plan: WPT for style invalidation, covered by existing tests otherwise.
Reviewers: heycam
Tags: #secure-revision
Bug #: 1450250
Differential Revision: https://phabricator.services.mozilla.com/D2154
MozReview-Commit-ID: C4mthjoSNFh
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : ee55a9ae7408e1f2603c1b2bc80ddcd8dbc837f0
The prefs, when enabled, will dump the gecko DL items followed by the
WR DL items that were generated from that gecko item. This allows us to
easily go from a DOM element with known id/class attributes to e.g. an
ImageKey of an image that was generated for that element.
Also, this logging can be enabled in CI builds just like gecko display-list
dumping, instead of the ifdef that we previously had in WebRenderLayerManager.
MozReview-Commit-ID: Eeo4iO62YY1
--HG--
extra : rebase_source : b4a348b2e8bced976489257b966f70b29c56df25
Most of the removed tests are specific to listbox code, some are related to fixes already covered elsewhere, and some have no associated fix and were originally checked in just for good measure.
MozReview-Commit-ID: 3AQXoKy6HhU
--HG--
extra : rebase_source : 88781275bfdb436c0bb4249972435ad74e95002e
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
I also tried to avoid this change but, again, given the number of times I was
repeating the same pattern of defining a static method just to forward a
callback to an instance method, decided it was probably necessary. Without an
easy way to do this, people are more likely to register observers rather than
callbacks, for which we'll wind up paying a continued memory and performance
penalty.
This patch adds a helper which creates a type-safe preference callback
function which forwards calls to an instance method on its closure object.
The implementation is somewhat complicated, mainly due to the constraint that
unregistering a callback requires passing the exact same function pointer that
was used to register it. The patch achieves this by creating the callback
function as a template, with the method pointer as a template parameter. As
long as the Register and Unregister calls happen in the same translation unit,
the same template instance is guaranteed to be used for both.
The main difficulty is that, until C++ 17, there's no way match a value as a
template parameter unless you know its complete type, or can at least compute
its complete type based on earlier template parameters. That means that we
need a macro to extract the type of the method, and construct the template
with the full set of explicit parameters.
MozReview-Commit-ID: 10N3R2SRtPc
--HG--
extra : rebase_source : 7d0a8ddeb77e01d4a6f421459514e93bc0875598
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
Generally there isn't really much difference for painting on html/body
element vs. viewport, so it's probably not worth finer grained control
over when we should propagate and when not.
MozReview-Commit-ID: HK7DsQdz41D
--HG--
extra : rebase_source : 444277648b9b5ee9bc9d14f549b42f4147afbeb3
Such messages happen intermittently on Android, presumably from bfcache being
purged due to memory pressure (which would then cause the back() operation
behave like a fresh load). So on Android, we'll now treat these redundant
messages as a "todo()" failure, to indicate that something went wrong but avoid
turning the testsuite orange.
MozReview-Commit-ID: GkaxB06vL7q
--HG--
extra : rebase_source : 64c0c0a41452d573062774b2300a26aad179b309
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
Lines pulled from next-in-flow or overflow frames have probably not been marked
dirty (as ReflowInput hasn't dealt with them when it was constructed), so we
need to mark them dirty for proper reflow.
If we don't do that, and they don't fit in the current column, the next column
will only mark its current children dirty, so when pulling back its first lines
from the previous column they will not be reflowed as needed, which causes this
bug.
MozReview-Commit-ID: 8GFO1ZWuZ1b
--HG--
extra : rebase_source : 0198b291a1b50441188e050dd5bcb2c06694df81