Closed Bug 521969 Opened 15 years ago Closed 12 years ago

Cannot reference tooltip by a changed ID inside XBL

Categories

(Core :: XBL, defect)

defect
Not set
normal

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)

366 bytes, application/vnd.mozilla.xul+xml
Details
889 bytes, text/xml
Details
50 bytes, text/css
Details
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
Attached file test.xul
Attachment #406000 - Attachment description: example → test.xul
Attached file testxbl.xml
Attached file test.css
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.
Blocks: 489925
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows Vista → All
Hardware: x86 → All
Version: unspecified → Trunk
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
blocking1.9.1: --- → ?
Flags: blocking1.9.2?
Flags: blocking1.9.0.15?
Well, we certainly need to fix the fact that it works to start with, before the attr change.
Group: core-security
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
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+
blocking1.9.1: .4+ → ?
Flags: blocking1.9.0.15+ → blocking1.9.0.15?
blocking1.9.1: ? → .4+
Flags: blocking1.9.0.15? → blocking1.9.0.15+
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.
Whiteboard: fixed1.9.0.15, fixed1.9.0.16
Whiteboard: fixed1.9.0.15, fixed1.9.0.16
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?
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.
Whiteboard: [sg:dupe 522030]
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.
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 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)?
(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.
Group: core-security
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).
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.

Attachment

General

Creator:
Created:
Updated:
Size: