Closed Bug 1412272 Opened 7 years ago Closed 7 years ago

Long scrollbar thumb (longer than screen width/height) can get clipped when clicked/dragged

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Version:
56 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla58
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- verified

People

(Reporter: support, Assigned: botond)

References

Details

(Keywords: regression)

Attachments

(4 files)

2017-10-27_bug.swf
2.56 MB, application/x-shockwave-flash
Details
bug.webm
3.19 MB, video/webm
Details
Bug 1412272 - Have ComputePartialPrerenderArea() handle the cases where aDirtyRect is larger than aPrerenderSize.
59 bytes, text/x-review-board-request
mstange
: review+
ritu
: approval-mozilla-beta-
Details
Testcase (from comment 3)
236 bytes, text/html
Details
Attached file 2017-10-27_bug.swf — 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Could you please explain more, and attach a screenshot instead of the Flash file?
Attached video bug.webm — 

    
    

    
  
Hello,

The problem occurs with using several horizontal embedded scrolls. The internal scroll has strange behavior while scrolling (it isn't set to the correct position and moves independently after some time). To reproduce the issue, I used the following page:

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<body>
        <div style="width: 3000px; overflow-x: scroll;">
            <div style="width: 3500px">
                test
            </div>
        </div>
</body>

I also attached the .webm file to demonstrate this behavior.

    
    

    
  
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Firefox: 58.0a1, Build ID 20171031220132

I have managed to reproduce this issue, using the steps provided in the description, on Windows 10 x64, Ubuntu 14.04 x64 and Mac 10.12.6 with the latest Firefox release (56.0.2) and latest Nightly (58.0a1) builds.
Considering this, using the Mozregression tool, I have managed to find a regression window. From the pushlog, it seems that the bug 1359868  has caused this.

Here are the results:
Last good revision: 8178250f3a8b58fbb48f31b0095de2c0d2af802a
First bad revision: ef01a708f156b3a9c8c9f7d46959fe61571a6692
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8178250f3a8b58fbb48f31b0095de2c0d2af802a&tochange=ef01a708f156b3a9c8c9f7d46959fe61571a6692

Botond, can you please take a look at this?
Blocks: 1359868
Status: UNCONFIRMED → NEW

          status-firefox56:
          --- → affected

          status-firefox57:
          --- → affected

          status-firefox58:
          --- → affected
Component: Untriaged → Panning and Zooming
Ever confirmed: true
Flags: needinfo?(botond)
Keywords: regression
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All

    
  
Assignee: nobody → botond
Flags: needinfo?(botond)

    
    

    
  
In bug 1359868, we changed the portion of the scrollbar thumb that is rendered when the thumb is layerized. The intention was to *expand* the rendered portion to cover not just the portion visible on-screen, but also potentially part of any off-screen portion (up to a limit determined by the browser window's size) in anticipation of impending async scrolling.

It looks like, in some cases when the thumb's total size exceeds the limit defined by the browser window's size, our computation sometimes makes a poor choice of *which* portion to render, such that the rendered portion can exclude some of the on-screen portion. This was not the intention - we should always at least render the entire on-screen portion.

    
    

    
  
(In reply to Botond Ballo [:botond] from comment #5)
> It looks like, in some cases when the thumb's total size exceeds the limit
> defined by the browser window's size, our computation sometimes makes a poor
> choice of *which* portion to render, such that the rendered portion can
> exclude some of the on-screen portion. This was not the intention - we
> should always at least render the entire on-screen portion.

Specifically, the thumb's visible region can be larger than the browser window size (due to it being limited by the displayport rather than the viewport), and in cases like this we were choosing the pre-render area by centering a region of the pre-render size over the visible region, oblivious to the fact that this could clip away part of the visible region if the visible region is smaller.

    
    

    
      
  


  

    
    

    
  
(Not posting for review yet. Markus has more important things to review for the time being :)).

    
  
Summary: The horizontal scrollbar position is incorreсt in FireFox. → Long scrollbar thumb (longer than screen width/height) can get clipped when clicked/dragged

    
  

        Attachment #8924272 -
        Flags: review?(mstange)

    
    

    
  
Comment on attachment 8924272 [details]
Bug 1412272 - Have ComputePartialPrerenderArea() handle the cases where aDirtyRect is larger than aPrerenderSize.

https://reviewboard.mozilla.org/r/195494/#review200726

        Attachment #8924272 -
        Flags: review?(mstange) → review+

    
    

    
  
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b17661987940
Have ComputePartialPrerenderArea() handle the cases where aDirtyRect is larger than aPrerenderSize. r=mstange

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/b17661987940
Status: NEW → RESOLVED
Closed: 7 years ago

          status-firefox58:
          affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58

    
    

    
  


  

    
  

        Attachment #8925062 -
        Attachment mime type: text/plain → text/html

    
    

    
  
Comment on attachment 8924272 [details]
Bug 1412272 - Have ComputePartialPrerenderArea() handle the cases where aDirtyRect is larger than aPrerenderSize.

Approval Request Comment
[Feature/Bug causing the regression]:
  Bug 1359868 (regression on release since Firefox 55)

[User impact if declined]:
  When clicking on or dragging a scrollbar whose thumb is 
  longer  than the browser window's width/height (which can 
  occur in some scrollable subframes), the thumb can be 
  rendered incompletely.

  This can confuse users and lead them to believe that the
  browser is not scrolling correctly in response to their
  drag.
  
[Is this code covered by automated tests?]:
  There are some APZ mochitests for APZ scrollbar dragging.
  A test for this specific issue would be tricky to write,
  both because testing scrollbar rendering is tricky in
  general, and because the issue here requires input events 
  to trigger.
  
[Has the fix been verified in Nightly?]:
  Yes.

[Needs manual test from QE? If yes, steps to reproduce]: 
  STR:
    1. Load the test case attached to this bug
    2. Click on the scrollbar thumb of the subframe (near 
       the top of the screen)
  Actual results:
    The thumb gets truncated when you click on it, as if 
    it had moved.
  Expected results:
    The thumb does not get truncated.

[List of other uplifts needed for the feature/fix]:
  None

[Is the change risky?]:
  No.

[Why is the change risky/not risky?]:
  It's a very small, targeted fix. The only codepath it
  affects in a supported configuration concerns the
  rendering of scrollbar thumbs.

[String changes made/needed]:
  None

        Attachment #8924272 -
        Flags: approval-mozilla-beta?

    
    

    
  
Comment on attachment 8924272 [details]
Bug 1412272 - Have ComputePartialPrerenderArea() handle the cases where aDirtyRect is larger than aPrerenderSize.

We've discuss this over email and since this is not a recent regression, it's safer to let this fix ride the 58 train.

        Attachment #8924272 -
        Flags: approval-mozilla-beta? → approval-mozilla-beta-
Flags: qe-verify+

    
    

    
  
I have reproduced this issue using Firefox 58.0a1 (build ID = 20171027220059) on Win 8.1 x64.
I can confirm this issue is fixed, I verified using Firefox 58.0b5 on Win 8.1 x64, Ubuntu 14.04 x64 and Mac OS X 10.12.6.
Status: RESOLVED → VERIFIED

          status-firefox58:
          fixed → verified
Flags: qe-verify+

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: