868404 - Overlay scrollbars appear in hovered state even though they weren't visible before (Gmail chat)

Status: NEW

(Core :: Widget: Cocoa, defect, P3)

Description

[beingalink]

Attachment: Scrollbar_Gmail.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130503 Firefox/23.0
Build ID: 20130503030920

Steps to reproduce:

Slowly move mouse over the chatbox in the bottom left corner of the Gmail website.


Actual results:

Coming from the right side lets appear the old scrollbar style. Coming from the left side and letting a contact popup appear lets the scrollbar appear on top. See attached picture.


Expected results:

Safari shows a custom scrollbar (not the default OS X one).

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Likely fallout from the patch for bug 636564.

Comment 2

[David Corry]

Attachment: Testcase

Webkit does the same thing with a native (non-custom) scrollbar. (See attachment in Chrome or Safari. Top is native, bottom is custom.)

I would argue that the scrollbar should be under the popup, but the way it is now might be the correct behavior.

I couldn't find a similar bug for Webkit or Chromium.

Comment 3

[Stephen A Pohl [:spohl]]

(In reply to beingalink from comment #0)
> Actual results:
> 
> Coming from the right side lets appear the old scrollbar style.

What appears isn't actually the old scrollbar style, but the overlay scrollbar in hovered state. This is still a bug since the scrollbar in hovered state should only appear when the non-hovered scrollbar was visible and the user moved the mouse over the scrollbar, but I'm glad we're not falling back to the old style all together.

> Coming from
> the left side and letting a contact popup appear lets the scrollbar appear
> on top. See attached picture.

Per comment 2 (and from what I could confirm myself), this matches what Webkit is doing for non-custom scrollbars.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this fixed now that we're not using z-index:<bignum> for overlay scrollbars in Web content?

Comment 5

[Stephen A Pohl [:spohl]]

We no longer display scrollbars on top of contacts, but the scrollbar still appears in hovered state immediately when the mouse is moved over the contacts from the right.

In other words, the part of this bug that had to do with setting z-index:<bignum> for overlay scrollbars is fixed.

Comment 6

[Stephen A Pohl [:spohl]]

As soon as we hover over the div for the GMail chat the class property of the div changes. This appears to cause a reframe and we display the scrollbars. They appear in hovered state when coming from the right because the mouse will be over the scrollbars. They appear in their usual form when coming from the top, for example.

This bug is about figuring out how to suppress the call to ScrollbarActivity::ActivityOccurred in this situation and is therefore related (but most likely not identical) to bug 888027 and bug 869519.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Where does the ActivityOccurred call come from? Is nsGfxScrollFrameInner::ScrollToRestoredPosition on the stack?

Comment 8

[Tracy Walker [:tracy]]

Attachment: bug868404.png

see attachment for comparison of latest Nightly (50.0a1, 20160714030208), on left versus Safari, on right displaying the attached testcase from comment #2: custom scroll bar (bottom sample) is displayed correctly by Safari. Nightly displays system default scroll bars.