521966 - Flickering cursor while dragging over a possible drop target spot

Status: RESOLVED DUPLICATE of bug 536920

(Firefox :: Tabbed Browser, defect, P3)

Description

[Ria Klaassen (not reading all bugmail)]

STR:

- Open bookmarks menu or overflow menu
- Drag one of the bookmarks

No further details yet.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Seems caused by bug 483776.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Yes, seems correct, regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d96ffc8c2749&tochange=5bbfae9a5c7e

Comment 3

[Jim Mathies [:jimm]]

Best guess is I'll have to cache the old value of mozCursor and not reset it during GiveFeedback. 

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeDragSource.cpp#122

Need to make sure I can reproduce this first though.

Comment 4

[Ria Klaassen (not reading all bugmail)]

It is better visible if I use a different pointer scheme e.g. Black Large. Then I see it quickly switch  between those two styles even if I stay on the same spot.

Comment 5

[Jim Mathies [:jimm]]

Maybe this is an XP only bug? I can't reproduce on vista. Tried the big cursors theme as well.

Comment 6

[Ria Klaassen (not reading all bugmail)]

This was Vista :)

Comment 7

[Jim Mathies [:jimm]]

(In reply to comment #6)
> This was Vista :)

Well maybe I'm doing something wrong. I built mozilla-central, opened it, clicked on bookmarks, grabbed a link from the menu and dragged it around. No flicker here regardless of mouse setting. I wonder if it has something to do with custom mouse drivers?

Comment 8

[Ria Klaassen (not reading all bugmail)]

Maybe I wasn't clear indeed, sorry! New STR:

- open bookmarks menu
- mousedown on bookmark
- drag it up or down in the same menu with the intention to insert it higher or lower in the same menu
- then it will start to flicker nervously, displaying the drag pointer and the default pointer alternately

Comment 9

[Ria Klaassen (not reading all bugmail)]

Another way:

- mousedown on favicon in locationbar
- drag the favicon onto the personal toolbar overflow arrow
- still mousedown, keep it there, eventually moving a few pixels, until it starts flickering

Comment 10

[Ria Klaassen (not reading all bugmail)]

Does this bug still need more assistance with STR? I didn't notice it before, but now I see it also when I drag a link over a tab or when I drag anything to a possible target. It hesitates between the correct cursor and the default pointer like it can't make a choice. :)
I used a complete empty profile and the latest nightly build for it. It reproduces also on a different brand laptop, although they both have a NVidea graphics card.

Comment 11

[Jim Mathies [:jimm]]

(In reply to comment #10)
> Does this bug still need more assistance with STR? I didn't notice it before,
> but now I see it also when I drag a link over a tab or when I drag anything to
> a possible target. It hesitates between the correct cursor and the default
> pointer like it can't make a choice. :)
> I used a complete empty profile and the latest nightly build for it. It
> reproduces also on a different brand laptop, although they both have a NVidea
> graphics card.

I still can't reproduce. If we can't track it down we'll just have to back that patch out.

I wonder why my work station doesn't have an issue but your laptop does? I'll try some images, see what i can come up with.

Comment 12

[[not reading bugmail]]

Interesting, haven't tested Vista.. 

For comparison, I also noticed the flickering on my work laptop with XP having an Intel 915GM display adapter with the latest trunk nightly with my microsoft mouse (HID Compliant generic driver) or touchpad (Synaptics driver) gives same result.

(In reply to comment #11)
> (In reply to comment #10)
> > Does this bug still need more assistance with STR? I didn't notice it before,
> > but now I see it also when I drag a link over a tab or when I drag anything to
> > a possible target. It hesitates between the correct cursor and the default
> > pointer like it can't make a choice. :)

Confirming similar behavior with just Drag and Drop tabs on the tab bar (without letting go) after a few seconds shows the flickering cursor.

Comment 13

[Jim Mathies [:jimm]]

I've not had much luck here. I was able to simulate the problem by flipping back and forth between the default and auto values for mozCursor, but under normal drags w/o changes the value is always "default" as set by tab browser.

Looking at the code, the patch in bug 483776 could not have caused this. tab browser sets the cursor to default on the start of a drag, and it stays that way throughout the operation. The calls into GiveFeedback always indicate the 'default' value and process appropriately. 

http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeDragSource.cpp#126

Looking over the win code, we are handling this correctly according to MSDN.

My only guess is that something funny is going on on some systems where the call to LoadCursor returns a new handle when it should hand back the handle to the cursor already loaded. I'll post a patch we can check in to test that theory.

Comment 14

[Jim Mathies [:jimm]]

Attachment: potential fix

Comment 15

[Jim Mathies [:jimm]]

(In reply to comment #13)
> I've not had much luck here. I was able to simulate the problem by flipping
> back and forth between the default and auto values for mozCursor, but under
> normal drags w/o changes the value is always "default" as set by tab browser.
> 
> Looking at the code, the patch in bug 483776 could not have caused this. tab
> browser sets the cursor to default on the start of a drag, and it stays that
> way throughout the operation. The calls into GiveFeedback always indicate the
> 'default' value and process appropriately. 
> 
> http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsNativeDragSource.cpp#126
> 
> Looking over the win code, we are handling this correctly according to MSDN.
> 
> My only guess is that something funny is going on on some systems where the
> call to LoadCursor returns a new handle when it should hand back the handle to
> the cursor already loaded. I'll post a patch we can check in to test that
> theory.

I should add, the funny thing here is that apparently this started after the patch in bug 483776 landed. That code updates mozCursor during a drag which could cause problems if the value was changing, but from testing that doesn't happen.

Comment 16

[Jim Mathies [:jimm]]

(In reply to comment #12)
> Interesting, haven't tested Vista.. 
> 
> For comparison, I also noticed the flickering on my work laptop with XP having
> an Intel 915GM display adapter with the latest trunk nightly with my microsoft
> mouse (HID Compliant generic driver) or touchpad (Synaptics driver) gives same
> result.
> 
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Does this bug still need more assistance with STR? I didn't notice it before,
> > > but now I see it also when I drag a link over a tab or when I drag anything to
> > > a possible target. It hesitates between the correct cursor and the default
> > > pointer like it can't make a choice. :)
> 
> Confirming similar behavior with just Drag and Drop tabs on the tab bar
> (without letting go) after a few seconds shows the flickering cursor.

Dale, what type of desktop config do you have? Is aero enabled, how about desktop composition?

Comment 17

[[not reading bugmail]]

Both are enabled on Windows 7.  Unfortunately, It doesn't matter if I turn off all the performance settings or turn them all on.  I still get the flicker.  
I'm using Win 7 RC 32bit with Nvidia 7200 on board display adapter using Logitech MX wireless USB series mouse.

FWIW, there are a lot of bugs about 'flicker'.

Comment 18

[[not reading bugmail]]

Jim, I see this on all 3 windows platforms.

As comment 0 states, this affects both drag and drop bookmarks in the bookmark UI dialog and bookmark menu, as well as drag and drop tabs and dragging favicons from the location bar and it is a general drag-n-drop mouse cursor issue.

I also noticed when the drag crosses UI elements it goes into flicker mode, but then i thought it might be in a race condition with the blue insertion point animation images being drawn.  But then I also see it flicker when dragging the location bar favicon over the home button, but no insertion image.  I can confirm seeing it in the bookmarks menu & UI dialog moving bookmarks around.

Though, one place it doesn't flicker is if I drag a bookmark or tab into a tab content window, flicker stops, but it also doesn't show me the drag box icon, I just see the original mouse cursor but I haven't released the bookmark or tab.

Comment 19

[Ria Klaassen (not reading all bugmail)]

Also before this bug started I noticed a strange behavior while dragging tabs and bookmarks. The drag cursor was interrupted by Firefox's insertion icons. Don't know why the cursor is interrupted, but that caused also a kind of flicker. This may be caused by Bug 389931, where there are more flicker bugs. Don't know if it has something to do with this bug but it looks ugly.

For instance: open bookmarks menu, mouse down on bookmark, drag up slowly. At the moment you see the insertion line apppear, the drag cursor disappears for a split second, then it appears again.

Can only be reproduced with earlier builds.

Comment 20

[Jim Mathies [:jimm]]

Can everybody confirm, this is on trunk only correct? Or are we seeing this on 3.6 builds?

Comment 21

[[not reading bugmail]]

Here is some quick feedback on XP using 3.6 latest nightly.  It seems to work much better than the trunk.  I only see it redraw the cursor (or flicker) when I move the mouse and doesn't flicker if I sit still.  Also the drag a bookmark onto the tab content window keeps the cursor state with a drag box until I drop.

In comparison the trunk flickers all the time even when the cursor is still. 

I won't be able to confirm the rest till late tonight or tomorrow.

Comment 22

[Ria Klaassen (not reading all bugmail)]

This is trunk-only but bug 483776 is marked wanted‑firefox3.6.
The issue of comment 19 is also in 3.6, 3.5 and 3.0.

Comment 23

[Jim Mathies [:jimm]]

Files bug 524748 on trunk only issues related to the landing of the event state manager patch in bug 483776.

All further testing, comments, etc. for this bug should be on 3.6 builds!

Comment 24

[Ria Klaassen (not reading all bugmail)]

Not sure what this bug is still for, only for the comment 19 issue?

Comment 25

[Jim Mathies [:jimm]]

(In reply to comment #24)
> Not sure what this bug is still for, only for the comment 19 issue?

Yeah if we can reproduce anything on 3.6, might as well look at it here seeing as how we already had blocking status. If there's nothing here (my guess is it's working as we expect it to) let's close it out.

Comment 26

[[not reading bugmail]]

Jim, that makes sense now; splitting this up.  Basically if I'm reading this right, the behavior in comment 19 already exists before landing bug 483776 with approval to land 3.6 if needed.  The additional trunk flicker issues I'm seeing can be looked at separately under bug 524758.

Comment 27

[[not reading bugmail]]

(In reply to comment #26)
> The additional trunk flicker issues I'm seeing can be looked at separately 
> under bug 524758.

Sorry, make that bug 524748.

Comment 28

[Jim Mathies [:jimm]]

(In reply to comment #26)
> Jim, that makes sense now; splitting this up.  Basically if I'm reading this
> right, the behavior in comment 19 already exists before landing bug 483776 with
> approval to land 3.6 if needed.  The additional trunk flicker issues I'm seeing
> can be looked at separately under bug 524758.

Yep. I've actually reproduced that in the bookmarks window on an xp image, so I'll be looking at it here as soon as I get my blockers done.

(In reply to comment #19)
> For instance: open bookmarks menu, mouse down on bookmark, drag up slowly. At
> the moment you see the insertion line apppear, the drag cursor disappears for a
> split second, then it appears again.

This I can reproduce on 3.6, but it's very hard to notice. We're probably changing moz cursor state as we drag across elements.

If this is the only oddity we have on 3.6 (I tried everything else suggested here to be sure, didn't find any issues) I think we should mark this as non-blocking.

Comment 29

[Jim Mathies [:jimm]]

Clearing blocking status, the majority of problems reported here turned out to be trunk only, which we spun off into another bug.

Comment 30

[Ria Klaassen (not reading all bugmail)]

The issue of comment 19 is certainly a regression as it worked fine with Firefox 2.

Comment 31

[[not reading bugmail]]

Occasionally I see the Black no drop or not allowed cursor (when we're talking cursor conflicts) and other times I don't, its not consistently activated or applied when it looks like it should.  Though, I don't ever see the CSS Red cursor:no-drop or Red cursor:not-allowed cursors but, maybe that is by design.  

Bug 522248 looks like it affecting DnD feedback.

Comment 33

[Phil Lacy]

Jim I think I got a handle on this. My patch in Bug 536920 appears to fix flickering cursor. The patch is a hack but I think I got an idea where it's at really at, looks to me like the event dataTranfer lacks setting of the mozCursor on creation but is used uninitialized to set the original drag object's dataTransfer. I'll look into it tonight.

Sorry about patch on your bug. Bugzilla is messing with me I swear.

Comment 34

[Phil Lacy]

Jim you might try the patch for Bug 536920 to see if it fixes this bug.

Comment 35

[Jim Mathies [:jimm]]

(In reply to comment #34)
> Jim you might try the patch for Bug 536920 to see if it fixes this bug.

I've never been able to reproduce the problem. Lets dupe this, land the patch and see if we can get those that have to confirm the fix.

Comment 36

[[not reading bugmail]]

This looks like it is fixed in 1.9.3 see bug 524748.  Though we'd still need a fix on 1.9.2 to confirm.