Please report any other irregularities here.
In some js method new Option is created and some custom attribite is assigned to it, then this Option is added in some Select; if method is called from the same page where Select is located, custom attribute is always kept by Option, BUT in Mozilla if ...
Created attachment 112159 [details] Difference between setAttribute and className="" I think it is setAttribute weirdness. If I use className="new" CSS style apply, but in setAttribute('className','new') don't. I think I see same bug with setAttribute recently.
Oops. I miss a bug
Comment on attachment 112166 [details] I'm not sure that this is because of setAttribute() That's just the point - I don't use setAttribute(). And what is more, I'm generally not sure that my script is correct from the DOM point of view. All that I can say - this script works in IE, Opera and does not work in Mozilla IN SOME CASE. BTW, about using setAttribute() see http://www.xs4all.nl/~ppk/js/w3c_core.html
Sorry, it was attachment to other bug, and not to this one. But I could not reproduce you one. I do AddFromSelf (return 0), AddFromChild (return 1), select first line, press ShowCustom Att (get 0), select second line, press ShowCustom Att (get 1). Everything seems to be o'k. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030121
It seems that I have too old version - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212, probably in the latest versions all work as you have said.
Could someone attach a working testcase to this bug ("working" == "shows the problem")? If that requires multiple files (eg a frameset and a frame) attach the frame first, then point the frameset to the bugzilla attachment url and attach it.
Eugene, thanks. Confirming on Linux current trunk as well. Is the problem that the JS wrapper (which is what the custom prop is set on) is attached to the document and when we switch documents we get a different wrapper?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Comment on attachment 112186 [details] full test really does not work in 1.1, 1.2a, 1.3a, NS 7.0, but most likely works in 1.3b (i have not tested personally - this is from Ruslan Ismailov)
No, I say that I could not reproduce it on previous version of testcase.
Sorry, but could not this be a desired behaviour? I add a following button to iframe: <input type="button" value="Show Custom Att" onClick="parent.showCustomAtt()"> And found, that customAtt in thos case could be obtained from iframe, but not in mainfraime -- so it is look like data protection.
There should be no data protection issues if both frames come from the same site. And no, this is not desired behavior, imo.
Mass-reassigning bugs to email@example.com
Assignee: jst → dom_bugs
The original summary for this bug was longer than 255 characters, and so it was truncated when Bugzilla was upgraded. The original summary was: In some js method new Option is created and some custom attribite is assigned to it, then this Option is added in some Select; if method is called from the same page where Select is located, custom attribute is always kept by Option, BUT in Mozilla if method is called from the page in the IFRAME - custom attribute is lost irretrievably.
Assignee: general → nobody
QA Contact: desale → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.