1359868 - Scrollbar is not painted fully after mouse leaves and reenters Firefox window

Status: RESOLVED FIXED

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

Description

[Botond Ballo [:botond]]

STR:
  1. Run Firefox Nightly
  2. Unmaximize the Firefox window if necessary, and position it
     so that there's space below it.
  3. Load https://bug1355374.bmoattachments.org/attachment.cgi?id=8856856
  4. Grab the subframe's scroll thumb near the top.
  5. Drag it down until mouse leaves the Firefox window, keeping the
     mouse button down.

Once the mouse leaves the Firefox window:
  - the scroll thumb "jumps" up to an incorrect position
  - the scroll thumb is ony partially painted

This is a regression from APZ scrollbar dragging.

Comment 1

[Botond Ballo [:botond]]

(First reported in bug 1355374 comment 26.)

Comment 2

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #0)
> Once the mouse leaves the Firefox window:
>   - the scroll thumb "jumps" up to an incorrect position

This part no longer happens with the fix for bug 1355374.

Revised STR:

  1. Steps 1 through 5 from above.
  2. Drag the thumb back up to its original position.

When you drag it back up, the thumb is only partially painted. Specifically, it seems to be painted only up to the point where you grabbed it.

Comment 3

[Botond Ballo [:botond]]

I initially thought that this bug involved something particular to the mouse leaving the Firefox window, but it turns out the cause is a bit more obvious. *Any* time the scroll thumb is partially or fully offscreen and the main thread repaints it, the painted area is clipped to the on-screen portion. If we then subsequently get frames of an async drag without another main thread repaint to paint the entire thumb, we get this incomplete-rendering bug.

The issue isn't specific to scrollbar dragging - you can see it with other forms of async scrolling as well. For example, here is STR for mousewheel scrolling:

  1. Load https://bug1355374.bmoattachments.org/attachment.cgi?id=8856856
     No need to have the Firefox window unmaximized this time.
  2. Scroll the subframe (by any means) such that the thumb is partially
     offscreen.
  3. Click on the onscreen portion of the thumb, to force a main thread
     repaint.
  4. Mousewheel-scroll the subframe up so the thumb moves up.
     For a few frames, only the portion of the thumb that was previously
     onscreen is painted.

Comment 4

[Botond Ballo [:botond]]

The fix approach I'm going to explore is to have the main thread paint the entire thumb when it's layerized, limited to the viewport's height (we do still need a limit since thumbs of subframes can have arbitrarily large height). This won't make "checkerboarding" of the thumb impossible, but it will make it much less likely to happen in practice.

Comment 5

[Botond Ballo [:botond]]

Attachment: Bug 1359868 - Move the ComputePartialPrerenderArea() helper to nsLayoutUtils so it can be reused.

Review commit: https://reviewboard.mozilla.org/r/135310/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/135310/

Comment 6

[Botond Ballo [:botond]]

Attachment: Bug 1359868 - Try to pre-render offscreen portions of scrollbar thumbs.

Review commit: https://reviewboard.mozilla.org/r/135312/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/135312/

Comment 7

[Botond Ballo [:botond]]

Markus, thanks for pointing out the similarity to partial prerendering of transformed content. It turned out, reusing some of the code from that for this was quite convenient!

Comment 8

[Markus Stange [:mstange]]

Comment on attachment 8863540 [details]
Bug 1359868 - Move the ComputePartialPrerenderArea() helper to nsLayoutUtils so it can be reused.

https://reviewboard.mozilla.org/r/135310/#review138652

Comment 9

[Markus Stange [:mstange]]

Comment on attachment 8863541 [details]
Bug 1359868 - Try to pre-render offscreen portions of scrollbar thumbs.

https://reviewboard.mozilla.org/r/135312/#review138654

Looks good to me. I had forgotten that we already manually adjust the dirty rect of the scrollbar thumb, so this patch ended up being delightfully simple.

Comment 10

[Botond Ballo [:botond]]

Comment on attachment 8863540 [details]
Bug 1359868 - Move the ComputePartialPrerenderArea() helper to nsLayoutUtils so it can be reused.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/135310/diff/1-2/

Comment 11

[Botond Ballo [:botond]]

Comment on attachment 8863541 [details]
Bug 1359868 - Try to pre-render offscreen portions of scrollbar thumbs.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/135312/diff/1-2/

Comment 12

[Botond Ballo [:botond]]

Thanks! Updated to fix some typos and autolanded.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b032fab4ab6
Move the ComputePartialPrerenderArea() helper to nsLayoutUtils so it can be reused. r=mstange
https://hg.mozilla.org/integration/autoland/rev/9c7f749e9015
Try to pre-render offscreen portions of scrollbar thumbs. r=mstange

Comment 14

[Iris Hsiao [:ihsiao]]

https://hg.mozilla.org/mozilla-central/rev/6b032fab4ab6
https://hg.mozilla.org/mozilla-central/rev/9c7f749e9015

Comment 15

[ovidiu boca[:Ovidiu]]

Attachment: Recording #33.mp4

I verified this bug on Mac OS X 10.10 and if you grab the scrollbar and move it to the lower end of the page and then up again, the scrollbar is not fully repainted. To be able to see this issue don't click on "Append".

Also if I use my mouse wheel to move the scrollbar when that is in focus a repainting issue occurs. Please see the video.

Comment 16

[Botond Ballo [:botond]]

(In reply to ovidiu boca[:Ovidiu] from comment #15)
> Created attachment 8865423 [details]
> Recording #33.mp4
> 
> I verified this bug on Mac OS X 10.10 and if you grab the scrollbar and move
> it to the lower end of the page and then up again, the scrollbar is not
> fully repainted. To be able to see this issue don't click on "Append".
> 
> Also if I use my mouse wheel to move the scrollbar when that is in focus a
> repainting issue occurs. Please see the video.

I assume you also tried on Windows, and the issue was fixed there?

Comment 17

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #16)
> I assume you also tried on Windows, and the issue was fixed there?

Never mind. I was able to reproduce this issue, and it's not platform-specific. I filed bug 1363219 for it and will handle it there.

Thanks for catching this, Ovidiu!

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Backed out to see if this caused the checkerboarding regression in bug 1362987: https://hg.mozilla.org/integration/mozilla-inbound/rev/310707ea9db8332c499ed0b3716125094b026c2e

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6e2858fb7826
Move the ComputePartialPrerenderArea() helper to nsLayoutUtils so it can be reused. r=mstange
https://hg.mozilla.org/integration/mozilla-inbound/rev/ef01a708f156
Try to pre-render offscreen portions of scrollbar thumbs. r=mstange

Comment 20

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/6e2858fb7826
https://hg.mozilla.org/mozilla-central/rev/ef01a708f156

Comment 21

[ovidiu boca[:Ovidiu]]

Attachment: Recording #36.mp4

I tested this with the latest Nightly 55.0a1 (2017-05-15) and if you zoom in the browser and move the scrollbar, the issue is still there. Please see the video.

Comment 22

[Botond Ballo [:botond]]

(In reply to ovidiu boca[:Ovidiu] from comment #21)
> I tested this with the latest Nightly 55.0a1 (2017-05-15) and if you zoom in
> the browser and move the scrollbar, the issue is still there. Please see the
> video.

The issue depicted in the video is fixed by the patch in bug 1363219.

Comment 23

[ovidiu boca[:Ovidiu]]

I used this test case http://jsbin.com/ropiranayi/edit?html,output and I'm still able to reproduce the painting problem. Tested on Mac OS X 10.10 FF Nightly 55.0a1(2017-05-22)

Comment 24

[Botond Ballo [:botond]]

(In reply to ovidiu boca[:Ovidiu] PTO until 06.06.2017 for any issues please contact [e-mail] from comment #23)
> I used this test case http://jsbin.com/ropiranayi/edit?html,output and I'm
> still able to reproduce the painting problem. Tested on Mac OS X 10.10 FF
> Nightly 55.0a1(2017-05-22)

Thanks. I can reproduce the issue in JSBin, but not when testing the page by itself. The issue seems to be related to the fact that on JSBin, the page content is wrapped in an <iframe>. I filed bug 1367488 with a reduced testcase using an <iframe> that demonstrates the issue.

Comment 25

[ovidiu boca[:Ovidiu]]

I tested again this issue with FF Nightly 56.0a1(2017-07-03) on Windows 10 x64 and I can still reproduce it. Botond, what are the plans for this? Thanks

Comment 26

[Botond Ballo [:botond]]

(In reply to ovidiu boca[:Ovidiu] from comment #25)
> I tested again this issue with FF Nightly 56.0a1(2017-07-03) on Windows 10
> x64 and I can still reproduce it. Botond, what are the plans for this? Thanks

I assume you're talking about the test case mentioned in comment 23, for which the behaviour was fixed in bug 1367488. It does look like the behaviour of that test case has regressed since then - thanks for catching that! I filed bug 1378455 to track that regression.

Comment 27

[ovidiu boca[:Ovidiu]]

I can't reproduce the scenario from the description so then I will mark this as Verified Fixed.

Tested on Mac OS X 10.10, Windows 10x64 and Ubuntu 16.04 with FF Nightly 56.0a1(2017-07-12) and FF beta 55.0b8 and I can confirm the fix. Thanks Botond for bug 1378455.