Closed Bug 896443 Opened 12 years ago Closed 12 years ago

Z-ordering of overlay scrollbars needs tweaking

Categories

(Core :: Layout, defect)

24 Branch
All
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla25
Tracking Status
firefox23 --- disabled

People

(Reporter: spohl, Assigned: spohl)

References

(Depends on 1 open bug)

Details

(Whiteboard: [lion-scrollbars+])

Attachments

(5 files, 5 obsolete files)

After landing bug 870941 we no longer specify a z-index:<bignum> in the scrollbar's CSS. This fixes z-ordering issues in at least one known case (bug 868404), but also caused the following regression: From bug 636564 comment 242: At www.apple.com the scrollbar do not appear when the window is not maximized. Steps to reproduce: 1. run latest Nightly 2. open a small window 3. go to www.apple.com 4. scroll --> Result: No scrollbar
Adding ni=roc in case there are some good ideas how to approach this problem. The content on apple.com appears to specify a z-index of 1, but I'll need verify that that alone is causing this problem.
Flags: needinfo?(roc)
Whiteboard: [lion-scrollbars+]
Blocks: 891136
The current z-ordering also breaks scrollbars on Google Docs (bug 891136). When the CSS property 'z-index: 3' is removed for class 'grid-table-container'[1] in a Google spreadsheet [2], the scrollbars correctly display on top of the spreadsheet and scrolling is as responsive as it used to be. [1] https://docs.google.com/static/spreadsheets/client/css/2012322562-waffle_k_ltr.css [2] https://docs.google.com/spreadsheet/ccc?key=0AkZ8In_MZG_FdFN6R0VjdTc5ejNiZzJIY0tpNWUySEE#gid=0
In nsGfxScrollFrameInner::AppendScrollPartsTo, when overlay scrollbars are in use, we could make 'dest' be aLists.Outlines(). That should work.
Flags: needinfo?(roc)
Thanks roc. I ran a quick test with this but unfortunately, it didn't work. Content kept being displayed on top of the scrollbars. I'll have a deeper look at this tomorrow.
A display list dump with MOZ_DUMP_PAINT_LIST=1 might help.
Attached file displaylist dump (obsolete) —
This is a dump of the displaylist with MOZ_DUMP_PAINT_LIST=1 set in the environment and dest being set to aLists.Outlines() in nsGfxScrollFrameInner::AppendScrollPartsTo (see comment 3). Firefox was launched from the Terminal with a parameter of www.apple.com. The scrollbars should appear on top of the content there but fail to do so. At the top of the dump there's probably some data that pertains to the Firefox profile chooser dialog that launches by default for me on startup and can be ignored. Everything else is for www.apple.com.
This is the same dump as attachment 780442 [details] in HTML form, with dest set to aLists.Outlines in nsGfxScrollFrameInner::AppendScrollPartsTo. Scrollbars are not displayed on top of content.
This is a dump without the change suggested in comment 3 for comparison. Scrollbars aren't displayed.
This dump is taken from a build that adds back the z-index in nativescrollbars.css for testing purposes. Here, scrollbars display correctly on top of content.
Thanks. The <body> element of www.apple.com is position:relative z-index:1. We paint outlines under the elements with z-index > 0, so that's why the outlines layer didn't help. Sorry I didn't twig to that earlier. Here's one thing I think we can do: -- Make nsGfxScrollFrameInner::CreateAnonymousContent add the "root" attribute to horizontal and vertical scrollbars if mIsRoot is set. -- in scrollbars.css, make scrollbar[root] position:relative and z-index:<bignum> unconditionally.
Attached patch work in progress (obsolete) — Splinter Review
Great, this fixes www.apple.com. What attribute exactly should I be using on the scrollbars? 'nsGkAtoms::rootFrame', or 'nsGkAtoms::root_'? Unfortunately, this does not yet address the problem on Google Docs from comment 2. The difference from the problem on www.apple.com is that the scrollbars never used to show correctly, even before the landing of bug 870941. I'll be posting display list dumps shortly.
Attachment #780442 - Attachment is obsolete: true
Attachment #780480 - Attachment is obsolete: true
Attachment #780482 - Attachment is obsolete: true
Attachment #780490 - Attachment is obsolete: true
Attachment #781041 - Flags: feedback?(roc)
This dump was taken with attachment 781041 [details] [diff] [review] applied. The scrollbars are hidden by the cells in the spreadsheet. Out of curiosity, I've also tried setting the nsGkAtom::rootFrame attribute unconditionally on the scrollbars, and forcing aOwnLayer to 'true' in the static function AppendToTop. This did not help. (The dump was taken without those modifications).
This dump was taken after spoofing the CSS and removing 'z-index:3' for grid-table-container (comment 2). The scrollbars are visible on top of the cells with this change, but note that the row numbers for the spreadsheet are no longer visible. Maybe this dump is helpful and can be used to compare against dump 1 where the scrollbars aren't visible.
Comment on attachment 781041 [details] [diff] [review] work in progress Review of attachment 781041 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/generic/nsGfxScrollFrame.cpp @@ +2859,5 @@ > mVScrollbarContent->SetAttr(kNameSpaceID_None, nsGkAtoms::clickthrough, > NS_LITERAL_STRING("always"), false); > + if (mIsRoot) { > + mVScrollbarContent->SetAttr(kNameSpaceID_None, nsGkAtoms::rootFrame, > + NS_LITERAL_STRING("true"), false); Use nsGkAtoms::root_, which maps to "root".
Attachment #781041 - Flags: feedback?(roc) → feedback+
Let's land this. I'll take the discussion of Google Docs over to bug 891136.
Attached patch PatchSplinter Review
Thanks roc! Addressed feedback and added comment to clarify the chosen value for z-index. Carrying over r+.
Assignee: nobody → spohl.mozilla.bugs
Attachment #781041 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #781388 - Flags: review+
(In reply to Stephen Pohl [:spohl] from comment #17) > https://hg.mozilla.org/integration/mozilla-inbound/rev/c35d8edebbe1 ahh, no Windows love? :/
(In reply to Jim Mathies [:jimm] from comment #18) > (In reply to Stephen Pohl [:spohl] from comment #17) > > https://hg.mozilla.org/integration/mozilla-inbound/rev/c35d8edebbe1 > > ahh, no Windows love? :/ Argh, I wanted to make the same change for Windows once we have a solid patch. When we moved the discussion of Google Docs to bug 891136 I forgot about it. I shall put together a followup for Windows.
Followup for Windows.
Attachment #781657 - Flags: review?(roc)
(In reply to Stephen Pohl [:spohl] from comment #20) > Created attachment 781657 [details] [diff] [review] > Followup for Windows > > Followup for Windows. Thanks! FWIW, I can confirm the apple.com bug is in metrofx as well.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Attached image screenshot.png
Will this fix also fix the following issue: 1. go to google.de 2. notice the search box, the red log-on box and the use Chrome box on the right side 3. scroll Result: The scrollbars are under the boxes. I attached a screenshot. Please let me know, if I should file a new report for it. Thanks.
(In reply to Mehmet Sahin from comment #24) > Created attachment 781880 [details] > screenshot.png > > Will this fix also fix the following issue: I just checked and yes, the patch here will fix this too.
(In reply to Stephen Pohl [:spohl] from comment #25) > (In reply to Mehmet Sahin from comment #24) > > Created attachment 781880 [details] > > screenshot.png > > > > Will this fix also fix the following issue: > > I just checked and yes, the patch here will fix this too. Thanks for checking it :)
Comment on attachment 781388 [details] [diff] [review] Patch This is already in Fx25. [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 636564 User impact if declined: Overlay scrollbars can be hidden by content, for example on apple.com, making them difficult to interact with. Testing completed (on m-c, etc.): Has been on m-c for two weeks. Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #781388 - Flags: approval-mozilla-beta?
Comment on attachment 781657 [details] [diff] [review] Followup for Windows This is already in Fx25. [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 636564 User impact if declined: Overlay scrollbars can be hidden by content, for example on apple.com, making them difficult to interact with. Testing completed (on m-c, etc.): Has been on m-c for two weeks. Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #781657 - Flags: approval-mozilla-beta?
Comment on attachment 781657 [details] [diff] [review] Followup for Windows :jimm let me know that we don't need to uplift this to Fx24. Clearing a=?
Attachment #781657 - Flags: approval-mozilla-beta?
(In reply to Stephen Pohl [:spohl] from comment #30) > Comment on attachment 781657 [details] [diff] [review] > Followup for Windows > > :jimm let me know that we don't need to uplift this to Fx24. Clearing a=? Nope, 25 is good enough!
Attachment #781388 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
With the latest Aurora 25.0.a2 2013-08-13, no scroll bars appear in OWA (Outlook Web Access) in the area that you select an email to view. This tested with Exchange 2010 SP3 with Update Rollup 2, the most recent release available. Scrolling is erratic and lurches in blocks. Could it be related to this issue, or should I open another bug?
(In reply to Nick Lowe from comment #33) > Could it be related to this issue, or should I open another bug? Just a guess, but this could be related to bug 891136. Bug 891136 comment 5 gives more detail as to why this is happening for Google Docs.
Dear Stephen, I did some further testing and this issue only happens on a Mac and not under Windows. (Tested on 10.8.4) Any thoughts? Nick
It may be worth filing a new bug for OWA until we can tell for sure that we're facing the same problem as in Google Docs. You can select the same product, component and platform as this bug. Please include clear and reproducible STR. Best is to have a public way to reproduce the issue. Feel free to CC me on the bug. Thanks!
(In reply to Stephen Pohl [:spohl] from comment #0) > 1. run latest Nightly > 2. open a small window > 3. go to www.apple.com > 4. scroll > > --> Result: No scrollbar Everything's ok in FF 24b10 Mac OS X 10.8.4, but I also couldn't reproduce the initial issue on nightly 2013-07-22.
Given that QA cannot reliably reproduce the original issue as described I don't think we'll be able to truthfully verify this is fixed; tagging as [qa-] for now. Please replace the [qa-] whiteboard tag with the verifyme keyword if more reliable steps to reproduce can be provided.
Whiteboard: [lion-scrollbars+] → [lion-scrollbars+][qa-]
Could you please try the following steps: 1. In System Preferences > General, make sure that the option "When scrolling" is selected under "Show scrollbars:" 2. Run nightly from 7/22/2013 3. Go to www.apple.com 4. Make window smaller until scrollbars are supposed to appear 5. Scroll You may need to wait for the slideshow on apple.com to move a couple of images before the bug starts to appear. It is best to keep scrolling up and down while the slideshow is in progress. If the issue is present, the scrollbars will suddenly disappear behind the slideshow. I just verified and these steps reproduce the issue reliably for me on nightly 7/22/2013. If you still cannot see the issue, you could try the steps from comment 24 (slightly modified for clarity): > 1. In System Preferences > General, make sure that the option "When scrolling" is selected under "Show scrollbars:" > 2. Run nightly from 7/22/2013 > 3. go to google.de > 4. notice the search box, the red log-on box and the use Chrome box on the right side > 5. scroll > > Result: The scrollbars are under the boxes. Attachment 781880 [details] demonstrates the issue very well. Hope this helps!
Keywords: verifyme
Whiteboard: [lion-scrollbars+][qa-] → [lion-scrollbars+]
Thanks Stephen. Reproduced the issue on nightly 2013-07-22 using the instructions in comment 39. Verified fixed FF 24b10, 25.0a2(2013-09-10), 26.0a1(2013-09-10), Mac OS X 10.8.4.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Depends on: 994861
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: