Closed Bug 85725 Opened 23 years ago Closed 16 years ago

nls.net - Selecting member to add to private section erases all existing users

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gmeadow, Unassigned)

References

()

Details

(Keywords: dataloss, qawanted)

Attachments

(5 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+) Gecko/20010612 BuildID: 2001061204 Using Mozilla build above (overnight build), and .90 and .91, when working as a manager or administrator, and adding member to access private sections, there are two frames displayed. The right one, is a list of all memebers of that WebBoard conference who can access that area. To remove a member, you click their name, and they are removed when you submit the new list. The left frame is used to select members to ADD to that private area. When you click their name in the left frame, it's SUPPOSED to add their name to the TOP of the list in the right frame (it's in a scrolling list box). You pick all the people you want to add, then click SUBMIT in the right frame, and the list gets re-sent to the SQL database and access to the private section is set for that list of members. What's happening with Mozilla, and luckily I found this on a private section with only 4 members, is that when you click the name in the Left frame to add to the right, the entire list of people with access is ERASED, and all that's left, is the new user. If you go to add a second new person, that name replaces the one that was previously added. To double check that I was seeing things correctly, I clicked Submit, and re-accessed the site and area with IE 6, and NN4.77, and there was only one member with access to that private section. I re-added them with NN4.77, and that worked properly, each person was added to the top of the list, and when submitted, all were added. I tried this a second time with the above build of Mozilla, and had the same consequences, any addition of a name to the access list, removed all others, so it is repeatable. I know that you don't have access to a WebBoard system there to test against, but I am willing to open a private test board for you at my site, and let you access there to see what's happening. It will need probably 3 or 4 actual people to join, so there is a name base to work from, but that can be done. If you want me to do that, please send an email to gmeadow@home.com, and I'll get the site setup, and send back an email with they url and how to "join". Once several people have joined, I'll need their names, so I can set them up with Manager status so they can access that section of the site. I've also posted this bug on the O'Reilly WebBoard support area. Recently, WebBoard has been purchased by the company Chatspace, and they are taking over further development and support for this product. I requested that if they were NOT following the Mozilla builds, at least the Milestone builds, that they should be, and testing against WebBoard so that they can direct any comments or problems your way as well. Hope all this makes sense. Reproducible: Always Steps to Reproduce: 1. We'll have to set up a special Mozilla WebBoard for you to reproduce this. 2. 3. Actual Results: All tests reported in the description above Expected Results: See above I'm willing to do anything I can to get this sorted out. Just let me know. (I don't work for O'Reilly or Chatspace, but am a user of their product, and manage 7 separate areas on one site.)
Setting up that webboard would be much appreciated. Could you just comment in the bug once you've done that?
OK. Here's what needs to be done to access the test site. I've created a WebBoard "board" at the following url: http://webbd.nls.net:8080/~mozilla When you go there, you will be presented with a login screen. Click NEW MEMBER, and fill out the registration form. The system will email you your initial password within a minute or two. Go back to the above url and login within 24 hours (the system cancels any pending registration not accessed within 24hours, AND if the email bounces (make sure your email address is correct) cancels pending registrations if the "Welcome" email comes back.). When you get back to the site, it's best to copy/paste the password, as it's case sensitive, and uses l's and 1's, and 0's and O's. <grin>. Once you do that, and you get it, there will be ONE conference visible. Please click on that, and then click POST in the top navigation bar, and leave me a message that you're there. I will then ADD your access to the PRIVATE section (you won't see that section till I enable access), and add you as a Manager of the board. Manger status will allow you to then see additional options where you can then access the manager/administrator menus. Once you're there, I'll post another message on the board, describing how to show the bug. Glenn Meadows.
I'm there. Gerv
Severity: blocker → critical
Setting bug Status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
The error from the JS console is: Error: uncaught exception: [Exception... "Failure" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://webbd.nls.net:8080/~mozilla/userselect?137 :: <TOP_LEVEL> :: line 113" data: no] I should have a reduced test case with you soon. Gerv
I'll await your notice for a build to test. Thanks.
Attached file Testcase (deleted) —
This seems to be a problem with the simple routine which copies each element in the <option> array down one. Over to DOM Level 0 for a look. Heads up, lads - this is a bit nasty. Glenn: when I said a testcase, I meant a simple HTML file that exhibits the problem, not a patch to fix it or a build with a fix. :-) We aren't there yet... Gerv
Assignee: rods → jst
Component: Form Submission → DOM Level 0
Keywords: mozilla1.0
OS: Windows 2000 → All
QA Contact: vladimire → desale
Ok, today I've play a little bit around with the source! My own testcase do function, but it use an other method (replace with holder). Ok, back to the other testcase: 1.st: the first round in the for loop: ops[z+1] = null ops[z] = [HTMLOption] ops[z+1]=ops[z] ops[z+1] = null ... but should be ops[z]=[HTMLOption] ... ugh! 2. Ok, to resolve this you can add before a element so that ops[z+1]!=null (So that realy an element is there, which you can replace!) But: ops[z]=[HTMLOption] ops[z+1]=[HTMLOption] ops[z+1]=ops[z] ops[z+1] = null ... but should be ops[z]=[HTMLOption] ... ugh! 3. Ok, I'm a bad people and so do bad things: remove the special add from 2.) Now replace ops[z+1]=ops[z] with ops[z]=ops[z] ops[z]=[HTMLOption] ops[z+1]=null ... Yes, right! in line ops[z]=ops[z] <crash> The Browser crash's ... but why? (Hadn't make a talkback) 4. Ok, I'm more bad replace ops[z]=ops[z] with ops[z]=null hmmm, all elements are cleared and the last one becomes Fred Flintstone! all is right! So, I hope it helps!
The second attached testcase now works in mozilla AFAICT, but the first one doesn't work, and AFAICT it shouldn't do what the script developer intended. The first testcase does this in the loop: ops[3] = ops[2]; set ops[3] to ops[2], this will get opt[2] and add it to ops since there are only 3 items in ops. When this is done, there are still 3 items in ops, as there should be. ops[2] = ops[1]; set ops[2] to ops[1], this will get ops[1] and replace opt[2] with opt[1], when opt[2] is replaced with opt[1], opt[1] is removed from it's old parent (the same select) and then re-inserted at the correct position. The result of this is of course that opt[1] is removed from ops and ops[2] is replaced with ops[1], once this is done there are 2 items in ops, as there should be. ops[1] = ops[0]; same as above, once this is done there's only one item left in ops, as there should be. Marking WORKSFORME, since I don't see a problem in mozilla here any more, if the original site still isn't working, please reopen if the problem still exists.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
1.) Why you don't read the comments to my testcase? It was only the upside down version of testcase 1 to demonstrate that this is working. In my comment also stands thinks which makes errors. 2.) The testcase 1 and the website also should work ... cause it had worked/is working in NS4.x and IE!! So I'm for reopening! (I can't do it, I've no button for that)
I think what jst effectively said is: "This is a bug in NS4 and IE in the way they handle the first testcase". The implication is "Code that depends on correct behavior will work in Mozilla but break in IE and NS4" and the further implication that "we don't want to break such code unless there's a compelling reason to (like lots of sites depending on the broken behavior)".
Why does ops[2]=ops[1] remove from ops[1] its old parent and is reinserted? Like jst had sayd. You only say with that line that the object in ops[1] is also set in ops[2]. But it don't say tat ops[1] is to remove. And why does ops[number]=ops[number] crashes mozilla? It shouldn't do this! Also ops[x] means normaly member x from array/record ops ... why have ops[x] as parent ops[x-1] ???
An option can not be in the DOM tree in more than one place (i.e. it can not occure more than once in any circumstances), so if you replace opt[1] with opt[2] opt[1] will first be removed from its old place in the DOM tree and then reinserted, in this case it happens to be reinserted in the same place where it was removed from. See the DOM spec for more information.
Johnny, or others, can someone point me to this part where that in the DOM Documentation stand what Johnny said? I haven't found it!
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-1950641247 To quote the method descriptions (note the last sentence in each description): appendChild Adds the node newChild to the end of the list of children of this node. If the newChild is already in the tree, it is first removed. insertBefore Inserts the node newChild before the existing child node refChild. If refChild is null, insert newChild at the end of the list of children. If newChild is a DocumentFragment object, all of its children are inserted, in the same order, before refChild. If the newChild is already in the tree, it is first removed. replaceChild Replaces the child node oldChild with newChild in the list of children, and returns the oldChild node. If newChild is a DocumentFragment object, oldChild is replaced by all of the DocumentFragment children, which are inserted in the same order. If the newChild is already in the tree, it is first removed. What this testcase is doing is essentially a call to insertBefore()
Boris: Thanks for sending. From the view of the add Method of the HTMLSelectElement it is right. Add a new element to the collection of OPTION elements for this SELECT. This method is the equivalent of the appendChild method of the Node interface if the before parameter is null. It is equivalent to the insertBefore method on the parent of before in all other cases. But with ops[3] = ops[2] I don't use the add of HTMLSelectElement function and ops is a HTMLCollection and no note! And the most had changed. It looks like it had to function! The following will also function: var elements = document.forms[0].elements; alert(elements); -> [object HTMLCollection] elements[1]=elements[0]; alert(elements[0]); -> [object HTMLSelectElement] alert(elements[1]); -> [object HTMLSelectElement] alert(elements[2]); -> JSError (right!) alert(elements.length); -> 1 (But there are 2 inside!) elements[1] isn't shown and elements.length is one but it works and HTMLForm has no add function! var ops = document.forms[0].elements[0].options alert(ops); -> [object HTMLOptionCollection] (Hmmm, yours DOM interpretion?) ops[1]=ops[0]; alert(ops[0]); -> [object HTMLOptionsElement] alert(ops[1]); -> [object HTMLOptionsElement] alert(ops[2]); -> JSError (right!) alert(ops.length); -> 1 (should also 2) Since this works (what doesn't work at the time as the bug was started) I think only the length counter of the HTMLCollection is false (or memory leak?) correct me am I false. Reporter: It's saver to use: document.forms[x].elements[y].add(NewOption,document.forms[x].elements[y].options[0]) for adding a new option on first position in select element. (My comment 10 is deprecated. In comment 15 the crash is also deprecated!)
Does mozilla function differently than Netscape 4.x or IE does wrt: opt[x] = opt[y]; ? If so, IE and Netscape probably create a new option when assigning into the options array, if that's the case, we can make mozilla do that too. Could someone tests that?
Alexaner, you asked: > can someone point me to this part where that in the DOM Documentation stand what > Johnny said? I haven't found it! The DOM spec doesn't define this DOM0, ECMAScript specific behavior, it's all about backwards compatibility. If you have a simple testcase showing mozilla working differently than Netscape 4x or IE wrt opt[x] = ..., please attach the testcase and reopen this bug.
Attached file Testcase to demonstrate (deleted) —
Tested with NS 4.77 I've also try it with IE 6.0 but ther it works like in Mozilla. Is "ops[x] =" only DOM0/ECMAScript specific and not for DOM1/2 ? But then how I add an element to a form in pure DOM1/2?
> But then how I add an element to a form in pure DOM1/2? Using some combination of cloneNode(), appendChild(), insertBefore(), I would say. The entire [] notation is DOM0. DOM1/2 has .item() for getting things from lists and methods on nodes to append/insert things to/in lists
A yes, I remember ... the HTMLCollections was only a "live" element, which represent the childNodes. So I think var ops = document.forms[0].elements[0].options; ops[1]=ops[0]; should be the same like if ops[1] was null! document.forms[0].elements[0].options.appendChild( document.forms[0].elements[0].options.childNotes[0].cloneNode(false)) if ops[1] != null! document.forms[0].elements[0].options.replaceChild( document.forms[0].elements[0].options.childNotes[0].cloneNode(false), document.forms[0].elements[0].options.childNotes[1]) Am I right?
This bug is NOT fixed in build 2001122106. I just went to the Mozilla test webboaard that I set up, and tried to ADD a member to a private section, and the action of adding a name via selection in the left frame (adds name to the access list in the right frame) ERASES ALL MEMBERS PREVIOUSLY ADDED. THIS IS NOT GOOD, and is NOT resolved. It makes it IMPOSSIBLE to use Mozilla and NETSCAPE 6.x for site management on WebBoard. I've stated before, I'll add ANYONE on the test team to MANGER STATUS, so that they can PLAY with the member access to the private section and see the problem. So far, only ONE person has requested manager status, and that is Gervase Markham. I would think it would be difficult to test the fix if one has not actually tested against an operating system where the bug is present (Frustrated that this is marked "RESOLVED WORKSFORME" if you haven't been to the site and tested it against a live working system. Sorry for the frustration, but I'm willing to provide anyone access to test this. I'd LOVE to use Mozilla for my work on the 7 WebBoards I maintain, and there are others that wish to use it as well, but with this bug, it's impossible to use. Glenn Meadows.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Severity = Medium [Since its dataloss] Visibility = Medium [Gets one point of compatibility with other browsers. URL above works on NS4.x & IE. Also one more point of Compliance] Priority = Visibility * Severity Priority = p3 adding word "qawanted" because I'm setting this priority on available data & if someone feels otherwise then please investigate this more & feel free to change this priority.
Keywords: qawanted
Priority: -- → P3
Johnny you say it's no problem to let it work like NS < 5 and IE and I've provide the testcase. Would be nice if someone can let it work. :-) I know it is only for backward compatibility, but it should easy to make it work.
Attached patch Patch to fix (deleted) — Splinter Review
This makes us act like NS4 (and not like IE5, which acts like we do). Fabian? jst? What do you think?
Continued compatibility with nn4 is a dead end. I say let's be compatible with the semantics of the W3C DOM and IE5 so that we can live on the same code fork instead of making web developers support distinct forks.
Comment on attachment 79170 [details] [diff] [review] Patch to fix sr=jst
Attachment #79170 - Flags: superreview+
Oh, sorry, wasn't paying attention to the discussion here, I just looked at the patch and sr'ed. I agree, compatibility with IE and the specs is far more important than compatibility with 4x at this point. Should we WONTFIX this one?
Over to evangelism...
Assignee: jst → doron
Status: REOPENED → NEW
Component: DOM Level 0 → US General
Product: Browser → Tech Evangelism
QA Contact: desale → zach
Hardware: PC → All
Version: other → unspecified
There is no definition in the specs. And from the view of a record field it realy makes no sence that ops[1]=ops[0] removes firstly ops[0] before it overwrites ops[1]. So I think IE5's interpretation is more a bug then the old NS4x form. The live elements like NodeList are an easy form of handle with the document and so it would be easier to let it work. And I think compatible with NS4x goes over compatible with IE5 if there are websites which don't work then.
Does the website this bug is reported against work with IE? (I can't test it in IE). If so, why?
the test forum is doa -> wfm
Status: NEW → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
Summary: Selecting member to add to private section erases all existing users → nls.net - Selecting member to add to private section erases all existing users
The website doesn't exist any more but that don't say, that it work like exspected. In other words we haven't interpreted how does it have to work. There are testcases so we do not need the Website. In some time I will post more.
I've found faster time as I thought. About the Testcases with NS4.77, IE5.5 and mozilla 2002120908 all on win95 1. Testcase: (up to down) NS: works like exspected ... the first item ist doubled. IE: doesn't work ... object haven't such a method in line 11 MO: do not work like expected ... all elements are removed, not the first 2. Testcase: (down to up with one holded back) NS: don't work as exspected ... all items become Fred Flintstone IE: Works as expected ... Fred Flintstone is added on first position MO: Works as expected ... Fred Flintstone is added on first position 3. Testcase: (only ops[x] = ops[y]) NS: Works as expected ... A, A, C IE: don't work as expected ... A, C and Error on line 6 MO: don't work as expected ... A, C 4. Newest Testcase: HTMLCollection vs. HTMLOptionsCollection (Not correct in mozilla ... please add the plural!) ... HTML 4.01 Validated. button 1: NS+MO: Works like in Testcase 3 (it's the same, but with alert output) IE: Breaks at alert(ops[0]); button 2: NS: Go through all, no errors, button is not copied/overwritten, alerts not correct named IE: Hold on elements[1]=elements[0];, button is not copied/overwritten, first allert not correct named MO: Go through all, no errors, button is not copied/overwritten, alerts are correct button 3: NS: Go trough all, no errors, button is copied but not viewed, buttons.length is 1(!) but buttons[1] exists, alerts not correct named IE: Go trough all, no errors, button is copied but not viewed, buttons.length is 1(!) but buttons[1] exists, alerts not correct named MO: Go trough all, no errors, button is copied but not viewed, buttons.length is 1(!) but buttons[1] exists All together it doesn't work like exspected (IE 6.0 and others not tested ... hope I can do it at home) in point of my view and I see it from the array side where ops[x]=ops[y] is possible and no data is removed. In the W3C DOM Level 2 HTML I don't find a hint on that. There is also no definition of the ops[x] ... you have for HTML(Options)Collection only length(), item(), namedItem(). (Also for DOM 2 Core the NodeList and NamedNodeMap have no [x] possibilitys) So we have three ways: 1.) Accept opt[x]=opt[y] done by replaceChild(NodeX, NodeY) (btw. appendChild(NodeY) after DOM 2 Core like it is yet done in HTMLOptionsCollection (but not HTMLCollection ??) 2.) Accept opt[x]=opt[y] done by replaceChild(NodeX, cloneChild(NodeY) (btw. appendChild(cloneNode(NodeY)) after DOM 2 Core like it is done in NS 4.x and is expected on the view point of an array. 3.) Reject opt[x]=opt[y] because it isn't defined any where and looks like the cleanest way, but some things will become a bit more complicated. http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#td-live doesn't say, that you can change Nodes via the live object but it also do not reject such things. I haven't found a testcase for this -> http://www.w3.org/2002/11/DOM-Level-2-HTML-Results/dom2-html-matrix.html and http://www.w3.org/2002/11/DOM-Level-2-HTML-Results/Mozilla-5.0-X11-Linux-i686-en-US-rv-1.2b-Gecko-20021016.html also says nothing about a problem but I think, there is no testcase. Reopened for discussion.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached file 4. Testcase (deleted) —
see note above
This is in the wrong component. If you care about this getting fixed in the DOM, assign it to the DOM.
Johnny have assigned this to Tech Evangelism not me. I thought there will be discussed about such issuse and not in the DOM space where bugs will be fixed and not discussed if it's a bug or not. I'm not familiar with that so please do it for self.
Read comment 32. What has changed since then?
Nothing, because no one have answered or think about it after/about my point of viewing to this. And today I have write a new Overview about the unclear things in it all to start again the discussion. For me it isn't a wontfix cause of the different handling of HTMLCollection and HTMLOptionsCollection which isn't clear and makes no sence. I have bring 3 ways in comment 38 and every way follows with a Bugreport and need work. Cause it's not clean and proper.
1) The testcase you attached is unusable, as it does not list the expected behavior. 2) "There is also no definition of the ops[x]" -- yes, there is. The ECMAScript bindings define it. 3) Could you _clearly_ explain in words or with a _small_ (not everything-and-the-kitchen-sink) testcase what this difference between "HTMLCollection" and "HTMLOptionCollection" is? 4) "For me it isn't a wontfix" -- you are not the module owner.
1.) I'll be better next time. Hopefully. It's unknown how it should work, so it is unknown how does it works wrong. But I hoped that my comment is clear enough for that all. 2.) I've wrote it not very clear but excuse english is not my mother language. If HTMLCollection[x]; a dereference to HTMLCollection.item(x); then is HTMLCollection[x] = HTMLCollection[y]; the same as HTMLCollection.item(x)=HTMLCollection.item(y); and this is an Error (invalid assignment left-hand side). Am I wrong here? 3.) Ok, I'll try. 4.) But it's my opinion. And close a bug, couse of that a page exist any more and there are testcases is not a god thing. It's to late today testcase for 3.) comes tomorrow.
> Am I wrong here? Nope. According to the DOM spec, that should be an error, as far as I can tell. The only reason it's not is for DOM-0 reasons (compatibility with other browsers). Which means it has to behave compatibly with other browsers. In this case, the "other browsers" to be compatible with is IE, since compat with NS4 doesn't really make much sense at this point. _That_ is why the bug was closed as WONTFIX -- because for the part of this behavior that is an extension of the spec our extension is compatible with IE's. It was _not_ because the site no longer exists.
tech evang june 2003 reorg
Assignee: doron → english-us
Status: REOPENED → NEW
QA Contact: zach → english-us
the link as provided in the URL box is no longer valid apparantly.
The link is 404 , marking fixed
Status: NEW → RESOLVED
Closed: 22 years ago16 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: