Closed Bug 521966 Opened 14 years ago Closed 14 years ago

Flickering cursor while dragging over a possible drop target spot

Categories

(Firefox :: Tabbed Browser, defect, P3)

Product:
Firefox
Component:
Tabbed Browser
Version:
3.6 Branch
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 536920

People

(Reporter: ria.klaassen, Assigned: jimm)

References

Details

(Keywords: regression)

Attachments

(1 obsolete file) 

STR:

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

No further details yet.
Seems caused by bug 483776.
Blocks: 483776
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.
Assignee: nobody → jmathies
Flags: blocking-firefox3.6?
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.
Maybe this is an XP only bug? I can't reproduce on vista. Tried the big cursors theme as well.
This was Vista :)
OS: Windows XP → Windows Vista
(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?
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
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
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.
Summary: Dragging in menu causes flickering cursor → Flickering cursor while dragging over a possible drop target spot
(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.
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.
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.
Attached patch potential fix (obsolete) — — Splinter Review 

    
    

    
  
(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.

    
    

    
  
(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?

    
    

    
  
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'.
Assignee: jmathies → nobody
Component: Bookmarks & History → Tabbed Browser
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Priority: -- → P2
QA Contact: bookmarks → tabbed.browser
Assignee: nobody → jmathies

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
  

        Attachment #407087 -
        Attachment is obsolete: true

    
  
No longer blocks: 483776

    
  
Target Milestone: --- → Firefox 3.6
Version: Trunk → 3.6 Branch

    
    

    
  
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!

    
    

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

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
(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.

    
    

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

    
  
Priority: P2 → P3
Target Milestone: Firefox 3.6 → ---

    
  
Keywords: regression

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
(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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE

    
    

    
  
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.

          You need to log in
          before you can comment on or make changes to this bug.