Version: (using KDE KDE 3.5.6)
Installed from: RedHat RPMs
With 2 sub pages in a frame set, there appears to be some VERY strange
aliasing of DOM elements.
There is a minimised example at http://www.papermule.co.uk/example/index.html
The code in frame TWO uses a fully disambiguated reference
to get to the "test" element in frame two.
Despite this, the code (both "make" and "show") appears
to be operating on COMPLETELY different elements
depending on wether the CALL to the code is from frame one
or frame two.
To demonstrate the bug, click on "show attribute" in both
frames. Both alert()s will show "undefined".
The click on "make attribute" button in frame 1.
"show attribute" in frame 1 now shows "10",
but "show attribute" in frame 2 still shows "undefined".
Now click on "make attribute" in frame 2, and
"show attribute" in frame 2 will show "20".
But show attribute in frame 1 STILL shows "10".
The expected behaviour is that setting the attribute should
work from EITHER frame, and that viewing should
also show the same output from either frame.
By 'attribute' you mean an object property, right? Seems like we need to make the wrapper map global or such...
>> By 'attribute' you mean an object property, right?
I mean attributes as the term is used here...
i.e. an attribute of a DOM element.
In the test, I use "element.name", which can be both read and written.
Not true, actually. IE permits you to set attributes like that (which is non-standard!), and last I checked Mozilla doesn't. We actually do it weirdly and have only read access, which we should probably consider removing...
I don't want to argue (too much...) here, but the test works successfully on the following browsers:
SeaMonkey (Linix) 1.0.8
Safari (Mac) 2.0.4
Firefox (Linux) 220.127.116.11
IE 6 (XP) 6.0.2800.1106
IE 7 (XP) 7.0.5730.11
We also tried other attributes (out original app used a custom attribute)
Everything behaves "as expected" except for konqueror.
Well, it doesn't disagree with the testcase working/not working --- the point is that if you tried to go getAttribute('name') in gecko after setting it as .name IIRC it would not work. But that's a side note...
If you don't me writing to the "name" attribute, I can assure you the behaviour is just the same with a custom attribute.
(The example I put up was simplified down from a rather larger context,and we were indeed using custom attributes).
Try the following testcase:
document.body.name = 'foo';
yep, tried that. Did as you said.
document.body.blah = 'foo';
document.body.setAttribute( 'blah', 'foo2');
alert("++" + document.body.blah + "--" + document.body.getAttribute('blah') + "++");
I can put up a test of the same phenomona with a custom property if you wish.
Yeah, pretty much, except IE actually unifies the two, and we have partial emulation of that which is kinda odd... But as you said, it's all irrelevant to this testcase..
The situation with your bug is as following --- and you pretty much got it right --- in order to permit stuff like this to work, we have a table that maps DOM objects to corresponding JS objects. However, the table is per interpreter/frame so the two call above get separate JS objects representing the same DOM objects. It seems like we need to share the table, which isn't hard except I'd have to double-check with a few people to make sure it doesn't screw anything up XSS-wise.
And thanks again for reporting this... I suspect some of the reports about websites are caused by this.
One easy solution would be to complete the IE syntax, since attributes are already global.
Personally I think it is Firefox that is being really odd by sharing properties globally.
It wouldn't work completely since JS properties don't have to be strings (e.g. can be functions or objects)
But could you still make the properties part the DOM, so it is stored with the object instead of in the semi-global table?
Well, you would have to store a pointer to the wrapper object in every node, or be able to store arbitrary JS objects along attributes. (well, and then do a mark-and-sweep through the document, but it's sort of the right thing)
It'd be easiest to just make the wrapper map global --- the only reason I didn't do it is that I am not 100% certain of the XSS implications.
SVN commit 763528 by orlovich:
Properly coalesce wrappers accross documents. This requires having a global
map for hashconsing along with the previous local wrapper maps
used for memory management. (We also have to be careful to insert into
local maps when reusing from global ones).
M +4 -1 kjs_binding.cpp
M +26 -10 kjs_binding.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=763528