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)
Tech Evangelism Graveyard
English US
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.)
Comment 1•23 years ago
|
||
Setting up that webboard would be much appreciated. Could you just comment in
the bug once you've done that?
Reporter | ||
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
I'm there.
Gerv
Updated•23 years ago
|
Severity: blocker → critical
Comment 4•23 years ago
|
||
Adding keywords.
Comment 6•23 years ago
|
||
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
Reporter | ||
Comment 7•23 years ago
|
||
I'll await your notice for a build to test. Thanks.
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
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
Comment 10•23 years ago
|
||
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!
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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)
Comment 14•23 years ago
|
||
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)".
Comment 15•23 years ago
|
||
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] ???
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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!
Comment 18•23 years ago
|
||
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()
Comment 19•23 years ago
|
||
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!)
Comment 20•23 years ago
|
||
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?
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
> 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
Comment 24•23 years ago
|
||
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?
Reporter | ||
Comment 25•23 years ago
|
||
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 → ---
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
This makes us act like NS4 (and not like IE5, which acts like we do). Fabian?
jst? What do you think?
Comment 30•23 years ago
|
||
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 31•23 years ago
|
||
Comment on attachment 79170 [details] [diff] [review]
Patch to fix
sr=jst
Attachment #79170 -
Flags: superreview+
Comment 32•23 years ago
|
||
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?
Comment 33•23 years ago
|
||
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
Comment 34•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
Does the website this bug is reported against work with IE? (I can't test it in
IE). If so, why?
Comment 36•22 years ago
|
||
the test forum is doa -> wfm
Status: NEW → RESOLVED
Closed: 23 years ago → 22 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
Comment 37•22 years ago
|
||
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.
Comment 38•22 years ago
|
||
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 → ---
Comment 39•22 years ago
|
||
see note above
Comment 40•22 years ago
|
||
This is in the wrong component. If you care about this getting fixed in the
DOM, assign it to the DOM.
Comment 41•22 years ago
|
||
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.
Comment 42•22 years ago
|
||
Read comment 32. What has changed since then?
Comment 43•22 years ago
|
||
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.
Comment 44•22 years ago
|
||
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.
Comment 45•22 years ago
|
||
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.
Comment 46•22 years ago
|
||
> 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.
Comment 47•21 years ago
|
||
tech evang june 2003 reorg
Assignee: doron → english-us
Status: REOPENED → NEW
QA Contact: zach → english-us
Comment 48•19 years ago
|
||
the link as provided in the URL box is no longer valid apparantly.
Comment 49•16 years ago
|
||
The link is 404 , marking fixed
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•