Closed Bug 888027 Opened 8 years ago Closed 5 years ago

Overlay scrollbars become active when objects "beneath" them are refreshed

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: smichaud, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [lion-scrollbars=][tpi:?])

Attachments

(1 file)

This bug is spun off from bug 870917 comment #15.  It's about the "related problem" reported there.

STR:

1) Open a Firefox window and visit https://www.mozilla.org/en-US/ in it.  Notice that part of the page refreshes every 7-8 seconds.  Also notice that it always has a vertical scrollbar.
2) If you make the page narrow enough, the vertical scrollbar reappears (and then fades out again) every time the page is refreshed.

I assume, but don't yet know for sure, that the kind of "refresh" that happens is a reflow.

Of the platforms that support overlay scrollbars, I've tested on OS X and Android.  I've not yet tested on Windows Metro.

I've tentatively put this bug in Layout, though I don't really know whether it belongs there or in CSS.
I don't know whether this behavior is intentional, but it seems wrong to me.

Safari (on OS X) and Android's built-in "Browser" don't behave this way.  And I think overlay scrollbars should only appear as the result of some kind of user action -- resizing the page, clicking where the scrollbar should be, or scrolling the page by some other means.
Hardware: x86 → All
Whiteboard: [lion-scrollbars=]
At least on OS X, this bug goes away if you make the window wide enough.  It'd be interesting to hear if this is also true on Windows Metra.

(As best I can tell you have only limited control over the window size on Android -- by changing your phone's orientation.  So I can't really perform the test there.  On my phone (a Nexus S), at least, the bug occurs with both orientations.)

I currently have no idea why this happens.  But I suppose it's a clue to this bug's underlying cause.  It also suggests the current behavior isn't intentional.
It would be interesting to know what ActivityOccured is called in response to. It's called in two places in nsGfxScrollFrame.cpp, for changes to different attributes.
(In reply to Markus Stange [:mstange] from comment #3)
> It would be interesting to know what ActivityOccured is called in response
> to. It's called in two places in nsGfxScrollFrame.cpp, for changes to
> different attributes.

#0  mozilla::layout::ScrollbarActivity::ActivityOccurred (this=0x14d02b0e0) at /Users/Stephen/Documents/mozilla-central/layout/generic/ScrollbarActivity.cpp:34
#1  0x0000000101e39570 in nsGfxScrollFrameInner::SetCoordAttribute (this=0x12274e450, aContent=0x14de92a10, aAtom=0x110799a60, aSize=2006) at /Users/Stephen/Documents/mozilla-central/layout/generic/nsGfxScrollFrame.cpp:3910
#2  0x0000000101e3a5c5 in nsGfxScrollFrameInner::FinishReflowForScrollbar (this=0x12274e450, aContent=0x14de92a10, aMinXY=0, aMaxXY=120339, aCurPosXY=0, aPageIncrement=15660, aIncrement=2880) at /Users/Stephen/Documents/mozilla-central/layout/generic/nsGfxScrollFrame.cpp:3559
#3  0x0000000101e3abd7 in nsGfxScrollFrameInner::ReflowFinished (this=0x12274e450) at /Users/Stephen/Documents/mozilla-central/layout/generic/nsGfxScrollFrame.cpp:3640
#4  0x0000000101d4c575 in PresShell::HandlePostedReflowCallbacks (this=0x12273b000, aInterruptible=false) at /Users/Stephen/Documents/mozilla-central/layout/base/nsPresShell.cpp:3702
#5  0x0000000101d45eb1 in PresShell::DidDoReflow (this=0x12273b000, aInterruptible=false, aWasInterrupted=false) at /Users/Stephen/Documents/mozilla-central/layout/base/nsPresShell.cpp:7661
[...]

The content of the page changes every 7-8 seconds. Although the width of the page remains the same, the height changes. We change the nsGkAtoms::maxpos attribute, which in turn makes us call ActivityOccurred() on our ScrollbarActivity object.
Attached patch wipSplinter Review
This wip illustrates how this bug can be avoided. This isn't quite finished yet because the scrollbars don't become visible anymore when the browser window is being resized. There may be other problems that I haven't detected yet.
Stephen, your patch for bug 870917 (present in today's mozilla-central nightly) fixes this bug for me ... at least so far as I can tell.

But in bug 870971 comment #43 you say it doesn't fix this bug for you.

Please give me STR that show this bug still happening with today's mozilla-central nightly.
I followed your STR from comment 1:

1) Open a Firefox window and visit https://www.mozilla.org/en-US/ in it.  Notice that part of the page refreshes every 7-8 seconds.  Also notice that it always has a vertical scrollbar.
2) If you make the page narrow enough, the vertical scrollbar reappears (and then fades out again) every time the page is refreshed.

The problem still exists for me in the latest nightly available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/, i.e.:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20130715 Firefox/25.0
Thanks, Stephen.

I also still see the problem when I make the page *really* narrow.

Sorry for the confusion :-(
Blocks: 868404
Flags: needinfo?(twalker)
Whiteboard: [lion-scrollbars=] → [lion-scrollbars=][tpi:?]
(In reply to Stephen A Pohl [:spohl] from comment #7)

> 1) Open a Firefox window and visit https://www.mozilla.org/en-US/ in it. 
> Notice that part of the page refreshes every 7-8 seconds.  Also notice that
> it always has a vertical scrollbar.
> 2) If you make the page narrow enough, the vertical scrollbar reappears (and
> then fades out again) every time the page is refreshed.
> 

I am unable to reproduce this with latest Nightly 50.0a1 20160714030208 at the page given.  Perhaps that page is no longer refreshing in the same manner as before?
Flags: needinfo?(twalker)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.