Open Bug 1363341 Opened 8 years ago Updated 2 years ago

Investigate if we need to flush when scrolling trees after bug 1334635

Categories

(Core :: XUL, defect, P5)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: enndeakin, Unassigned)

References

Details

See comment 10 of bug 1334635 for details, copied here: It's called by nsTreeBodyFrame::FullScrollbarsUpdate() via nsOverflowChecker. If there is no script blocker, flushing the layout synchronously. nsTreeBodyFrame::FullScrollbarsUpdate() is called by nsTreeBodyFrame::EnsureView() via nsTreeBodyFrame::SetView(), after that it tries to update scroll position to show the selected item. However, if there is pending reflow, I'm not sure if this works as expected because gfxScrollFrame tries to clamp the scroll destination into current range. http://searchfox.org/mozilla-central/rev/72fe012899a1b27d34838ab463ad1ae5b116d76b/layout/generic/nsGfxScrollFrame.cpp#2242,2255-2256
See Also: → 1334635
status-firefox56: --- → wontfix
status-firefox57: --- → wontfix
status-firefox58: --- → fix-optional
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.