User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:188.8.131.52) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:184.108.40.206) Gecko/20091007 Firefox/3.5.4 If you changed the ID of a tooltip inside an XBL binding, you cannot refer to the new ID of the tooltip inside the XBL. (You can still however refer to it by the old ID). This was working as expected in 3.5.3. Reproducible: Always Steps to Reproduce: 1. See attachment example Actual Results: Tool tip does not show up Expected Results: Tool tip shows up
Bz, do I remember right that you changed ID handling in anonymous content?
I changed the behavior of getElementById (to not return anonymous content). I didn't change getAnonymousElementByAttribute. Looking into this.
Oh, the tooltip thing. I see... nsXULTooltipListener::FindTooltip uses getElementById. If it's supposed to work with XBL-generated content, that's wrong. Sadly we had no tests for this.
The fact that this works without changing the id is incredibly scary, by the way.
In XBL (e.g. tabbrowser.xml) I think you're expected to use tooltip="_child".
OK, but are we fine with making the compat-breaking change of requiring that on our stable branches?
id on xbl generated content isn't expected to be used, so I don't think there's anything to fix here.
And the reason it works to start with is this callstack: #0 nsIdentifierMapEntry::AddIdContent (this=0x1f1bda68, aContent=0x849a00) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/base/src/nsDocument.cpp:420 420 NS_PRECONDITION(aContent, "Must have content"); (gdb) t [Current thread is 1 (process 32789 local thread 0x2e03)] (gdb) bt #0 nsIdentifierMapEntry::AddIdContent (this=0x1f1bda68, aContent=0x849a00) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/base/src/nsDocument.cpp:420 #1 0x11f261e8 in nsDocument::UpdateIdTableEntry (this=0x1a97fa00, aContent=0x849a00) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/base/src/nsDocument.cpp:2333 #2 0x121a8ff8 in nsXULDocument::AddElementToDocumentPre (this=0x1a97fa00, aElement=0x849a00) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/xul/document/src/nsXULDocument.cpp:1704 #3 0x121aa81a in nsXULDocument::AddSubtreeToDocument (this=0x1a97fa00, aElement=0x849a00) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/xul/document/src/nsXULDocument.cpp:1786 #4 0x12167701 in nsXBLBinding::InstallAnonymousContent (this=0x20627340, aAnonParent=0x852820, aElement=0x2062fca0) at /Users/bzbarsky/mozilla/css-frameconst/mozilla/content/xbl/src/nsXBLBinding.cpp:377
Well, we certainly need to fix the fact that it works to start with, before the attr change.
I filed bug 522030 on comment 11; unfortunately this needs to stay closed until that bug is opened up. So this bug can stay on the desired behavior of nsXULTooltipListener::FindTooltip on the stable branches. Should it find nodes with the relevant id in the same anonymous subtree if aTarget is anonymous?
We're going to re-spin both Firefox 3.0.15 and 3.5.4 for this issue.
This is fixed on 1.9.2 by the checkin for bug 522030. Per comment 8 and comment 10, sounds like this is invalid on trunk?
Boris: This is fixed on 1.9.1 and 1.9.0 now, right?
Yes, it is.
verified fixed on 1.9.1 and 1.9.2 with builds on all platforms: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11) Gecko/20091016 Firefox/3.5.4 ID:20091016081620 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091016 Namoroka/3.6b2pre ID:20091016042840 Boris, checking Minefield shows me the tooltip on all platforms. So I assume too that there is no problem on trunk (from my testing perspective at least).
The state on trunk is temporary; I still need to file the bug on backing out the fix for bug 522030 on trunk, relanding the fix for bug 489925 with some additional changes to better handle the situation of bug 522030, etc. Once that's done this bug will reappear on trunk; the only question is whether it should be fixed (not that hard) or invalid/wontfix.
I'm not sure what is going on in 1.9.0 for this bug. If I run this on XP with 18.104.22.168 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/2009082707 Firefox/3.0.14 (.NET CLR 3.5.30729)) using the attached testcase, run locally from my desktop, I get the "heya" tooltip. I see the same exact behavior in build 3 of 126.96.36.199 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2009101601 Firefox/3.0.15 (.NET CLR 3.5.30729)). Was this bug actually ever explicitly seen in 1.9.0? Comment 0 implies it with the Build ID being present.
Al, you mean build 3 of 3.0.15, right? You should check build 1 or 2 to see the difference. It was a regression from 3.0.14.
Yes, I meant build 3 of 184.108.40.206 (see string following). Comparing with Build 1, I see the failure there so this is verified fixed for 220.127.116.11. Does this work in the same manner for bug 522030 (verify build 3 against build 1)?
(In reply to comment #22) > Does this work in the same manner for bug 522030 (verify build 3 against build > 1)? No, as given by Boris on bug 522030 we don't have a crash testcase yet.
Verified for 18.104.22.168 using attached testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).