This fixes the failure of
layout/reftests/pagination/dynamic-abspos-overflow-01-cols.xhtml with
the primary patch in bug 1308876.
Since it is an independently testable failure, I'm posting it as a
separate bug.
Without the patch, both reftests fail to rewrap in response to the
dynamic change, and the inner dark blue absolutely positioned element
remains wrapped at the wrong position when the inner light blue
relatively positioned element rewraps. (I tested this only outside of
the reftest harness, but that should be sufficient.)
I verified manually that the height conditions were correct by modifying
both reftests to add some padding and border to #relpos and margin to
#abspos, changing the height of #abspos so that it was either exactly at
or just above the threshold where reflow was needed, and using
GECKO_DISPLAY_REFLOW_RULES_FILE debugging to verify that the reflow of
the absolutely positioned element did or didn't happen as expected.
MozReview-Commit-ID: 6ISgSEYyMiN
--HG--
extra : transplant_source : %93%86%8Csr_L%83%F2OJ%DC%7F%3D%7D%BC%9C%A6%1F0
Functions like BuildDisplayListForStackingContext or BuildDisplayListForChild look
up EffectSet property several times in callees, such as IsTransformed() or
HasOpacity(), which is time wasting.
We should look up EffectSet just once, and pass the found one to all callees
that need it.
MozReview-Commit-ID: GZywm2UcpU7
--HG--
extra : rebase_source : 21f5dd0076a90d876a6df35eee2b886844b44f0a
This patch aims to speed up the lookup and storage of DisplayItemData objects, by removing a level of indirection and preventing the previously required hashtable lookup in order to access these. Instead it stores an array of pointers on each frame that allows direct access to the DisplayItemData object by dereferencing the frame. Since most frames get either 1 or 2 DisplayItemData objects attached to them a specialized class is used that is of minimal size (2 * sizeof(void)) and that performs well for sizes 1 or 2.
MozReview-Commit-ID: HONKAmpk5H8
This fixes an inconsistency in part 2 (32faa7c639ff), which wrote the
constant for uninitialized in two different ways.
The constructor uses nscoord_MIN for uninitialized, and that's also what
GetFloatEdges tests for, so this should use nscoord_MIN as well.
I believe this is because the review comment in comment 29 was only
partially addressed.
I noticed the difference because it caused broken behavior in a tree
with my patch for bug 1227493, which defines NS_INTRINSIC_WIDTH_UNKNOWN
differently. Some text was disappearing on github (email and website
on user pages), slack (usernames of private chats in the sidebar), and
twitter (username of user who tweeted a quoted tweet).
MozReview-Commit-ID: Ah9FUPf2dw4
--HG--
extra : rebase_source : 2d947e017647bc6d6029169ef57cddca5aa4f3a9
Instead of hardcoding a color-to-compare, compare the contrast between
the text and the background color v.s. text and the alternative
background color, and use the color that has better contrast.
MozReview-Commit-ID: D90047Y0Xst
--HG--
extra : rebase_source : cc0bd290930dbb11f464aa434b7606bab268627a
This change does the following:
* Introduce a new smart pointer called CounterStylePtr which either
holds an AnonymousCounterStyle strongly, or a named CounterStyle
managed by CounterStyleManager weakly, and use it to replace all
RefPtr<CounterStyle> around the codebase.
* Rename CounterStyleManager::mCacheTable to mStyles to reflect the
fact that it is used to manage all styles, not just for caching.
* Add a retired styles list which collect all named CounterStyle
evicted from mStyles, and post a PostRefreshObserver to destroy
objects in that list after next flush.
* Remove helper functions for counter style in nsStyleList and expose
mCounterStyle directly, to make code simpler with the new pointer.
Reason for adding a new smart pointer type rather than making their
AddRef/Release behave like BuiltinCounterStyle is that, it is possible
that after a flush, some stale style structs may still be alive. They
can contain pointer to destroyed CounterStyle objects. Although the
actual content may never be accessed anymore, RefPtr may still access
the object for refcounting during destruction.
MozReview-Commit-ID: xxegwSDhNb
--HG--
extra : rebase_source : bb5443f0eb56eee51cbdfd08e0400335648610e8
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This uses the StackingContextHelper and typed helper functions in
WebRenderLayer to simplify WebRenderTextLayer::RenderLayer. It also
removes the implicit assumption in WebRenderTextLayer that the parent
layer pushed a stacking context, which is an assumption we will
probably break in the future.
MozReview-Commit-ID: CARoGVQd56i
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
This restores the code to what it was doing prior to bug 1360241 (where
the else to add to mWildRules was an else of a test of fType), but then
removes the unnecesary null-check on the result of GetFrameTypeInfo.
MozReview-Commit-ID: EOPumJoKrIs
--HG--
extra : transplant_source : %E4%C8%A7%21%98%FAx%C7%1E%A5%0D%B5-%C5%BA%80%D4%1C%A8M
Mats Palmgren
Wes Kocher
Jonathan Kew
Carsten "Tomcat" Book
Phil Ringnalda
L. David Baron
Hiroyuki Ikezoe
Kartikaya Gupta
cku
Bas Schouten
Alexis Beingessner
Ethan Lin
Morris Tseng
Iris Hsiao
Timothy Guan-tin Chien
Cameron McCormack
Xidorn Quan
Sebastian Hengst