354371 - Glitch during drag-n-drop of bookmarks on bookmark bar

Status: RESOLVED FIXED

(Camino Graveyard :: Drag & Drop, defect)

Description

[Ben Willmore]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060925 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060925 Camino/1.2+

If I drag a bookmark on the bookmark bar, and take it over to the right hand side of the bookmark bar (where there are no bookmarks), the ghost image jumps away from my pointer. Now they're separated by about a tab-width, and I can't tell where the bookmark is going to drop.

It doesn't happen every time, and I can work out exactly what causes it to happen. It seems more likely to happen on the first view drags after startup.

It works fine on the release versions and branch AFAICT.

Sorry this bug report does not offer a better way to reproduce.

Reproducible: Sometimes

Comment 1

[froodian (Ian Leue)]

I've definitely seen occasional glitchy favicon dragging during trunk testing.

Comment 2

[philippe (part-time)]

I've seen this problem occasionally when dragging a url to the desktop, or -more often- to another browser's icon on the dock. During the drag, the url-string + favicon (or globe) is visible some 50px away form where the cursor is. After releasing the mouse, I can see the whole thing 'jump back' to the location bar.

This never happens when dragging the proxy from the tab-bar.

Comment 3

[philippe (part-time)]

Attachment: Screenshot during drag

Comment 4

[Ben Willmore]

Attachment: Screenshot during drag along bookmark bar

Similar to Philippe's.

Comment 5

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

Does this go away if you apply the Cocoa drag/drop patches in bug 332913?

Comment 6

[philippe (part-time)]

(In reply to comment #5)
> Does this go away if you apply the Cocoa drag/drop patches in bug 332913?
> 

Nope. (PPC G4, 10.4).

Comment 7

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

This should be confirmed, but if anyone gets reliable steps, please do post them ;)

Comment 8

[John Bailey]

Dragging the favicon from the URL field in the toolbar across the bm bar will eventually trigger this (it usually happens quickly).  You can see when it happens because it starts dragging from the URL favicon again, and when you drop, you get the duplicate.  Interesting observation, when you drop onto the menubar (to cancel the drag/drop) the first ghost flys back to the URL field, then the second one flies back to the field when you mouse the mouse again (although this is intermittent).  This is on the trunk and 10.4.8, PPC.

Comment 9

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

If you're getting duplicate drags, that's bug 347212.

Comment 10

[philippe (part-time)]

(In reply to comment #9)
> If you're getting duplicate drags, that's bug 347212.
> 
You mean 'drops' ?

FWIW, I have a hard time reproducing the duplicated drop: I have to drag from the location bar _slowly_ to the BM bar. Even then, I not always get a duplicated drop. And never when I drop on the desktop.

Comment 11

[John Bailey]

Everytime I get the duplicate drag, I always get a dupe item in the bm bar after dropping.  With the dupe drag, I did NOT get a dupe item when dropping onto the desktop.

Comment 12

[philippe (part-time)]

I noticed this entry in my console.log at the same moment I drag a url from the location bar to the desktop/dock icon for other browser

2006-12-15 22:07:53.993 Camino[20687] error in CoreDragDispose: -1850

Comment 13

[Stuart Morgan]

I looked into this a bit, and we're getting a mouseDragged: in the proxy icon class while servicing the original drag.

The stack is:
-[PageProxyIcon mouseDragged:]
-[NSWindow sendEvent:]
-[NSApplication sendEvent:]
nsAppShell::ProcessNextNativeEvent
nsBaseAppShell::DoProcessNextNativeEvent
nsBaseAppShell::OnProcessNextEvent
nsAppShell::OnProcessNextEvent
nsThread::ProcessNextEvent
NS_ProcessPendingEvents_P
nsBaseAppShell::NativeEventCallback
nsAppShell::ProcessGeckoEvents
-[AppShellDelegate handlePortMessage:]
__NSFireMachPort
__CFMachPortPerform
CFRunLoopRunSpecific
CFRunLoopRunInMode
RunCurrentEventLoopInMode
ReceiveNextEventCommon
BlockUntilNextEventMatchingListInMode
_DPSNextEvent
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
NSCoreDragBlockingProc
SampleMouseAndKeyboard
DragInApplication
CoreDragStartDragging
-[NSCoreDragManager _dragUntilMouseUp:accepted:]
-[NSCoreDragManager dragImage:fromWindow:at:offset:event:pasteboard:source:slideBack:]
-[NSWindow(NSDrag) dragImage:at:offset:event:pasteboard:source:slideBack:]
-[PageProxyIcon mouseDragged:]
-[NSWindow sendEvent:]
-[NSApplication sendEvent:]

Mento, I looked at the ProcessNextNativeEvent code, and at this point it's manually running the runloop in NSDefaultRunLoopMode, but it doesn't look from the stack like the outer runloop is running in default mode. That seems bad.

Comment 14

[Stuart Morgan]

Nominating as a 1.9 blocker, since this appears to me to be a (serious) regression caused by core changes to runloop handling.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> Mento, I looked at the ProcessNextNativeEvent code, and at this
> point it's manually running the runloop in NSDefaultRunLoopMode, but
> it doesn't look from the stack like the outer runloop is running in
> default mode. That seems bad.

Stuart, is this still true?

Comment 16

[Stuart Morgan]

An interesting question; I haven't looked at this extensively since that comment, and in quick tests I'm not hitting it (although it was always a bit tricky to reproduce on command). I'll try testing more thoroughly again when I get a chance.

Have there been any changes you would expect to change this behavior specifically, or just general churn in the event handling chain?

Comment 18

[Stuart Morgan]

As another data point, bug 358122, which having looked at the stack again appears to be the same issue, doesn't seem to be reproducible anymore, and I think that used to be a 100% repro case.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

> Have there been any changes you would expect to change this behavior
> specifically

Yes.  As of my appshell patch, ProcessNextNativeEvent() now tries to
process events in whatever the current "mode" is (if it's not
NSDefaultRunLoopMode).

Comment 20

[Stuart Morgan]

Awesome; that certainly fits with the fact that I can't seem to reproduce this anymore. Calling this FIXED by your appshell works then--Thanks!

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> Thanks!

You're quite welcome.  I wish all our bugs were this easy
... i.e. already fixed :-)