Lion-style scrollbars are not displayed on Google Docs

VERIFIED FIXED in Firefox 24

Status

()

Core
Widget: Cocoa
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: akeybl, Assigned: spohl)

Tracking

({reproducible})

Trunk
mozilla25
All
Mac OS X
reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox22 unaffected, firefox23 disabled, firefox24+ verified, firefox25+ verified)

Details

(Whiteboard: [lion-scrollbars=])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
STR:
1) Go to https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AmStZDZgJbV7dDhtMDZlQmRtdDB4a1plZXRwNXIzYWc#gid=0
2) Try to scroll horizontally or vertically

Expected:
Lion style scrollbars (or legacy scrollbars) are displayed.

Actual:
No scrollbars are displayed
(Assignee)

Updated

5 years ago
Whiteboard: [lion-scrollbars=]
(Reporter)

Comment 1

5 years ago
This is FF23 (Beta) specific fyi.
This is also about being unable to scroll, right? Or am I wrong?
(Assignee)

Comment 3

5 years ago
I find that scrolling is still possible, but it may take a few tries (i.e. scrolling feels delayed). It's definitely not as smooth as it used to be.

The overlay scrollbars are actually visible when scrolling all the way to the right. They seem to slide under the spreadsheet, but become visible when scrolling past the spreadsheet and over the grey background.
Since we determined this is an evangelism issue and have done outreach to Google, this isn't a trackable issue for blocking release.
tracking-firefox23: ? → ---
(Assignee)

Updated

5 years ago
Depends on: 896443
The Google docs case is tough.

#0-grid-container is position:relative z-index:0. It contains .grid-table-container (containing the cells) which is position:relative z-index:3, and .scroll-container which is position:absolute z-index:1. So it makes sense that the cells are positioned over the scrollbars. Given this DOM setup, there is no way, using CSS, to make the scrollbars float over the cells.

It looks like script is responsible for sizing and clipping .grid-table-container to fit inside the scrollable part of .scroll-container, which is why the scrollbars are normally visible. So the basic problem here is that Google Docs expects us to allocate room for the scrollbars and relies on that for the scrollbars to be visible.

Stephen, it would be interesting to try Safari to see if the DOM setup for Google Docs is the same there, or whether Google are doing something special to handle Safari.

Given this setup, I can see a few options:
1) Rely on Google changing their behavior.
2) Turn off overlay scrollbars for elements where Web content could be relying on the scrollbars having some size to make them visible. This would probably mean enabling overlay scrollbars for viewport scrolling, and for built-in controls such as textareas and listboxes, but disabling them for other content (e.g. arbitrary scrollable DIVs).
3) Do some crazy hack so that overlay scrollbars appear on top of all other content (unless they're in a CSS transform or CSS opacity group or some other forced-stacking-context). This would be quite difficult, and would also be risky since there would be cases where the scrollbars would appear on top of content we probably think they should not be on top of.
(Assignee)

Comment 6

5 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) 
> Stephen, it would be interesting to try Safari to see if the DOM setup for
> Google Docs is the same there, or whether Google are doing something special
> to handle Safari.

Google Docs is displaying custom, permanently visible scrollbars in Safari and I do see -webkit-scrollbar-track being used in the source. Before using custom scrollbars, Google Docs may have run into the same problem with overlay scrollbars in Safari. We have bug 77790 open, which seems to track a similar feature in Gecko.

> Given this setup, I can see a few options:
> 1) Rely on Google changing their behavior.
> 2) Turn off overlay scrollbars for elements where Web content could be
> relying on the scrollbars having some size to make them visible. This would
> probably mean enabling overlay scrollbars for viewport scrolling, and for
> built-in controls such as textareas and listboxes, but disabling them for
> other content (e.g. arbitrary scrollable DIVs).
> 3) Do some crazy hack so that overlay scrollbars appear on top of all other
> content (unless they're in a CSS transform or CSS opacity group or some
> other forced-stacking-context). This would be quite difficult, and would
> also be risky since there would be cases where the scrollbars would appear
> on top of content we probably think they should not be on top of.

There may be one more option: Since bug 77790 has been open for quite a long time it may not be reasonable to expect this to be fixed for when we release overlay scrollbars. But maybe we can expose a different CSS attribute that allows containers to explicitly fall back to permanently visible scrollbars without further customizations? Something like -moz-non-disappearing-scrollbars? If that's a reasonable workaround and as far as I can tell, it should be fairly straightforward to make scrollable frames behave correctly. Even both types of scrollbars should be possible on the same page without conflicts.
Interesting idea. I'd classify that as a sub-case of part 1 since we'd still be relying on Google Docs changing to use this new behavior.

But if Google Docs is going to change, why wouldn't they just change to put their scrollbars above the cells so disappearing scrollbars work properly? Naively, it seems to me that's no more work than adding a custom CSS property, and it would lead to a better result.
Another option would be 4) do a crazy heuristic hack to disable overlay scrollbars for the Google Docs situation --- a scrollable block containing a single, empty scrollable block.

It would be very useful to know, now that bug 896443 is fixed, what (if any) sites other than Google Docs spreadsheets are still broken.
Hmm, while composing a message to Google I realized that you can't just raise the z-index of the element with the scrollbars, because then the scrollable element would cover the cells and you wouldn't be able to click on the cells.

Stephen, could you try adding "pointer-events:auto" to the scrollbar rule in scrollbars.css, and then open a spreadsheet, and on .scroll-container set z-index to 5 and also set pointer-events:none on it, and see if that works?
(Assignee)

Comment 10

5 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7) 
> But if Google Docs is going to change, why wouldn't they just change to put
> their scrollbars above the cells so disappearing scrollbars work properly?

I was thinking that Google might want to be able to display permanently visible scrollbars from a UX standpoint. But I have to admit that this was just an assumption of mine and even if it turned out to be true, it wouldn't need to be handled as part of this bug.

> Stephen, could you try adding "pointer-events:auto" to the scrollbar rule in
> scrollbars.css, and then open a spreadsheet, and on .scroll-container set
> z-index to 5 and also set pointer-events:none on it, and see if that works?

This works great!
(Assignee)

Comment 11

5 years ago
Created attachment 782715 [details] [diff] [review]
Patch

Sets pointer-events:auto on scrollbars.
Attachment #782715 - Flags: review?(roc)
Comment on attachment 782715 [details] [diff] [review]
Patch

Review of attachment 782715 [details] [diff] [review]:
-----------------------------------------------------------------

This matches IE and Chrome so let's do it.
Attachment #782715 - Flags: review?(roc) → review+
Comment on attachment 782715 [details] [diff] [review]
Patch

Review of attachment 782715 [details] [diff] [review]:
-----------------------------------------------------------------

Er no. We need to do this on *all* scrollbars, not just root scrollbars! Especially for Docs!
Attachment #782715 - Flags: review+ → review-
(Assignee)

Comment 14

5 years ago
Created attachment 782873 [details] [diff] [review]
Patch
Attachment #782715 - Attachment is obsolete: true
Attachment #782873 - Flags: review?(roc)
Actually IE is irrelevant because IE doesn't support pointer-events:none on HTML content.
https://hg.mozilla.org/mozilla-central/rev/f8bf18dceb1c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 18

5 years ago
Still a Tech Evangelism bug despite the patch?
Assignee: english-us → spohl.mozilla.bugs
status-firefox25: affected → fixed
Flags: needinfo?(spohl.mozilla.bugs)
(Assignee)

Comment 19

5 years ago
This bug requires changes both on our and Google Doc's side. We've reached out to Google Docs with the suggestion in comment 9. I'm guessing this still counts as a Tech Evangelism bug?
Flags: needinfo?(spohl.mozilla.bugs)
(Assignee)

Updated

5 years ago
Component: English US → Widget: Cocoa
Product: Tech Evangelism → Core
Version: unspecified → Trunk
(Assignee)

Comment 20

5 years ago
Comment on attachment 782873 [details] [diff] [review]
Patch

Moving bug back to Core component because I can't request approval for aurora otherwise.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 636564
User impact if declined: Overlay scrollbars cannot work on Google Docs, and possibly other sites.
Testing completed (on m-c, etc.): Has been on m-c for 5 days.
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none
Attachment #782873 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 21

5 years ago
Comment on attachment 782873 [details] [diff] [review]
Patch

[Approval Request Comment]
(See comment 20)
Attachment #782873 - Flags: approval-mozilla-beta?
(Reporter)

Updated

5 years ago
tracking-firefox24: --- → ?
tracking-firefox25: --- → +
(Reporter)

Updated

5 years ago
Attachment #782873 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

5 years ago
Attachment #782873 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Updated

5 years ago
tracking-firefox24: ? → +
(Assignee)

Comment 22

5 years ago
Created attachment 788163 [details] [diff] [review]
Patch for beta branch

I just found out that overlay scrollbars for Windows will not be pushed to Fx24, so I removed the Windows parts. This is the patch that I will land on beta. I will wait to land until the patch for bug 896443 has landed in order for this patch to apply cleanly.
Attachment #788163 - Flags: review+
(Assignee)

Updated

5 years ago
status-firefox23: affected → disabled
(Assignee)

Updated

5 years ago
status-firefox24: affected → fixed
Target Milestone: --- → mozilla25
(Assignee)

Updated

5 years ago
Depends on: 907853
Keywords: verifyme
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0

Verified as fixed on Firefox 24RC (buildID: 20130910201120), Firefox 25 beta 2 (buildID: 20130923194050) and latest Aurora (buildID: 20130924004001).
Status: RESOLVED → VERIFIED
status-firefox24: fixed → verified
status-firefox25: fixed → verified
Keywords: verifyme
(Assignee)

Updated

5 years ago
Blocks: 920550
(Assignee)

Updated

5 years ago
Duplicate of this bug: 926292
Blocks: 880671
(Assignee)

Updated

4 years ago
Duplicate of this bug: 926292

Comment 27

4 years ago
Hi, I have a rather simple JSFiddle example where the scrollbar is still being overlapped by HTML elements (scrollbar is on a parent element that has a child with higher z-index) and this doesn't happen in Safari or Chrome:
http://jsfiddle.net/barts/6y4ce/

Screenshot of what I'm seeing here:
http://d.pr/i/jMN1

I have Firefox 28.0 on Mac OS X (10.9.1, Mavericks).
(Assignee)

Comment 28

4 years ago
(In reply to Bart Szyszka from comment #27)
> Hi, I have a rather simple JSFiddle example where the scrollbar is still
> being overlapped by HTML elements (scrollbar is on a parent element that has
> a child with higher z-index) and this doesn't happen in Safari or Chrome:
> http://jsfiddle.net/barts/6y4ce/

I've confirmed that this is the same issue as the one discussed in bug 926292 comment 11:
> It's true that we don't display the scrollbars at all in this case. Safari
> displays the scrollbars, but when the mouse hovers over the scrollbar, it
> doesn't widen the scrollbar like it usually does (presumably because the
> mouse hover is consumed by the div). I'd say Safari's behavior is more
> appealing to the eye, but not fully functional either.

A workaround is also given there, if desired.

Comment 29

4 years ago
(In reply to Stephen Pohl [:spohl] from comment #28)
> (In reply to Bart Szyszka from comment #27)
> > Hi, I have a rather simple JSFiddle example where the scrollbar is still
> > being overlapped by HTML elements (scrollbar is on a parent element that has
> > a child with higher z-index) and this doesn't happen in Safari or Chrome:
> > http://jsfiddle.net/barts/6y4ce/
> 
> I've confirmed that this is the same issue as the one discussed in bug
> 926292 comment 11:
> > It's true that we don't display the scrollbars at all in this case. Safari
> > displays the scrollbars, but when the mouse hovers over the scrollbar, it
> > doesn't widen the scrollbar like it usually does (presumably because the
> > mouse hover is consumed by the div). I'd say Safari's behavior is more
> > appealing to the eye, but not fully functional either.
> 
> A workaround is also given there, if desired.

It's not practical for me to shorten the width of elements for Firefox. When the scrollbar becomes hidden there will be a gap on the page and it would look awkward even if I made the scrollbars always visible. 

This is clearly a bug in the way Firefox handles scrollbars. Before the new style of scrollbars, the entire width of the page would be narrowed to make room for always-visible scrollbars. The new behavior is that the scrollbars should always be *on top* without affecting the width of the body. The z-index of child elements shouldn't cause the scrollbar to be obscured and I shouldn't be forced to make child elements 16-pixels narrower than parent elements and have 16-pixel gaps all over the place.

Comment 30

4 years ago
> the scrollbars should always be *on top* without affecting the width of the body

+100500

Comment 31

4 years ago
May be somehow related to bug 925686, which was then marked WONTFIX.
That was another instance where a scrollbar was displayed below content.
Fixing this bug may also benefit 925686.
Blocks: 925686

Updated

3 years ago
Depends on: 1156450
You need to log in before you can comment on or make changes to this bug.