Open Bug 903839 Opened 11 years ago Updated 2 years ago

Mac-style scrollbar: thumb is not bright on dark background

Categories

(Core :: Widget: Cocoa, defect)

24 Branch
x86_64
macOS
defect

Tracking

()

People

(Reporter: fb+mozdev, Unassigned)

References

()

Details

(Whiteboard: [lion-scrollbars=])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130806170643

Steps to reproduce:

Visit and scroll around on: http://www.coding2learn.org/blog/2013/07/29/kids-cant-use-computers/ (recommended read, BTW ;) )

Make sure that your browser window is wide enough to also show the dark background.


Actual results:

Scrollbar thumb is too dark on dark background (at least for the header area and general background). 


Expected results:

Scrollbar thumb is bright, like on Chrome & Safari. 

This, however, is a problem when the window is not wide enough to show the dark background: the content background (except header) is bright so the thumb is hardly visible there (at least in Chrome & Safari). However, at least in this case, most people will have a wide enough window to see the dark background.
Blocks: 865806
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
Hardware: x86 → x86_64
Whiteboard: [lion-scrollbars?]
Whiteboard: [lion-scrollbars?] → [lion-scrollbars=]
Hmm, Safari gets this right...
Looking through Inspector, I think the background color of this page seems to be rgb(37, 37, 37) which _should_ quality as dark with our heuristic...
Under the debugger, I get a transparent color:

(gdb) p *bgSC->StyleBackground()
$9 = {
  mAttachmentCount = 1, 
  mClipCount = 1, 
  mOriginCount = 1, 
  mRepeatCount = 1, 
  mPositionCount = 1, 
  mImageCount = 1, 
  mSizeCount = 1, 
  mLayers = {
    <nsAutoArrayBase<nsTArray<nsStyleBackground::Layer>, 1u>> = {
      <nsTArray<nsStyleBackground::Layer>> = {
        <nsTArray_Impl<nsStyleBackground::Layer, nsTArrayInfallibleAllocator>> = {
          <nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyElements<nsStyleBackground::Layer> >> = {
            mHdr = 0x11c68bb48
          }, 
          <nsTArray_TypedBase<nsStyleBackground::Layer, nsTArray_Impl<nsStyleBackground::Layer, nsTArrayInfallibleAllocator> >> = {
            <nsTArray_SafeElementAtHelper<nsStyleBackground::Layer, nsTArray_Impl<nsStyleBackground::Layer, nsTArrayInfallibleAllocator> >> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, 
      members of nsAutoArrayBase<nsTArray<nsStyleBackground::Layer>, 1u>: 
      {
        mAutoBuf = "\001\000\000\000\001\000\000?\000\000\001\003\003??\000\000\000\000\000\000\000\000\001???\000\000\000\000\000\000\000\000\001??\000\000\000\000??????????\000\000\000\000\000\000\000\000\000???????????????????????????\002\002?????", 
        mAlign = {
          elem = 1 '\001'
        }
      }
    }, <No data fields>}, 
  mBackgroundColor = 0, 
  mBackgroundInlinePolicy = 1 '\001'
}

I'm not sure what's going on here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's another example where it's the opposite (white thumb on white background): http://liftoff.github.io/GateOne/About/index.html#prerequisites

Can't you do some kind of multiply or inverse on the background?
… and another example: http://css-tricks.com/html5-meter-element/
This is also incorrectly handled in Chrome & Safari.
Seen this on more pages, e.g. http://blog.fogcreek.com/we-spent-a-week-making-trello-boards-load-extremely-fast-heres-how-we-did-it/ (in case this helps in finding edge cases)
The new MDN has the same issue (e.g. https://developer.mozilla.org/en-US/Firefox_OS/Releases/1.2). It uses white for HTML but a 30% blue on BODY – most of the page (under the thumb, at least) is white, though.
FWIW I think a good fix here would just be to emphasize the border of the scrollbar. As long as the border is thick/dark enough the scrollbar should still be visible and usable but right now the light-grey border on the scrollbar isn't high-contrast relative to the white.
See Also: → 951705
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.