When our flexibilities sum to a fraction < 1, we clamp the free space to be no
greater than that same fraction of the original free space. This effectively
makes us treat a flexibility of e.g. "0.01" as "1% of the original free space"
in that sort of situation (while still treating it as a normal flex factor if
the sum of the flex factors is greater than 1).
The phrase "flex weight" used to be a term defined in the spec, but it's
long-since been replaced with "flex factor" and "scaled flex factor".
I'm now using the term "weight" to mean "flex factor, with any necessary scaling already done, ready to be used as a weight for apportioning free space".
I'm dropping the "flex" modifier from "flex weight" both for brevity & to make
it more clearly-distinguishable from actual "flex factor" usages in the code.
Also NotifyRenderingChanged was on the canvas background color item, not the background image item.
Bug 818643 was a problem where the cache didn't get purged enough, but the fix meant we basically always purged the cached and never got to use it, making it useless. It meant that we purged the cache anytime the item has any type of invalidation whatsoever, even if the item would be drawn the same but the layer contents needed to be invalidated so that it would be redrawn (ie due to staying at the same position on screen but a different position in the layer).
This is really hacky, but NotifyRenderingChanged is only observed on one type of display item. So we just isolate the case where the only thing that changed is the offset (due to scrolling) and skip the NotifyRenderingChanged in that case.
- The condition described in the FIXME comment is already handled by
GetNearestBlockContainer in nsFrame.cpp (helper for
nsIFrame::GetContainingBlock).
The bug that this test was intended to test seems transient, according to
testing with nightlies around the time the bug was filed. Additionally,
the test connects to external servers, which is frowned upon and will soon
be forbidden.
- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED),
the overflow areas of the children have changed and the parent have changed
(CHILDREN_AND_PARENT_CHANGED), or if only the transform has changed
(TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
Bug 926292 accidentally put them in the background list if there were no positioned descendents they needed to be on top of it (because this was where non-overlay scrollbars went, which never made sense). If there are no positioned descendents overlay scrollbars should go on the top-most non-positioned list, which is outlines.
This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED) or
if the transform has changed (TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
Bug 926292 accidentally put them in the background list if there were no positioned descendents that they needed to be on top of it (because this was where non-overlay scrollbars went, which never made sense). If there are no positioned descendents overlay scrollbars should go on the top-most non-positioned list, which is outlines for the current implementation.
Bug 926292 accidentally put them in the background list if there were no positioned descendents that they needed to be on top of it (because this was where non-overlay scrollbars went, which never made sense). If there are no positioned descendents overlay scrollbars should go on the top-most non-positioned list, which is outlines for the current implementation.
This should be backed out for two reasons:
(1) It caused a serious regression with bullets from list-style-image,
which no longer affect the line box height and thus overlap.
(2) The dependency on 'line-height: normal' doesn't make sense; there's
no reason for whether line-height is 'normal' or not to affect the
behavior of bullets.
I don't currently have time to figure out why Gecko behavior differs
from other browsers on bug 942017, but that should be re-analyzed and
the bug fixed in a different way. At first glance, the code should
already be leading to the expected behavior, since the bullet ought to
have the same metrics and alignment as the block's influence on the line
box's height. Why this isn't the case should be investigated.
It would be incorrect to occlude async scrolled content.
Instead of doing a lot of extra frame tree walking just use the flags on display items to tell if they are in fixed position subtrees.
Also, don't let the fixed position flag on display items get set if we start building display items inside a subdocument. If didn't do this non-fixed content in a subdocument that is in fixed content in the parent document would be marked as in fixed position, and no occlusion would occur at all. This means that the fix applies to slightly less cases which are less important so that a more important case works the same as before.
