Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Cannot reference tooltip by a changed ID inside XBL




8 years ago
5 years ago


(Reporter: Loune, Unassigned)


(5 keywords)

regression, verified1.9.0.15, verified1.9.0.16, verified1.9.1, verified1.9.2
Dependency tree / graph
Bug Flags:
blocking1.9.0.15 +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta2-fixed, blocking1.9.1 .4+, status1.9.1 .4-fixed)


(Whiteboard: [sg:dupe 522030])


(3 attachments)

366 bytes, application/vnd.mozilla.xul+xml
889 bytes, text/xml
50 bytes, text/css


8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: 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: 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

Comment 1

8 years ago
Created attachment 406000 [details]


8 years ago
Attachment #406000 - Attachment description: example → test.xul

Comment 2

8 years ago
Created attachment 406001 [details]

Comment 3

8 years ago
Created attachment 406002 [details]

Comment 4

8 years ago
Bz, do I remember right that you changed ID handling in anonymous content?

Comment 5

8 years ago
I changed the behavior of getElementById (to not return anonymous content).  I didn't change getAnonymousElementByAttribute.

Looking into this.

Comment 6

8 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.
Blocks: 489925
Ever confirmed: true
Keywords: regression
OS: Windows Vista → All
Hardware: x86 → All
Version: unspecified → Trunk

Comment 7

8 years ago
The fact that this works without changing the id is incredibly scary, by the way.

Comment 8

8 years ago
In XBL (e.g. tabbrowser.xml) I think you're expected to use tooltip="_child".

Comment 9

8 years ago
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.

Comment 11

8 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

8 years ago
Well, we certainly need to fix the fact that it works to start with, before the attr change.


8 years ago
Group: core-security

Comment 13

8 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
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+
status1.9.1: --- → wanted
Flags: blocking1.9.0.15? → blocking1.9.0.15+

Comment 15

8 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
Boris: This is fixed on 1.9.1 and 1.9.0 now, right?

Comment 17

8 years ago
Yes, it is.
status1.9.1: wanted → .4-fixed
Whiteboard: fixed1.9.0.15, fixed1.9.0.16
Keywords: 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: 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

8 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.
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 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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 (see string following).

Comparing with Build 1, I see the failure there so this is verified fixed for

Does this work in the same manner for bug 522030 (verify build 3 against build 1)?
Keywords: fixed1.9.0.15 → verified1.9.0.15
(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 using attached testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).
Keywords: fixed1.9.0.16 → verified1.9.0.16
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.