Closed Bug 1363219 Opened 3 years ago Closed 2 years ago

Scrollbar thumb can still be cut off after being offscreen

Categories

(Core :: Panning and Zooming, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: botond, Assigned: botond)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files)

STR:
  1. Load https://bug1355374.bmoattachments.org/attachment.cgi?id=8856856
  2. Resize the Firefox window so that the space above the grey div is
     (vertically) smaller than the visible portion of the div.
  3. Grab the div's scroll thumb near the top.
  4. Drag it down as far as you can (mouse near bottom of screen),
     and then back up.

When you drag the thumb back up, the bottom part can be cut off (i.e. not fully painted). Unlike bug 1359868, the cutoff doesn't happen at the point where you grabbed the thumb, but further down.

Originally reported by Ovidiu in bug 1359868 comment 15.
See Also: → 1359868
The fix we applied in bug 1359868 is helping (that's why the thumb isn't cut off at the point where you grabbed it, only further down), but not enough.

The problem is that we bound the region we paint by the size of the browser window's content area, but we apply this bound to the entire scrollbar, not just the thumb. In the affected scenario, the scrollbar's total height is larger than the browser window (half of the div is offscreen, so the scrollbar is twice as high as the visible part of the div), so we limit how much of it we paint to that much, and in this process we cut off part of the thumb.

What we really want to do, is apply the bound to the thumb only, so as long as the thumb itself is not taller than the browser window, we paint the whole thing.
Priority: -- → P3
Whiteboard: [gfx-noted]
Comment on attachment 8865679 [details]
Bug 1363219 - Try harder to pre-render offscreen portions of scrollbar thumbs.

https://reviewboard.mozilla.org/r/137312/#review141260
Attachment #8865679 - Flags: review?(mstange) → review+
The patch has a code dependency on bug 1359868, so it needs to wait for that bug to reland.
Depends on: 1359868
(In reply to Botond Ballo [:botond] from comment #5)
> The patch has a code dependency on bug 1359868, so it needs to wait for that
> bug to reland.

Bug 1359868 has now relanded, and is expected to stick (since it has been cleared of causing the regression in bug 1362987), so this is good to land now.
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

hg error in cmd: hg rebase -s 56d5b360c8e7 -d 79c28571253b: rebasing 396259:56d5b360c8e7 "Bug 1363219 - Try harder to pre-render offscreen portions of scrollbar thumbs. r=mstange" (tip)
merging layout/generic/nsGfxScrollFrame.cpp
merging layout/xul/nsSliderFrame.cpp
warning: conflicts while merging layout/xul/nsSliderFrame.cpp! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f74ec590a534
Try harder to pre-render offscreen portions of scrollbar thumbs. r=mstange
https://hg.mozilla.org/mozilla-central/rev/f74ec590a534
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Blocks: 1367488

I tested this on Mac OS X 10.10 and Windows 10 x64 with FF beta 55.0b8 and I can't reproduce the issue.

On Nightly 56.0a1(2017-07-12) on the same OSes, but zoom in the page to 300% I can reproduce the issue. On Mac, the scrollbar is repainted with delay and on Windows, I see a flicker. 

Botond please tell your opinion, thanks.
Flags: needinfo?(botond)
(In reply to ovidiu boca[:Ovidiu] from comment #12)
> 
> I tested this on Mac OS X 10.10 and Windows 10 x64 with FF beta 55.0b8 and I
> can't reproduce the issue.
> 
> On Nightly 56.0a1(2017-07-12) on the same OSes, but zoom in the page to 300%
> I can reproduce the issue. On Mac, the scrollbar is repainted with delay and
> on Windows, I see a flicker. 

At 300% zoom, I cannot fit the scrollable div on my screen well enough to effectively perform the STR. I tried at 200% zoom, and I couldn't see any delay or flicker. I was testing on Linux; I will test also on Windows on Friday when I am near a Windows machine. Leaving needinfo until then.
Attached video 300%bug.mp4
Please see the attached video. Tested with FF 55.0b10 on Mac OS 10.10
(In reply to ovidiu boca[:Ovidiu] from comment #14)
> Created attachment 8888179 [details]
> 300%bug.mp4
> 
> Please see the attached video. Tested with FF 55.0b10 on Mac OS 10.10

Thanks for the video - I understand what's going on now. With the page zoomed in this much, the height of the scrollbar thumb is larger than the height of the browser window, and we limit how much of the thumb we render to the height of the browser window. We do this because there needs to be *some* limit (thumbs can get arbitrarily long as the viewport size of their scroll frame gets larger), and the browser window's height seemed like a reasonable limit that should be sufficient for the vast majority of use cases.

So, the behaviour you are seeing is expected. I think users will run into it very rarely if at all, and thus it's not worth trying to change the limit, although if you run into this issue on a real website with a realistic zoom level, we can re-evaluate.
Flags: needinfo?(botond)
You need to log in before you can comment on or make changes to this bug.