Open Bug 113536 Opened 23 years ago Updated 2 years ago

tooltips don't handle mousedown event

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

People

(Reporter: hewitt, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [adt3]) 

This bug makes outliner titletips very annoying, because if one appears under
your mouse and you want to select the row your mouse is over, you can't.  I've
put breakpoints all the way down at the PresShell level, and on windows at
least, the mousedown event simply does not get dispatched.  What does get
dispatched is the NS_PLUGIN_ACTIVATE event.  This gets dispatched every time you
mousedown on the tooltip, but I would assume it should only happen once and then
the tooltip window would become active and wouldn't have to dispatch that event
again.  So, it seems something is going wrong at the widget level.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
*** Bug 113617 has been marked as a duplicate of this bug. ***
*** Bug 113699 has been marked as a duplicate of this bug. ***
nominating.
Keywords: nsbeta1
Joe, where would a guy like me start looking to find the titletip implementation?
This is not a bug in the titletips implementation.  As I stated in the bug
description, the NS_MOUSE_LEFT_BUTTON_DOWN event is not getting dispatched at
all when you click on the tooltip. In the titletips implementation I am already
handling mousedown and hiding the tooltip when it occurs, however, this listener
never gets called as it should.

Dean, see layout\xul\base\src\nsXULTooltipListener.cpp for the implementation
I've figured out what's happening here, nsWindow.cpp has special casing for
popups whenever WM_ACTIVATE is handled (on windows, and presumably for the
equivalent system message on other platforms).  I have to do something in
nsWindow::DealWithPopups to handle tooltips
Joe beat me to it...

Is this problem specific to Windows?  The only bug reports I've seen so far are
on Windows.

If it is, you may want to look at nsWindow::DealWithPopups().  Specifically I'm
wondering about the code that returns MA_NOACTIVATE on WM_MOUSEACTIVATE.  This
was done so... oh, I can't quite remember but I know it was important!  Maybe
pink can remember.

I'd look at this, but I won't be around the source for a couple of days.
So, I am able to make the tooltip go away by registering it on the window as a
rollup listener.  However, I still need to be able to pass the mousedown event
to the outlinerbody.  Unfortunately, there is no such mousedown message coming
from the OS, so I will probably have to synthesize one.
There really should be a message coming from the OS.  What do you mean there
isn't one?

You might want to look at bug 86606.  I don't know if my new function there
makes it any easier for you.
Yes! ShouldRollupOnMouseActivate does indeed help me out here.  I'll get
somebody to sr bug 86606 for you and land it for you, if ya don't mind.

A possibly related problem: the outliner isn't seeing mouse move events either.
Example:
|This subject is so long...|This sender is too long...|
Hover over the subject, and a titletip appears:
[This subject is so long that the title tip obscures the sender as well]
If you then hover over the sender, the subject titletip should dismiss,
and a new titletip for the sender should appear:
|This subject is so long...[This sender is too long as well]
In the worst case demonstrated above the entire row would be obscured and you
could only see the sender titletip by hovering from above or below.

And while I'm on the subject, what about cells that are so deeply nested that
there isn't any text to mouse over?

Oh, and why doesn't the text in the popup line up with the cells? Ideally you
would adjust for the theme-specific text offsets in the tooltip and cell...
Forget that last one, I figured out how to do it - although the CSS is there in
classic it didn't quite seem to line up properly.

And next time please post in n.p.d.skins and/or n.p.m.xpfe when you break skins...
Still wittering on...

Hard-coding 21px is wrong even in the skin, so there.
Real tooltips measure the height of the mouse pointer :-P
Joe: Go for it.  I've only been trying for a couple of months!
> And while I'm on the subject, what about cells that are so deeply nested that
> there isn't any text to mouse over?

Bug 113615
Neil, I did post about this landing to n.p.m.xpfe a few days ago.
*** Bug 113873 has been marked as a duplicate of this bug. ***
To follow up on comment #12, for me once the tooltip appears over the subject
line of the thread pane in Mail, no mouse events seem to be handled at all
(unlike the behavior described in comment #12), and Mail becomes manipulable
only by keyboard navigation. I filed bug 113873 on this and it was duped to this
bug, but it seems to be different. This bug appears to be about not being able
to click through a tooltip and about a tooltip not disappearing when the mouse
is moved, whereas my bug was about the entire window ignoring mouse events once
a tooltip had appeared. Is this indeed the same bug? 

If these are the same bug, the severity of this bug should probably be promoted
to critical or at least major, since this practically freezes the Mail interface
for the user who doesn't know how to do keyboard navigation.

Using Linux trunk build 2001-12-06-08.
Leston: I re-opened that bug.  It sounds different enough to keep it separate.

R.K.Aa: I think your behavior (and originally reported and duped bug) is the
same as bug 113873.
*** Bug 113873 has been marked as a duplicate of this bug. ***
Blocks: titletips
In reply to comment #17, you did not say that it would break existing skins...
*** Bug 114154 has been marked as a duplicate of this bug. ***
*** Bug 114093 has been marked as a duplicate of this bug. ***
Joe: the fix for bug 86606 has been checked in
*** Bug 113674 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Nav Triage Team:  marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
adding self to cc list
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 138185 has been marked as a duplicate of this bug. ***
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
*** Bug 140277 has been marked as a duplicate of this bug. ***
*** Bug 147606 has been marked as a duplicate of this bug. ***
*** Bug 152013 has been marked as a duplicate of this bug. ***
Is 131409 related to this?

We have found something similar to c19 on OS/2 (and someone found it 
on Linux)

If you can manage to click on a tooltip, the mouse stops working.

We traced to the fact that the tooltip is being destroyed during the 
mousedown.

Maybe the tooltip should not handle the mouse down and disappear on 
the mouse up?
On BeOS. 
Don't recall about vanilla BeOS builds, but when i set wider mouse event scope
in nsWidget code (to handle proper closing, hiding, destruction etc for popups)
- 1)enabling tooltips "freezes" left mouse button - and cursor permanently has
"over link" shape.  2)Tooltips don't stay - they flashes for moment and
disappears 3)First time they appear far outside window.
*** Bug 159810 has been marked as a duplicate of this bug. ***
I  think we should have to separate/distinct tooltips from other popups (menus,
pull-downs etc) on nsWidget implementation code level. Those have different
properties and should be handled differently.
We nned some tag for this purpose - e.g. new type eWindowType_tooltip or some other.
I've look at code for nsWindow/nsWidget for different platforms. Hacks and
workarounds everywhere about tooltips, but still those problems appear and appear.
Just because tooltips are handled same way as "active" popups.
Joe, I've been trying but failing to set up a rollup listener on the titletip.  
Did you implement it in nsMenuFrame?
OK, I've got the listener sitting in nsMenuPopupFrame now.  I can even reproduce
the old behavior of freezing the window when clicking on a tooltip.

Joe (and anyone else): did you ever get further on thinking about changes to
nsWidget::DealWithPopups (comment 6) or on how to use
ShouldRollupOnMouseActivate (comment 11)?  I added a second call to
ShouldRollupOnMouseActivate to DealWithPopups.  I was thinking of letting the
nsMenuPopupFrame pass through the event, but the problem is that there's now way
that I've found to communicate the specifics of the event from DealWithPopups to
the nsMenuPopupFrame.
1. Shouldn't this bug be re-targeted since it was not closed and
Mozilla 1.0.1 was released on September 10, 2002?

  http://www.mozilla.org/releases/stable.html

2. This is my #1 most annoying Mozilla bug of all time.  When I
right-click on a link to get a contextual menu, the tooltip that
pops up (for example, on bug numbers in comments in Bugzilla)
is positioned OVER the second item in the contextual menu, which is
either "Open Link in New Tab" (for default Mozilla builds) or
"Open Link in New Window" (for Red Hat's Mozilla builds).  It just
so happens that I always open a contextual menu to open a link in
a new tab.  The time it takes for me to right-click, move the mouse,
then left-click is just enough to make the tool tip appear under the
mouse pointer before I left-click, thereby disabling left-clicking
in the contextual menu and the menu bar!  ARGH!

Hmmm...I just noticed a couple things in playing with this bug (by
right-clicking on a bug number link in Bugzilla to bring up a
contextual menu before a tooltip appears):

1) If I right-click on the tooltip itself, the
   can't-click-in-contextual-menu bug does not occur!

2) If I left-click on the tooltip, the bug occurs.  But if I repeat
   the right-click on the bug link to bring up a contextual menu, then
   right-click on the tooltip, I am able to "nullify" the bug and am
   able to left-click in the contextual menu and in the toolbar again.

Why does right-click behave differently from left-click in this case?
(I suppose this is a stupid question since each click is set up with
different events, but the workaround is very interesting nevertheless.)

I am using Mozilla 1.1:

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021106

N.B. Has anyone ever looked at the top 10, 25, 100 open bugs with the
most CC addresses on them?  It seems to me like this would be a good
indication of which bugs are most "popular" and give an indication of
what should be fixed to make users happy.  This bug now has 34 CC
addresses (including my own that I just added).
David: the problem with right-click context menus is already fixed.  please use
a recent build to test Mozilla.
It seems this bug is related to Bug 156764.
I have posted a patch there.
Blocks: 135962
I talked to Joe about how to solve this, and what we came up with is that the
titletip needs to intercept the mousedown event and redispatch it to whatever is
underneath it (which could be some other application in the case of the titletip
extending beyond the window). This needs to happen at the widget level. An
example implementation of this can be found here for MFC based titletips:

See PreTranslateMessage in http://www.codeguru.com/listview/titletip.shtml

That code will have to be translated into Mozilla-speak, and similar code will
have to be written for each platform.
how can the platform widget code know that it is a tooltip? It's just a Mozilla
window.
I think it is potentially dangerous to allow tooltips to work as a "coverup" for
clickable areas underneath it. Users should be allowed to SEE what they click on.
Wouldn't it be better if one click made the tooltip go away for n seconds, so
user can see - and possibly click on - whatever the tooltip was hiding?
Moving outside the cell with the cropped text should make the titletip go away
(currently that doesn't happen though). With that, the user could only
potentially click on / select the cell the titletip is for.

mkaply: after talking to bryner I'm reconsidering my earlier suggestion. Right
now I'm looking at intercepting the mousedown at the DOM level and dispatching
it through either the DOM, nsIWidget::DispatchEvent or possibly
ESM::HandleEvent. There are concerns that this doesn't play nicely with
drag&drop, click, double-click, so I dunno, but I'll try.

If I do have to do something like comment 45, we'll have to find some way to
distinguish titletip windows from other windows. Essentially that's what the
article's author did by extending the window class, I think we could do the same
thing (if all platforms support that).
Aren't "Assignment", "Status Resolution" and "Target Milestone" = Mozilla 1.0.1 blatant wrong? The bug was assigned to the reporter, Joe Hewitt (gone), hewitt@formerly-netscape.com.tld, and his last comment has been comment #17 nearly 5 years ago.

Tooltips are still annoying, sometimes.
Assignee: hewitt → jag
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.widgets
Target Milestone: mozilla1.0.1 → ---
Assignee: jag → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates and 10 votes.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.