- 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.
