Open Bug 876875 Opened 8 years ago Updated 3 years ago

dataTransfer.mozCursor should accept "grabbing"

Categories

(Core :: Widget, defect, P3)

defect

Tracking

()

People

(Reporter: jaws, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P5][tpi:+])

Attachments

(2 files)

On Windows we can set dataTransfer.mozCursor to "default" so that the moving cursor isn't used.

When in customization mode, it would be nice to have the -moz-grabbing cursor used, since the user is actively picking an item and moving it.

This should also be implemented for all major platforms (linux, osx, and windows). mozCursor is currently only implemented for Windows.
Whiteboard: [Australis:M?]
https://code.google.com/p/chromium/issues/detail?id=74699 mentions that "Those cursor images are built-in to the Mac and can be swiped in bit array form for GTK."

Jim, do you know of anyone who can help us out here?
Flags: needinfo?(jmathies)
Smichaud might be able to help on Mac, maybe Karlt for linux?

On windows looks like we load a custom cursor from a file - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#2388
Flags: needinfo?(jmathies)
The GTK port supports -moz-grabbing cursors [1] but not during drags.
It doesn't look like GTK provides an interface to the application for this purpose, but instead uses a cursor from the current theme appropriate for the current drag action.  It may be possible through tricks like changing the theme and using XCURSOR_PATH to point to a theme with different cursors, or grabbing the pointer again with a different cursor, but these probably come with more risks than they are worth.  A replacement implementation using only GDK and rewriting the GTK parts is probably possible, but too much work/code.

[1] http://hg.mozilla.org/mozilla-central/annotate/495b385ae811/widget/gtk2/nsGtkCursors.h#l372
Yet another prefix proliferation :(
I frankly don't know how difficult or easy it'd be to do this on the Mac.  Both Josh Aas and Markus Stange have done more work on the Cocoa dragging code than I have, and might have a better idea.

I did notice something interesting looking through the Cocoa dragging code just now:

http://hg.mozilla.org/mozilla-central/annotate/8d85de779506/widget/cocoa/nsChildView.mm#l755

Here we stop nsChildView::SetCursor() from working if a drag is in progress.  And see bug 358095 comment #1, which seems to say that bad things happen (or used to happen) if we allow Gecko to set the cursor during a drag.
(Following up comment #5)

Oddly, there's another implementation of nsChildView::SetCursor() just below (with different parameters) that works just fine if a drag is in progress:

http://hg.mozilla.org/mozilla-central/annotate/8d85de779506/widget/cocoa/nsChildView.mm#l768
Attached patch for macSplinter Review
Does this do the trick?
Attached patch WIP for WindowsSplinter Review
(In reply to Markus Stange from comment #7)
> Created attachment 755422 [details] [diff] [review]
> for mac
> 
> Does this do the trick?

Most likely not, there is still some other parts of the drag/drop code that needs to be updated to propogate a -moz-grabbing string down to the native levels.

This patch should do so, but it doesn't get the cursor to load on Windows.
Not taking this for Australis:M7.
(In reply to Masatoshi Kimura [:emk] from comment #4)
> Yet another prefix proliferation :(

Filed bug 880672.
Whiteboard: [Australis:M?] → [Australis:M?][Australis:P5]
Comment on attachment 755424 [details] [diff] [review]
WIP for Windows

Jim, do you think you could help me out here as to why the cursor isn't loading?
Attachment #755424 - Flags: feedback?(jmathies)
(In reply to Jared Wein [:jaws] from comment #11)
> Comment on attachment 755424 [details] [diff] [review]
> WIP for Windows
> 
> Jim, do you think you could help me out here as to why the cursor isn't
> loading?

Is that load cursor call occurring? Maybe we override it someplace else? You might check SetCursor in widget to see.
Blocks: 908910
Attachment #755424 - Flags: feedback?(jmathies)
Several people have noticed this, so maybe we should try to put more effort into fixing this?
Whiteboard: [Australis:M?][Australis:P5] → [Australis:M?][Australis:P4]
-moz-grabbing has been unprefixed.
Summary: dataTransfer.mozCursor should accept "-moz-grabbing" → dataTransfer.mozCursor should accept "grabbing"
(In reply to Karl Tomlinson (:karlt) from comment #3)
> The GTK port supports -moz-grabbing cursors [1] but not during drags.
> It doesn't look like GTK provides an interface to the application for this
> purpose, but instead uses a cursor from the current theme appropriate for
> the current drag action.

The Adwaita theme provides cursors for dnd-none, dnd-move, etc that represent a hand grabbing.  These are what are used for drags.
Whiteboard: [Australis:M?][Australis:P4] → [Australis:M?][Australis:P5]
Whiteboard: [Australis:M?][Australis:P5] → [Australis:M?][Australis:P5] [feature] p=0
No longer blocks: fxdesktopbacklog
Whiteboard: [Australis:M?][Australis:P5] [feature] p=0 → [Australis:M?][Australis:P5]
Whiteboard: [Australis:M?][Australis:P5] → [Australis:P5]
Priority: -- → P3
Whiteboard: [Australis:P5] → [Australis:P5][tpi:+]
Could this be considered as part of Photon ?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Guillaume C. [:ge3k0s] from comment #16)
> Could this be considered as part of Photon ?

I don't think so. The changes to customize mode are fairly minimal - mostly to support other work we're doing - and there's a pretty sizable backlog of other work that we need to get done in the next 2 months or so still. So I don't think this is a good fit in terms of the cost/benefit/alignment balance.
Flags: needinfo?(gijskruitbosch+bugs)
Maybe as follow-up work for a v2 then. ;-)
You need to log in before you can comment on or make changes to this bug.