110840 - XBL Scope Seemingly Not There

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Eric Murphy]

Hopefully my testcase will say it all. I can do a getElementById in a XUL doc,
and find an element with that id in an attached binding. Also doing stuff from
inside the binding doesn't show any scope existing in that direction either.

What happened? This didn't work at least a couple of months ago, and now it
doesn't nearly conform to the XBL spec. This seems very important to fix before
the next milestone.

Comment 1

[Eric Murphy]

Attachment: test.xul

Comment 2

[Eric Murphy]

Attachment: test.xml

Comment 3

[Eric Murphy]

Attachment: test.css

Comment 4

[David Hyatt]

I don't understand the bug.  Can you explain further?

Comment 5

[Eric Murphy]

OK. If you click on Button A, it should return null. Instead, it somehow finds
the value from inside the binding. getElementById is looking into the binding
for elements from the main document.

Basically, the anonymous content is acting like it's directly part of the
document's DOM.

Comment 6

[David Hyatt]

getElementById has never been properly scoped AFAIK.  I'd never done any work to
make that happen, so I'm unconvinced that this is a regression.  Are you sure
this actually used to work?

Comment 7

[Eric Murphy]

I could be wrong about the regression part, but I remember when I was learning
XBL, I'd try stuff like this and it would not work. My best memory was trying to
use getElementById in a binding to find other elements in that binding with the
same ID. This didn't work... I'm pretty sure of that.

Let me try to pull an old build and see what happens... I'll post an update here
this afternoon.

At any rate, this seems like a major problem? This seems to go totally against
the XBL spec, and also introduces the problem of multiple same IDs existing in
the same document.

Comment 8

[Eric Murphy]

OK... I just tried this testcase with 0.8, and it works correctly. Only button A
works... all the rest do not.

This is definitely a regression. Now what?

Comment 9

[David Hyatt]

It does go against the XBL spec, but there are many XBL bugs like that which I
probably won't have time to work on before Mozilla 1.0. :(

Heck, ElementXBL doesn't even exist.  You have to use undocumented DocumentXBL
methods instead.  That's much worse than this bug. :)

Comment 10

[Eric Murphy]

OK. Well I ran across this bug trying to make an example in the XBL chapter for
the "Building Applications with Mozilla" book. 

I'll have to sidestep around this issue... I tried saying that stuff like this
doesn't work, and that it goes against the spec... and here I find out it does
work. The main reason why I did this is because I remember trying all these
strange hacks when learning XBL, so I'm trying to guide readers away from these
types of things relating to scope.

Do you have any tips for me in writing this XBL chapter? I guess that I'll just
have to do my best for now. I think that you are a book reviewer? Maybe you can
offer some pointers after reading this thing.

Comment 11

[Jaime Rodriguez, Jr.]

Adding nsbeta1 keyword to all regressions so they *get some love* and attention.

Comment 12

[Peter Trudelle]

nsbeta1- per nav triage team

Comment 13

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 14

[Boris Zbarsky [:bzbarsky]]

getElementById hasn't returned anonymous content in a good long while.