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)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: dbaron, Assigned: ehsan.akhgari)

References

Details

(Keywords: fixed1.9.1)

Attachments

(3 files)

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.
(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.
Attached patch Patch (v1)Splinter Review
Separate the cursor rules based on exact direction of the resizer.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attachment #358148 - Flags: review?(mano)
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.
Comment on attachment 358148 [details] [diff] [review]
Patch (v1)

Dao: perhaps you can review this faster?  Thanks!
Attachment #358148 - Flags: review?(mano) → review?(dao)
Component: XUL → Themes
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → themes
Attachment #358148 - Flags: review?(dao) → review+
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
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 on attachment 358148 [details] [diff] [review]
Patch (v1)

a191=beltzner
Attachment #358148 - Flags: approval1.9.1? → approval1.9.1+
1.9.1 patch based on the new patch in bug 240536.
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: