Closed
Bug 521969
Opened 15 years ago
Closed 12 years ago
Cannot reference tooltip by a changed ID inside XBL
Categories
(Core :: XBL, defect)
Core
XBL
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta2-fixed |
blocking1.9.1 | --- | .4+ |
status1.9.1 | --- | .4-fixed |
People
(Reporter: lpgcritter+bugz, Unassigned)
References
Details
(5 keywords, Whiteboard: [sg:dupe 522030])
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.14) 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:1.9.1.4) 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
Attachment #406000 -
Attachment description: example → test.xul
Comment 4•15 years ago
|
||
Bz, do I remember right that you changed ID handling in anonymous content?
Comment 5•15 years ago
|
||
I changed the behavior of getElementById (to not return anonymous content). I didn't change getAnonymousElementByAttribute. Looking into this.
Comment 6•15 years ago
|
||
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.
Updated•15 years ago
|
Comment 7•15 years ago
|
||
The fact that this works without changing the id is incredibly scary, by the way.
Comment 8•15 years ago
|
||
In XBL (e.g. tabbrowser.xml) I think you're expected to use tooltip="_child".
Comment 9•15 years ago
|
||
OK, but are we fine with making the compat-breaking change of requiring that on our stable branches?
Comment 10•15 years ago
|
||
id on xbl generated content isn't expected to be used, so I don't think there's anything to fix here.
Comment 11•15 years ago
|
||
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
blocking1.9.1: --- → ?
Flags: blocking1.9.2?
Flags: blocking1.9.0.15?
Comment 12•15 years ago
|
||
Well, we certainly need to fix the fact that it works to start with, before the attr change.
Updated•15 years ago
|
Group: core-security
Comment 13•15 years ago
|
||
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?
Depends on: 522030
Comment 14•15 years ago
|
||
We're going to re-spin both Firefox 3.0.15 and 3.5.4 for this issue.
blocking1.9.1: ? → .4+
Flags: blocking1.9.0.15? → blocking1.9.0.15+
Updated•15 years ago
|
blocking1.9.1: .4+ → ?
Flags: blocking1.9.0.15+ → blocking1.9.0.15?
Updated•15 years ago
|
Comment 15•15 years ago
|
||
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?
status1.9.2:
--- → final-fixed
Comment 16•15 years ago
|
||
Boris: This is fixed on 1.9.1 and 1.9.0 now, right?
Updated•15 years ago
|
Keywords: fixed1.9.0.15,
fixed1.9.0.16
Whiteboard: fixed1.9.0.15, fixed1.9.0.16
Comment 18•15 years ago
|
||
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:1.9.1.4) 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).
Flags: blocking1.9.2? → in-testsuite?
Keywords: verified1.9.1,
verified1.9.2
Comment 19•15 years ago
|
||
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.
Updated•15 years ago
|
Whiteboard: [sg:dupe 522030]
Comment 20•15 years ago
|
||
I'm not sure what is going on in 1.9.0 for this bug. If I run this on XP with 1.9.0.14 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14) 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 1.9.0.14 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15) 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.
Comment 21•15 years ago
|
||
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.
Comment 22•15 years ago
|
||
Yes, I meant build 3 of 1.9.0.15 (see string following). Comparing with Build 1, I see the failure there so this is verified fixed for 1.9.0.15. Does this work in the same manner for bug 522030 (verify build 3 against build 1)?
Updated•15 years ago
|
Keywords: fixed1.9.0.15 → verified1.9.0.15
Comment 23•15 years ago
|
||
(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.
Updated•15 years ago
|
Group: core-security
Comment 24•15 years ago
|
||
Verified for 1.9.0.16 using attached testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.16pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).
Keywords: fixed1.9.0.16 → verified1.9.0.16
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•