56647 - Autocomplete menu has URL bar tooltip

Status: RESOLVED WORKSFORME

(SeaMonkey :: Location Bar, defect, P3)

Description

[Blake Ross]

If you hover over an item in the autocomplete menu, it has the URL bar tooltip, 
because the menu doesn't specify a tooltip and therefore it derives from the 
parent (the textfield).  I have a fix for this, but it's in the XML, which 
isn't good for skinnability reasons.  Ducarroz, please see my question in bug 
56646 about styling this menu in a .css file.

Comment 1

[Blake Ross]

JF...?

Comment 2

[Jean-Francois Ducarroz]

this problem doesn't occurs on Mac but does occur in Linux!

Ross, I don't really have an answer for your question, see bug 56646

Comment 3

[Jean-Francois Ducarroz]

we need also to add a rule to remove the max width use actually by the menu item!

Comment 4

[Blake Ross]

Not sure what to do with this one, so handing over to JF for now...

Comment 5

[Jesse Ruderman]

Bug 63576 says there shouldn't be a tooltip for short urls in the dropdown, and 
that for long urls the tooltip should be the entire url.

Comment 6

[Jean-Francois Ducarroz]

Black Ross, what's your fix for the tooltip matter? I have a fix for the menu
width problem but I cannot figure out how to remove those anoying tooltip...

Comment 7

[Jean-Francois Ducarroz]

*** Bug 63576 has been marked as a duplicate of this bug. ***

Comment 8

[Jean-Francois Ducarroz]

Pinkerton, For some reason the menu "inherrite" the tooltip from the textfield.
But if I setup my own tooltip for the menuitem, this one still show the wrong
one. Any idea how I can tell the popup menu to use it's own tooltip or no
tooltip at all?

Comment 9

[Blake Ross]

The menu is supposed to inherit the tooltip from its parent (the textfield) 
unless it's overridden.  I swear I had a fix for this awhile back, but it 
doesn't seem to be working anymore.

And no, I don't know what I as talking about when I said styling this in css in 
my original report. Maybe I meant dtd.

Comment 10

[Marcia Knous [:marcia]]

Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.

Comment 11

[sairuh (rarely reading bugmail)]

pardon da spam...

Comment 12

[Joe Hewitt (gone)]

taking, marking dependency. This is fixed by the patch in 43189.

Comment 13

[Blake Ross]

This isn't fixed by the patch in 43189 as far as I can tell from the 
experimental build.

Comment 14

[Joe Hewitt (gone)]

Using both modern/classic, this seems to be fixed.  

Comment 15

[Blake Ross]

The bug is that hovering over an autocomplete menuitem shows a tooltip, and 
it's still there for me in a new nightly.  Meet me outside the parking lot of 
b21 at night if you wanna challenge that ;)

Comment 16

[Mike Pinkerton (not reading bugmail)]

this has gotten much much worse with the new AC widget. now hovering over 
anything in that widget, even the scrollbar, shows the url bar tooltip. it makes 
the AC widget pretty darn hard to use with the mouse.

Comment 17

[Joe Hewitt (gone)]

Yuck.  I wish I could reproduce this, but my tree builds, and the sweetlou build
I downloaded today do not demonstrate the problem. 

Comment 18

[Mike Pinkerton (not reading bugmail)]

i'm using a sweetlou build on mac from 5/1

Comment 19

[hangas]

Themes Triage Team marking nsbeta1+

Comment 20

[Joe Hewitt (gone)]

This is driving me INSANE.  I'm trying to solve this by setting "inputtooltip"
and "inputtooltiptext" on the autocomplete <textbox/>, then inheriting those
attributes to the anonymous <html:input/> and/or it's <xul:box/> parent as
"tooltip" and "tooltiptext".

But the gosh darn tooltip won't show.

I've tried setting those attributes on many different combinations of anon.
content, and the only success I've had is setting them on a popup or a button
with allowevents="true".  What is this bullocks?!

Is this coming down to a bug with the tooltip system or what?

Comment 21

[Joe Hewitt (gone)]

Attachment: this patch SHOULD fix the bug, but it does not

Comment 22

[Joe Hewitt (gone)]

not gonna get done in time -> 0.9.2

Comment 23

[Todd Pringle]

themes triage:

Not an rtm stopper - moving to 0.9.3.

Comment 24

[Joe Hewitt (gone)]

I'll get to this during the next milestone when I re-write the way tooltips work.

Comment 25

[Joe Hewitt (gone)]

*** Bug 112610 has been marked as a duplicate of this bug. ***

Comment 26

[Walter K.]

I can reproduce this 100%. The tooltip text is the same as the last tooltip
shown. For instance, if I hoover over personal toolbar link to get a tooltip and
then expand URL list, the tooltip over URL list is the same.
Win2K. Moz 0.9.8 (Build 2002020406)

Comment 27

[Blake Ross]

Attachment: patch - ain't it purty?

Comment 28

[Blake Ross]

So hewitt's patch doesn't work because of two problems:

* We don't register tooltip listeners if html elements in xul docs request tooltips.

* The target content for the mousemove event when you hover over the urlbar
isn't the containing box, but html:input (this isn't really a problem but a reality)

So although we did register a tooltip listener on the containing box with
hewitt's patch, when we looked for tooltiptext on the html:input when mousing
over, we found none.

This loser patch gets us to register the tooltip listener on the containing box
via the tooltiptext attr, and then ensures that we find the tooltiptext by
placing it on the html:input.

This is not a general fix but a fix for this specific, highly annoying bug.  I
presume a real fix would search a target content's children for tooltiptext if
not found on the target content.

Comment 29

[Blake Ross]

*** Bug 114978 has been marked as a duplicate of this bug. ***

Comment 30

[Blake Ross]

This bug was really annoying, so I checked in the attached 'fix'.  I guess I'll
leave this bug open to deal with the tooltip issue in general.

Comment 31

[Peter Trudelle]

nsbeta1- per Nav triage team, resolving as wfm, please open a new bug for
general case.

Comment 32

[Jesse Ruderman]

Still a problem for the location bar *context menu* (bug 133788).