XBL Scope Seemingly Not There




17 years ago
9 years ago


(Reporter: murphye, Unassigned)




Firefox Tracking Flags

(Not tracked)



(3 attachments)



17 years ago
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

17 years ago
Created attachment 58419 [details]

Comment 2

17 years ago
Created attachment 58420 [details]

Comment 3

17 years ago
Created attachment 58422 [details]


17 years ago
Keywords: regression

Comment 4

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

Comment 5

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

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


17 years ago
Target Milestone: --- → mozilla1.1

Comment 11

17 years ago
Adding nsbeta1 keyword to all regressions so they *get some love* and attention.
Keywords: nsbeta1

Comment 12

17 years ago
nsbeta1- per nav triage team
Keywords: nsbeta1 → nsbeta1-
QA Contact: jrgmorrison → xbl


9 years ago
Assignee: hyatt → nobody
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.
You need to log in before you can comment on or make changes to this bug.