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.
I don't understand the bug. Can you explain further?
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.
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?
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.
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?
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. :)
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.
Adding nsbeta1 keyword to all regressions so they *get some love* and attention.
nsbeta1- per nav triage team
Keywords: nsbeta1 → nsbeta1-
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.
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.