358446 - [cocoa] can't drag and drop buttons when customizing toolbars

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[(not reading, please use [e-mail] instead)]

[cocoa] can't drag and drop buttons when customizing toolbars.

this is with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20061027 Minefield/3.0a1

josh, any ideas?

fwiw, when I attempt to do the dnd of a button onto the toolbar when attempt to customize, I get the "hand" cursor.

Comment 1

[Phil Ringnalda (:philor)]

*** Bug 361249 has been marked as a duplicate of this bug. ***

Comment 2

[Håkan Waara]

I think dnd for this type is simply not implemented yet...

Comment 3

[Phil Ringnalda (:philor)]

*** Bug 362559 has been marked as a duplicate of this bug. ***

Comment 4

[Phil Ringnalda (:philor)]

*** Bug 363206 has been marked as a duplicate of this bug. ***

Comment 5

[Bruce P. Blair]

13 of the 24 customization icons do not appear in the drop-down screen

Is this merely an aspect of the same bug? - To whit: When attempting to customize toolbar of newly installed Camino 2006091101 (v1.0.3Int) on Mac G4 running 10.3.9 13 of the 24 customization icons do not appear in the drop-down screen.Only the text appears for thirteen of the bottons. 

The icon-like text "drags and drops" but without the true-icons appearing above the text—even after text is "dropped" onto toolbar. 

For what it's worth, the Apple Command [drop-down function) accociated with the individual missing icon/buttons while active, has no effect on the appearance of these missing icons. 

Further, clicking in the space where the icon "should appear" functions as if the icon were there—when clicking the space above text customizations dropped on the toolbar. 

First-time bug report. Hope you find it helpful. Many thanks.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(Comment 5 is bug 366163)

Comment 7

[Phil Ringnalda (:philor)]

This was vaguely tolerable while I could build Fx without Cocoa, but now that that's become impossible, doing anything with customization code is completely blocked.

Comment 8

[Colin Barrett [:cbarrett]]

Phil, how "blocking" is this bug? Is this preventing you from doing *any* work at all?

Basically, I'm asking if I should drop everything and look into fixing it now, or just move it to the top of my queue.

Comment 9

[Phil Ringnalda (:philor)]

Depends on how you look at it: it's the nature of Moz that you never want to be working on just one thing, or have just one tree, or use just one platform, because you'll always be getting broken or halted in one way or another. So I'm not entirely sitting on my hands, but, Firefox has separate UI for the customization dialog on OS X, and menus are handled sufficiently differently from every other platform, so I'm doing absolutely nothing with customization bugs (the ones I made depend on this, plus all the others I didn't bother with) until it's possible to test Mac as well as the lesser platforms.

As to what order you should do things, that has to be up to you and your manager-if-any, keeping in mind that I'm not all that productive and my time doesn't cost MoCo a penny. *I* think it should have been fixed before anyone even considered playing around with eye-candy HTML widgets, much as I hate our crayon-drawn radio buttons, but then there's probably a reason why I barely even get to decide what I do, much less what anyone else does.

Comment 10

[Colin Barrett [:cbarrett]]

Heh, alright.

I've moved this to the top of my queue, behind PPC printing not working. I'll get on this soonish.

Drag & Drop in general is something I've been wanting to investigate, so this isn't entirely out of my way.

Comment 11

[Neil Deakin]

This is because the code in nsChildView::initWithFrame only accepts certain types. If there's a way in cocoa to allow any type, that should be done. Otherwise, we would need to create some kind of wrapper type so that custom data types may be used.

Comment 12

[Colin Barrett [:cbarrett]]

What type of drag operation is being sent (if any)? There are a number of different ones beyond what nsChildView already implements (see NSPasteboard.h in AppKit for a complete list of the built in ones).

Comment 13

[Neil Deakin]

It isn't a built-in drag type, it's a custom one, which varies based on the window id. (For Firefox, it's 'text/toolbarwrapper-id/main-window')

Adding that specific type to the 'registerForDraggedTypes' call makes toolbar dragging work properly, but this needs a general solution. 

Comment 14

[Colin Barrett [:cbarrett]]

There isn't a way to register for all dragging types. A generic type of some kind seems like the way to go, then.

Comment 16

[Stan Shebs]

One of the nasties about this is that the custom drag type is created *after* the drag gesture begins, while Cocoa requires that types be registered before dragging gets underway. So we'd have to have some kind of on-the-fly reduction from the custom type to something generic.

Comment 17

[Stan Shebs]

Attachment: proposed fix

The patch may look a little hackish, but I think it's the right solution to a thorny problem, namely that the toolbar's drag type is built on the fly in JS code, long after it needs to be registered with Cocoa's list of drag types for the view. Basically we augment the fallback case of arbitrary drag types to also record the same data as a wildcard "anything" type. The JS code doesn't actually care about Cocoa's registration of drag types, it has its own tests for which drags to accept where, and in the presently-nonexistent case where there are multiple synthesized types in a single drag area, the JS code could still get the specific recorded type from the pasteboard and decide which kind of drag was meant.

Comment 18

[Asaf Romano (gone)]

Comment on attachment 262197 [details] [diff] [review]
proposed fix

josh, mark and stuart are better reviewers for this code.

Comment 19

[Josh Aas]

Comment on attachment 262197 [details] [diff] [review]
proposed fix

How about instead of just picking one random type to stuff in the wildcard we always make the wildcard data an NSDictionary that contains all unknown types? Then we can unstuff it at the other end and not lose any data.

Comment 20

[Stan Shebs]

Strictly speaking, we don't really need to record any data with the wildcard entry, since it only exists to mollify Cocoa. I just tried it out, supplying nil instead of currentValue, and it works just fine. Data transmission always goes through the other pasteboard entry, just like before.

Comment 21

[Josh Aas]

Comment on attachment 262197 [details] [diff] [review]
proposed fix

This looks good after a second look. Please change "anything" in

+NSString* const kWildcardPboardType = @"anything";

to MozillaWildcard or something like that.

Comment 22

[Stan Shebs]

Attachment: improved toolbar drag patch

Updated to reflect review comments. Somebody else will need to check in, I don't have commit privs.

Comment 24

[Josh Aas]

landed on trunk