Closed Bug 427256 Opened 16 years ago Closed 16 years ago

Scroll Control Arrows don't work when moved to the top

Categories

(Core :: Widget: Cocoa, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9

People

(Reporter: spamthis, Assigned: mstange)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

By editing global OS defaults a user can relocate the window's scroll arrows to the top of the scroll bar. If moved they do not work at the top, however, if one clicks where the buttons were at the bottom, they will work.

Reproducible: Always

Steps to Reproduce:
1. Close Firefox
2. Change placement of scroll arrows. Open terminal.app, type 'defaults write "Apple Global Domain" AppleScrollBarVariant DoubleMin'
3. Open firefox
4. Attempt to use scroll arrows visually placed at the top of the scroll bar.

Actual Results:  
Scroll arrows do not work. Clicking where they were at the bottom (phantom arrows), does operate the controls at the top.

Expected Results:  
Arrows should work wherever the widget it placed.

There are multiple values of "AppleScrollBarVariant" with different effects.

These include: 
 AppleScrollBarVariant = DoubleMin; (Double arrows at the top)
 AppleScrollBarVariant = DoubleBoth; (Double arrows at both ends)
 AppleScrollBarVariant = DoubleMax; (DEFAULT: Double arrows at the bottom)
 AppleScrollBarVariant = Single; (Single arrows at both ends)

Only "DoubleMax" and "Single" are available through the GUI system preferences. I have only tested the DoubleMin value.
Multiple people are able to reproduce this
Status: UNCONFIRMED → NEW
Component: OS Integration → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
Version: unspecified → Trunk
Status: NEW → ASSIGNED
The necessary code for scrollbar arrows at the top is already there, we just didn't detect the setting properly.
Assignee: nobody → mstange
Attachment #313830 - Flags: review?(joshmoz)
Attachment #313830 - Flags: review?(joshmoz) → review+
QA Contact: os.integration → cocoa
Attachment #313830 - Flags: superreview?(roc)
Attachment #313830 - Flags: superreview?(roc) → superreview+
Comment on attachment 313830 [details] [diff] [review]
Fix v1.0: Add missing check for arrow style

Requesting approval1.9 - very low-risk patch for a rarely encountered but painful scenario.
Attachment #313830 - Flags: approval1.9?
Ah, forgot about the tests: I don't think writing a test for this bug is feasible or even possible; the test would have to execute command line commands and restart the browser...
Comment on attachment 313830 [details] [diff] [review]
Fix v1.0: Add missing check for arrow style

a1.9=beltzner
Attachment #313830 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in widget/src/cocoa/nsLookAndFeel.h;
/cvsroot/mozilla/widget/src/cocoa/nsLookAndFeel.h,v  <--  nsLookAndFeel.h
new revision: 1.7; previous revision: 1.6
done
Checking in widget/src/cocoa/nsLookAndFeel.mm;
/cvsroot/mozilla/widget/src/cocoa/nsLookAndFeel.mm,v  <--  nsLookAndFeel.mm
new revision: 1.18; previous revision: 1.17
done
Checking in widget/src/cocoa/nsNativeThemeCocoa.mm;
/cvsroot/mozilla/widget/src/cocoa/nsNativeThemeCocoa.mm,v  <--  nsNativeThemeCocoa.mm
new revision: 1.91; previous revision: 1.90
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: