42729 - Tooltips do not appear on text fields

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

I tried this on both <xul:textfield> and <html:input>, so it appears to be a 
problem with html:input rather than events not bubbling up to the containing 
box. 

e.g. 

<!-- for tooltip utility xul/js -->
<?xul-overlay href="chrome://global/content/globalOverlay.xul"?>

<textfield tooltip="aTooltip" tooltiptext="Foopy"/>

No tooltip appears when moused over. This bug blocks 42404, which the khakis/doc 
people deem "important".

Comment 1

[don]

Nominating for nsbeta2 since this blocks bug #42404 which is already nsbeta+.

Comment 2

[Mike Pinkerton (not reading bugmail)]

not a "blocker". dependency already set, that's enough.

Comment 3

[don]

This is still M21.  Will this be fixed for beta 2?

Comment 4

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix...to facilitate bug 42404.

Comment 5

[Mike Pinkerton (not reading bugmail)]

now that it's been marked as beta2+, i'll move it back in.

Comment 6

[leger]

Moving from [nsbeta2+] to [nsbeta2-] per todays PDT XP Toolkit Beta2 Review mtg.

Comment 7

[Mike Pinkerton (not reading bugmail)]

for my own notes, here's what is going on:

the onCreate (NS_MENU_CREATE) handler on an enderLite widget always returns 
consume_noDefault which is what we're using to indicate that the tooltip should 
not be displayed. It appears that enderLite is also hijacking this result code to 
show the event should not undergo default processing.

what we need to do is either modify the event handling code to not set 
consume_noDefault for NS_MENU_CREATE or switch to the new APIs for determining if 
the event has been handled and let consume_noDefault mean what it means 
elsewhere.

cc'ing mjudge, saari, and akkana. I'll hold onto this bug for now, but it isn't 
really a toolkit bug.

Comment 8

[saari (gone)]

more for your notes:

The new APIs of which you speak are nsIPrivateDOMEvent (nsPI?) ::SetHandled(bool) 
and bool ::IsHandled(void).

Comment 9

[Mike Pinkerton (not reading bugmail)]

need to coordinate with editor folks, but this should probably get fixed.

Comment 10

[Mike Pinkerton (not reading bugmail)]

future

Comment 11

[Mike Pinkerton (not reading bugmail)]

nope, not beta3. nothing to see here. move along.

Comment 12

[johng]

Pinkerton - please see dependency bug 42404 that has beeen repeatedly plused for 
beta3 and almost plused for beta2.  We need this capability for making search 
discoverable from the URL bar, and search is the #1 activity from Search.  It is 
also at the top of Jim Martin's list of UI enhancements.

Do not make an engineering only decision to cut this - let's talk if you like.

Comment 13

[Mike Pinkerton (not reading bugmail)]

jim martin has taken the time out of his busy schedule to comment that a tooltip 
on the url bar is one of the key UI improvements for 6.0?? Give me a break.

Man we have so many bigger problems than this. I'll defer to my manager. Talk to 
him if you want 42404 fixed.

Comment 14

[Peter Trudelle]

This reminds me of all those poorly-designed doors that offer only push
affordances, so they have to add a cheesy sign saying 'PULL'.  Unfortunately,
we've built the Location bar equivalent, and must now tack up a sign saying
'Search Here', or students will be unable to enter our School for the Gifted.
How long will it take to hook up tooltips to text fields? What are the risks?
Are you the right person to do the work?  

Comment 15

[Peter Trudelle]

->M18

Comment 16

[Mike Pinkerton (not reading bugmail)]

there are two ways to fix this bug:
- hack it to return the correct value for NS_MENU_CREATE, or
- update all of Ender to use the new nsIPrivateDOMEvent api's

I'm not about to check in a hack to ender, one that if landed will probably live 
on until we rewrite the codebase again. If the ender team wants to do this, it's 
their choice and they know the hack is there.

-->beppe for triage.

Comment 17

[rubydoo123]

this is on the low-hanging fruit list, assigning to sfraser to see what we can 
do, simon, let's talk

Comment 18

[Simon Fraser [no longer active]]

It's unlikely I can get to this. akk, can you take a look?

Comment 19

[Akkana Peck]

I'm not likely to have a chance either, but Anthony said we could put this on
his list.

Comment 20

[anthonyd]

yah, I already talked to pink about this, and he said he could show me how the 
new apis have changed.  I will grab pink this week and have a 'session' with 
him.

Anthony

Comment 21

[anthonyd]

removing nsbeta2- keyword

Comment 22

[leger]

Putting on [nsbeta2-] radar.  Bug already set for [nsbeta3+], missed PR2 train 
:-(

Comment 23

[Peter Trudelle]

getting off the CC spam radar...

Comment 24

[leger]

PDT is downgrading to [nsbeta3-], this is not critical to PR3 and RTM.

Comment 25

[rubydoo123]

moving to future and adding helpwanted

Comment 26

[anthonyd]

not sure about this, but i'll go ahead and move it to 0.9.

anthonyd

Comment 27

[anthonyd]

setting to p3.
anthonyd

Comment 28

[anthonyd]

pinkerton, this is one of the bugs I was telling you about.  When you get a 
chance, I want to get the new api's from you for this.

removing nsbeta stuff.

Comment 29

[rubydoo123]

bug 42404 has long been resolved, so is this still on issue? Moving to moz0.9.1

Comment 30

[Kathleen :Brade]

move to mozilla 0.9.2 since I don't see any pressing need for this at the moment.

Comment 31

[rubydoo123]

back to future for this one

Comment 32

[rubydoo123]

reassign to brade

Comment 33

[Kathleen :Brade]

hot potato?
-->kin

is this still a bug?

Comment 34

[Joe Hewitt (gone)]

works4me