Closed Bug 1156450 Opened 9 years ago Closed 8 years ago

Cannot scroll with scrollbar

Categories

(Core :: Layout, defect)

25 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- verified
firefox-esr31 --- wontfix
firefox-esr38 --- wontfix
firefox-esr45 --- affected

People

(Reporter: alice0775, Assigned: tnikkel)

References

()

Details

(Keywords: regression, Whiteboard: [parity-chrome][parity-IE])

Attachments

(2 files)

Attached file reduced html
Cannot scroll by dragging thumb.
Cannot scroll by clicking uparrow scroll button.
However, can scroll by clicking downparrow scroll button and mouse wheel.

IE11 and Chrome42 works as expected.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=770b97caaaba&tochange=5d56f5be9d3f

Regressed by: 
f8bf18dceb1c	Stephen Pohl — Bug 891136: Set pointer-events:auto CSS rule for overlay scrollbars to help make them work on sites such as Google Docs. r=roc
Whiteboard: [ → [parity-chrome][parity-IE]
Flags: needinfo?(spohl.mozilla.bugs)
This appears to affect both Windows and OSX. For Windows, we could simply change things so that "pointer-events: auto"[1] is only set for |@media all and (-moz-overlay-scrollbars)|. For OSX however, we will need to dynamically set this based on the type of scrollbars used to accommodate switching between the two types.

Unfortunately, I don't expect to have time to work on this anytime soon. Maybe this is straightforward for either Markus or Timothy?

[1] http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/xulscrollbars.css#19
Flags: needinfo?(tnikkel)
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(mstange)
Stephen, can you explain how pointer-events:auto on the scrollbars causes this bug?
Flags: needinfo?(mstange) → needinfo?(spohl.mozilla.bugs)
No, I don't have a good explanation at this point, sorry.
Flags: needinfo?(spohl.mozilla.bugs)
The div#container element (the only one on the page that's scrollable, including the root) doesn't even have an pointer-events style that apply to it. The sibling element <header> has a pointer-event style. So it's not at all clear to me how a change to the scrollbar pointer-events style would be affected by the presence of another unrelated element on the page having a pointer-events style. So we need to understand exactly whats going on here.
Flags: needinfo?(tnikkel)
tnikkel, what are the next steps here?
Flags: needinfo?(tnikkel)
The scrollable div (note, note the root scrollable frame, from the body or html element) is underneath the header element, the header element is position fixed and covers the whole page, and it has pointer-events: none. It contains a nav element, with opacity: 0 (so it's not visible) and overflow: scroll (so it has both scrollbars). Making scrollbars pointer-events: auto means that the scrollbars of the nav element consume the clicks, since they are on top of the scrollbars for the scrollable div (opacity: 0 things still consume events). Before bug 891136 they inherited pointer-events: none.

The testcase actually behaves the same in Firefox and Safari, but "works" in Chrome.

I also tried a simple scrollable div with and without pointer-events: none. Safari and Chrome also differed on whether this made the scrollbars of the scrollable div clickable or not.

I went back to bug 891136 and read through it. From what I can gather google docs had scrolled content on top of a scrollable container that provided the scrollbars. When no room was reserved for classic scrollbars (when we have overlay scrollbars) this meant that the scrolled content went on top of the overlay scrollbars. The solution that was devised was for google to move the scrollable container on top of the scrolled content, and add pointer-events: none to the scrollable container so that clicks would pass through it to the scrolled content. Then we would add pointer-events: auto to overlay scrollbars so they still responded to clicks.

Inspecting google docs today, Google does not seem to have made the changes from this plan (did we ever contact them communicating our plan? it's not clear from teh bug). Google has made changes to google docs though. They now reserve space for the scrollbars using elements called "native-scrollbar". These elements also serve to draw the scrollbars, they are just the width of the scrollbars, and don't overlap the scrolled content.

So it seems to me that the original reason (google docs) for adding pointer-events: auto to scrollbars is not needed (and never was) as google docs went with a different solution. So the only question is, did any other sites quietly start depending on this behaviour since bug 891136 landed? I don't know if there is any way to answer that question other than removing the change and seeing what breaks. The behaviour of pointer-events and scrollbars doesn't even seemed to be settled among webkit and chromium, so sites can't be depending on it unless they are doing browser specific hacks. However, since this bug was filed almost 2 years after the regressing bug, I don't have much confidence that this is something we will be able to catch before during the normal 3 * 6 weeks release train process :(.

Any thoughts Stephen?
Flags: needinfo?(tnikkel) → needinfo?(spohl.mozilla.bugs)
(In reply to Timothy Nikkel (:tnikkel) from comment #6)
> Any thoughts Stephen?

I've relied heavily on :roc's expertise when it came to the specifics of bug 891136. I do see that Google Docs seems to have taken a different approach, so backing out bug 891136 and seeing if Google Docs still works seems like a sensible first step. If that holds up, backing out bug 891136 permanently should at least get fair consideration.
Flags: needinfo?(spohl.mozilla.bugs)
Jet, can you find someone to help sort this one out?
Flags: needinfo?(bugs)
(In reply to Timothy Nikkel (:tnikkel) from comment #6)
> So it seems to me that the original reason (google docs) for adding
> pointer-events: auto to scrollbars is not needed (and never was) as google
> docs went with a different solution. So the only question is, did any other
> sites quietly start depending on this behaviour since bug 891136 landed? I
> don't know if there is any way to answer that question other than removing
> the change and seeing what breaks.

I think this is what we need to do. Timothy, do you want to do it?
Assignee: nobody → tnikkel
Flags: needinfo?(bugs)
Attachment #8735614 - Flags: review?(mstange)
Attachment #8735614 - Flags: review?(mstange) → review+
https://hg.mozilla.org/mozilla-central/rev/637e6dce9a3f
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Depends on: 1265807
QA Whiteboard: [good first verify]
I have reproduced this bug with Nightly 40.0a1 (2015-04-20) on Windows 7, 64 Bit.

The bug's fix is verified on Latest Beta 48.0b6.

Build ID 	20160706215822
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
QA Whiteboard: [good first verify] → [good first verify][testday-20160708]
I've managed to reproduce this bug on Nightly 40.0a1 (2015-04-20) ; (Build ID: 20150420030204) on Linux, 64 Bit.

This Bug is now verified as fixed on Latest Firefox Beta 48.0b6

Build ID: 20160706215822
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
QA Whiteboard: [good first verify][testday-20160708] → [good first verify]
As it verified on both windows (comment 13) and Linux (comment 14) marking this as verified
Status: RESOLVED → VERIFIED
Depends on: 1313013
You need to log in before you can comment on or make changes to this bug.