324131 - [trunk] Persisting tooltip on desktop after minimizing

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Ria Klaassen (not reading all bugmail)]

This is most likely a regression of bug 312566. Tried builds before and after.
Ater minimizing Firefox I see a tooltip of one of my bookmarks, mostly on the opposite side (so left) of my desktop. Also often it happens (this only in my default profile) that within a second the window maximizes again all by itself!

Steps to reproduce (see also screen captures):

1. Make a new profile and copy some bookmarks to the bookmarks toolbar folder.
2. Then with the customize window open put the bookmarks toolbar on the same bar as the menus (see screenshot to see what I mean). Close customize window.
3. Then point your mouse, first hovering over a bookmark so that a tooltip is generated, on the minimize button.
4. Click Minimize.

Result: a tooltip is visible on your desktop, and you need to hover over that tooltip to get rid of it.

If you can't reproduce it, delete localstore.rdf and try again.
Don't know why it happens all the time in my default profile also with older localstore.rdf's.

This regressed between 1.9a1_2005120122 and 1.9a1_2005120206. Before that time the tooltip was not persistent.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-01+21%3A00%3A00&maxdate=2005-12-02+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 1

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot tooltip

Comment 2

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot action

Comment 3

[Martijn Wargers (dead)]

Strange,  I can't reproduce this.
In fact, I thought this was fixed by bug 312566, because this has a similarities with bug 307399 (which is also fixed for me).

Comment 4

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #3)
> Strange,  I can't reproduce this.
> In fact, I thought this was fixed by bug 312566, because this has a
> similarities with bug 307399 (which is also fixed for me).
>
It started to happen when those were fixed. The hovering state of the button should disappear when you leave the toolbar. Normally this does also happen. But in practice the discribed problem happens some way. The main problem is not the tooltip, but the extra move you need to make to get rid of it :( 

Comment 5

[Ria Klaassen (not reading all bugmail)]

I can reproduce the problem (bug 307399 but with persistent tooltip on the wrong place) consistently now in a new profile (latest trunk).
- Put your bookmarks toolbar folder under the titlebar
- Drag at least two icons to another place (no matter what icons)
- Or drag a tab.
- Then hovering over a BTI place your cursor on the titlebar.
- When you want to end the behaviour click on a button, menu or on the toolbar.

Comment 6

[Martijn Wargers (dead)]

Ah, now I see it too. The dragging is a necessary step to trigger the bug.

Comment 7

[Ria Klaassen (not reading all bugmail)]

Now I can also explain why I see it so frequently.
With the Super DragAndGo extension installed I often drags links and selected words which triggers the bug.
Glad to know what it is. Now I can rest and place some things without tooltips (folders) under my minimize button :)

Comment 8

[Martijn Wargers (dead)]

I think I don't see this bug anymore in the 2006-01-22 trunk build. I guess fixed by bug 322947 then?

Comment 9

[Ria Klaassen (not reading all bugmail)]

I see it in this one: 1.9a1_2006012206

Comment 10

[Martijn Wargers (dead)]

Ah, sorry, I see it too now in the 2006-01-22 build.

Comment 11

[Martijn Wargers (dead)]

Attachment: patch

Well, this seems to fix the bug. Not sure if it's any good.
I think when a dragdrop happens, the mouseup event is not fired, causing mIsInMouseCapture to stay PR_TRUE.

Comment 12

[Ere Maijala (slow)]

Comment on attachment 209278 [details] [diff] [review]
patch

I don't think the patch is good. It will (partially) wallpaper the symptom, but not the actual reason. We should get the mouse up, otherwise we're hosed. You can for example start dragging a link in bookmarks toolbar and drop it on itself and the button will stay depressed. I've yet to find out what's preventing the mouse up message.

Comment 13

[Ere Maijala (slow)]

Or perhaps I should say that we depend on getting mouse up, which might be wrong, but NS_MOUSE_EXIT is not enough either. 

Comment 14

[Martijn Wargers (dead)]

Isn't that the behavior that is normal? IE6 also doesn't fire mouseup after a dragdrop, see:
http://wargers.org/mozilla/dragdrop_mouse_up.htm
(and while dragging also no mousemove or mouseover/mouseout events are fired)

You're right, NS_MOUSE_EXIT is not enough. That drag-dropping problem you mention in comment, would also be nice to get that fixed.

Comment 15

[Martijn Wargers (dead)]

I think that's bug 193321, by the way.

Comment 16

[Ere Maijala (slow)]

Comment on attachment 209278 [details] [diff] [review]
patch

Ok, because the problem is visible on Linux too, it seems that NS_MOUSE_EXIT message isn't having the effect it should somewhere deeper than the platform widget level. Maybe this patch is all we on this level so let's get it in.

I also tested simulating mouse up after drop (that's what many are doing), but that caused tooltip to reappear and would have been inconsistent with IE anyway.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm a bit confused. If MOUSE_EXIT can fire while the mouse is captured, doesn't that mean that a mousedown in the window followed by moving the mouse outside the window will cause capture to be released when we want it to stay in force?

OTOH if MOUSE_EXIT can't fire while the mouse is captured, this won't have any effect. Or does the platform fire MOUSE_EXIT when a drag session ends?

Comment 18

[Martijn Wargers (dead)]

(In reply to comment #17)
> I'm a bit confused. If MOUSE_EXIT can fire while the mouse is captured, doesn't
> that mean that a mousedown in the window followed by moving the mouse outside
> the window will cause capture to be released when we want it to stay in force?
I don't think that's happening, because in that case I should have seen that dragging 'stops' when moving out of the window (which I didn't see).

> OTOH if MOUSE_EXIT can't fire while the mouse is captured, this won't have any
> effect. Or does the platform fire MOUSE_EXIT when a drag session ends?
No, the problem is that when a drag ends by releasing the button, NS_MOUSE_LEFT_BUTTON_UP isn't fired, so capturing mode is still enabled after a drag (see comment 11 and further), which ideally shouldn't happen.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In that case, just CaptureMouse(PR_FALSE) in the widget code is not a complete solution, because the frame system hasn't seen the button release. This is probably the cause of the problems in comment #12. At some level we have to tell the event system that the button was released ... somewhere that will get to nsFrame::HandleRelease, which will release the capture on its own.

I don't know if MOUSE_EXIT is the right place to detect this. I think we could have drag/drop operations without MOUSE_EXIT ever firing.

Comment 20

[Ere Maijala (slow)]

I played with synthesizing a mouse up after drag, but caused trouble. For some reason it made the tooltip reappear.

Comment 21

[Martijn Wargers (dead)]

Roc, this is a typical widget->windows bug that you might be able to fix now.

Comment 22

[Ere Maijala (slow)]

Comment on attachment 209278 [details] [diff] [review]
patch

It actually seems that mouse trailer dies when something is dragged, and that could cause the problem. I'll try to find the reason for that.

Comment 23

[Ere Maijala (slow)]

Of course it dies if mIsInMouseCapture is left on... Now I'm not sure if there even is a better way to fix this than what Martijn proposed. When dragging we're not going to get the mouse up and need to behave even then.

Comment 24

[Ere Maijala (slow)]

Attachment: Patch v2

Here is another along the lines of Martijn's patch. In addition to checking NS_MOUSE_EXIT it also checks NS_MOUSE_MOVE. This can be done as there is also a check if any of the buttons is down. Martijn, can you test this?

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 245794 [details] [diff] [review]
Patch v2

Looks good to me if Martijn likes it.

Comment 26

[Martijn Wargers (dead)]

(In reply to comment #25)
> (From update of attachment 245794 [details] [diff] [review] [edit])
> Looks good to me if Martijn likes it.

I like it, it fixes the bug for me.

Comment 27

[Ere Maijala (slow)]

Attachment: Patch checked in

Fix checked in to trunk. This is the actually checked-in patch. The original one had just already bit-rotten.

Comment 28

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This patch seems to have broken the behavior of the <xul:resizer> element. Seemingly at random the resizer will lose mouse capture and the window will then only resize if the mouse is over the resizer element. I finally traced the problem to a WM_MOUSE_EXIT event that is cancelling the capture set by the resizer element.

To try this out all you have to do is grab a resizer and then move the mouse like crazy for a little bit. At some time later the window will stop following the mouse.

Not sure if you want to reopen this or open a new bug.

Comment 29

[Ben Turner (not reading bugmail, use the needinfo flag!)]

This is probably exactly what roc is describing in comment 17.

Comment 30

[Ere Maijala (slow)]

Reopening. I had hard time reproducing, but yes, it happens. Maybe we'll just have to remove NS_MOUSE_EXIT and leave it to mouse move to decide if capture should be given up. 

Comment 31

[Ere Maijala (slow)]

Then again, it seems to me it the problem occurs only if the resizer widget goes invisible. Windows will then send a WM_MOUSELEAVE regardless of capture state. So, it's actually very easy to reproduce, just drag resizer up. All this really sucks because we should be able to handle WM_MOUSELEAVE aka NS_MOUSE_EXIT but if Windows spurts it out in this case, we can't use it.

Comment 32

[Ere Maijala (slow)]

I think we can get away with this by checking mouse button state also when WM_MOUSELEAVE is posted. 

Comment 33

[Ere Maijala (slow)]

Attachment: Additional patch to add mouse button states to NS_MOUSE_EXIT

I'm sure I can get this right eventually. This patch adds mouse button states to NS_MOUSE_EXIT too so we don't release the capture if a button is still down. The second hunk is just removing CR's I somehow managed to check in last time.

Comment 34

[Ere Maijala (slow)]

Comment on attachment 245962 [details] [diff] [review]
Additional patch to add mouse button states to NS_MOUSE_EXIT

Of course the printf in nsToolkit.cpp didn't belong to this patch.

Comment 35

[Ere Maijala (slow)]

Attachment: Additional patch to add mouse button states to NS_MOUSE_EXIT

Uh... fixed patch, this time without running it through cat -vte..

Comment 36

[Ere Maijala (slow)]

Additional patch checked in. Fingers crossed..

Comment 37

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Thanks, attachment 245963 [details] [diff] [review] fixed the resizer regression.