Closed
Bug 474693
Opened 16 years ago
Closed 16 years ago
cursor (pointer) over scrollcorner is the wrong one (ugly nwse-resize instead of good se-resize)
Categories
(Toolkit :: Themes, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: dbaron, Assigned: ehsan.akhgari)
References
Details
(Keywords: fixed1.9.1)
Attachments
(3 files)
1.57 KB,
patch
|
dao
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
125.70 KB,
video/ogg
|
Details | |
857 bytes,
patch
|
Details | Diff | Splinter Review |
The mouse pointer over the scrollcorner in the main Firefox window is the wrong one; it no longer matches the mouse pointer that you get if you move the mouse a few pixels further onto the actual window frame. Steps to reproduce: 1. load Firefox 2. move the mouse to the lower-right edge of the bar at the bottom of the window where there are a bunch of dots indicating something you can grab to resize 3. look at the mouse cursor 4. move the mouse a few pixels down and to the right, so that it's over the actual window frame 5. look at the mouse cursor again Expected results: 3. mouse cursor is the standard window resize cursor for resizing at the bottom right corner 5. mouse cursor is the standard window resize cursor for resizing at the bottom right corner Actual results: 3. mouse cursor is a bizarre looking cursor indicating ability to drag something diagonally to the upper left or the lower right 5. mouse cursor is the standard window resize cursor for resizing at the bottom right corner (as expected) This regressed between x86_64 Linux nightlies 2009-01-18-01-mozilla-central and 2009-01-19-02-mozilla-central, which gives a regression range of: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=04a8a61b9999&tochange=afec2ee5b993 When I look at the area showing the bad cursor in DOM Inspector, I see that it's a xul:resizer element and a style rule in chrome://global/skin/resizer.css is giving it a 'cursor: nwse-resize'. In the good build, it was getting a resizer[dir='bottomright'] { cursor: se-resize; } from chrome://global/skin/global.css . Since I see that the patch in bug 240536 removed the rule that caused the good display and added the one that causes the bad display, I'm pretty confident that that patch is responsible. I suspect this should be relatively simple to fix: just remember that nwse-resize is not the same on all platforms as se-resize and nw-resize, and go back to using the more specific ones.
Reporter | ||
Comment 1•16 years ago
|
||
(In reply to comment #0) > I suspect this should be relatively simple to fix: just remember that > nwse-resize is not the same on all platforms as se-resize and nw-resize, and go > back to using the more specific ones. In particular: * on Windows, the platform provides only nwse-resize, etc., so we use those for nw-resize, se-resize, etc. * on GTK, the platform only provides nw-resize, se-resize, etc., so we actually make up our own nwse-resize that doesn't come from the platform and which therefore doesn't fit in with the cursor theme * on Mac, we make up all the diagonal ones ourselves, but the platform provides distinct n-resize, s-resize, and ns-resize cursors.
Assignee | ||
Comment 2•16 years ago
|
||
Separate the cursor rules based on exact direction of the resizer.
Comment 3•16 years ago
|
||
I just ran across this issue on my machine (and I was about to file a new bug, until I found this one already filed with a patch already posted -- nice! :) ). Here's a quick ogg-video clip of it happening on Linux, FWIW.
Assignee | ||
Comment 4•16 years ago
|
||
Comment on attachment 358148 [details] [diff] [review] Patch (v1) Dao: perhaps you can review this faster? Thanks!
Attachment #358148 -
Flags: review?(mano) → review?(dao)
Updated•16 years ago
|
Component: XUL → Themes
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → themes
Updated•16 years ago
|
Attachment #358148 -
Flags: review?(dao) → review+
Assignee | ||
Comment 5•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/8c2b629e1bb8
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Comment 6•16 years ago
|
||
Comment on attachment 358148 [details] [diff] [review] Patch (v1) Theme-only low-risk change which we need to take if bug 240536 is approved for the 1.9.1 branch.
Attachment #358148 -
Flags: approval1.9.1?
Comment 7•15 years ago
|
||
Comment on attachment 358148 [details] [diff] [review] Patch (v1) a191=beltzner
Attachment #358148 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Comment 8•15 years ago
|
||
1.9.1 patch based on the new patch in bug 240536.
Assignee | ||
Comment 9•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0c9cb75bc9ba
Keywords: fixed1.9.1
Assignee | ||
Updated•11 years ago
|
Flags: in-litmus?
You need to log in
before you can comment on or make changes to this bug.
Description
•