Opera Bug? Unselecting/removing options

M

Matt Kruse

Using the latest version of Opera 8.5, this test case:

--------------------------------------------------------
<select name="sel" multiple="true" size="3">
<option value="option1" selected>option1</option>
<option value="option2" selected>option2</option>
<option value="option3" selected>option3</option>
</select>

<input type="button"
value="Unselect the first option, then remove the second option"
onClick="this.form.sel.options[0].selected=false;this.form.sel.options[1]=null;">
--------------------------------------------------------

results in the 2 remaining options to both be selected.
However, the first option should no longer be selected.

Am I wrong, or is this an Opera bug?
Or is this somehow acceptable behavior?
 
S

Stephen Chalmers

Matt said:
Using the latest version of Opera 8.5, this test case:

--------------------------------------------------------
<select name="sel" multiple="true" size="3">
<option value="option1" selected>option1</option>
<option value="option2" selected>option2</option>
<option value="option3" selected>option3</option>
</select>

<input type="button"
value="Unselect the first option, then remove the second option"
onClick="this.form.sel.options[0].selected=false;this.form.sel.options[1]=null;">
--------------------------------------------------------

results in the 2 remaining options to both be selected.
However, the first option should no longer be selected.

Am I wrong, or is this an Opera bug?
Or is this somehow acceptable behavior?

It behaves as expected in Opera 7.54 but not in 8.51.
If it helps, reversing the order of the instructions clears the problem
 
M

Michael Winter

On 17/12/2005 20:41, Matt Kruse wrote:

[snip]
<input type="button"
value="Unselect the first option, then remove the second option"
onClick="this.form.sel.options[0].selected=false;this.form.sel.options[1]=null;">
[snip]

Am I wrong, or is this an Opera bug?

It would seem to be. The behaviour is the same using the remove method
as well. Reversing the order of the operations (remove first) avoids the
problem.

Have you reported this?

[snip]

Mike
 
M

Matt Kruse

Michael said:
It would seem to be. The behaviour is the same using the remove method
as well. Reversing the order of the operations (remove first) avoids
the problem.
Have you reported this?

I just did, yes. I was doing some regression testing and grabbed the latest
Opera. I was shocked to find it erroring out on such simple things. I
thought maybe I was missing something obvious.

It looks like when an option is removed, all options are set back to their
'defaultSelected' status. Bummer. They can spend lots of hours on gestures
and skins, but can't get basic options collections working right :)
 
V

VK

Matt said:
I just did, yes. I was doing some regression testing and grabbed the latest
Opera. I was shocked to find it erroring out on such simple things. I
thought maybe I was missing something obvious.

It looks like when an option is removed, all options are set back to their
'defaultSelected' status. Bummer. They can spend lots of hours on gestures
and skins, but can't get basic options collections working right :)

I guess that while refactoring SELECT (on add/remove options) Opera
gives priority to hardcoded settings over runtime scripted properties.
If *all properties* are runtime scripted then it works as expected:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF">
<form method="post" action="">
<select name="sel" size="3" multiple>
<option value="option1">option1</option>
<option value="option2">option2</option>
<option value="option3">option3</option>
</select>

<input type="button"
value="Unselect the first option, then remove the second option"
onClick="
with (this.form.sel) {
options[0].selected = true;
options[1].selected = true;
options[2].selected = true;

options[0].selected=false;
options[1] = null;
}
">
</form>
</body>
</html>

Opera team always positionned themselves as holly keepers of *true* CSS
ans HTML layout rules. So you may file a complain but I guess that the
response (if any) will be a la PointedEars bunch of doc quotes and
explanations how one really should read them.

P.S. Also note that "multiple" is a flag and not an attribute/value
pair. Opera is rather picky on it, so say multiple="on" is ignored as
invalid declaration.
 
M

Michael Winter

On 18/12/2005 09:22, VK wrote:

[snip]
Opera team always positionned themselves as holly keepers of *true*
CSS ans HTML layout rules.

No, they just try to produce a decent browser that implements the
relevant standards as closely as feasible. A laudable goal for any
browser vendor.

[snip]
P.S. Also note that "multiple" is a flag and not an attribute/value
pair. Opera is rather picky on it, so say multiple="on" is ignored as
invalid declaration.

I didn't notice that mistake in Matt's original post. It wasn't the
focus of my attention.

Indeed, boolean attributes in HTML do not have values like yes/no,
true/false, or on/off. The mere presence of the attribute itself
indicates true, and its omission, false. If it is given a value, that
value must be itself. That is,

<select ... multiple="multiple">

However, the value is better omitted in HTML.

That said, it makes no difference with regard to the observed behaviour
in this case.

Mike
 
V

VK

Michael said:
No, they just try to produce a decent browser that implements the
relevant standards as closely as feasible. A laudable goal for any
browser vendor.

The OP question was "is this SELECT behavior a bug to report or an
intentional feature". Actually it was not a question but a statement:
"this is a bug".

It seems though that it is an intentional feature as illustrated by my
test case: HTML-hardcoded attributes have priority over scripted ones.
This behavior is reproducible up to the most recent Opera 8.51

It is a shame that this issue appeared too close to the holidays.
I'm pretty much sure that the behavior choice both in Firefox and Opera
has been made based on the same documents from the same W-known
organization. One could ask for official Mozilla Foundation reading of
the relevant paragraphs, then the same from Opera, then ask some local
standards' guru to comment on both positions. That would be a lot of
evangelism Christmas fun we're going to miss now :-(
:)
 
M

Michael Winter

On 18/12/2005 15:01, VK wrote:

[snip]
The OP question was "is this SELECT behavior a bug to report or an
intentional feature".

That's paraphrased, but essentially correct.
Actually it was not a question but a statement: "this is a bug".

I think it really was a question. Matt may have been of the opinion that
is a bug, but wanted a second opinion nevertheless. You'd have to ask
him, though.
It seems though that it is an intentional feature as illustrated by my
test case: HTML-hardcoded attributes have priority over scripted ones.
This behavior is reproducible up to the most recent Opera 8.51

No, it isn't. It is a new 'feature' in Opera 8.x only. No other version
I have, from 6.06 to 7.54, behaves the same way. That may indicate
either a fundamental change of opinion within the development team, or a
bug that slipped through regression testing - something that only Opera
Software can comment upon.

[snip]

Mike
 
V

VK

Michael said:
No, it isn't. It is a new 'feature' in Opera 8.x only. No other version
I have, from 6.06 to 7.54, behaves the same way. That may indicate
either a fundamental change of opinion within the development team, or a
bug that slipped through regression testing - something that only Opera
Software can comment upon.

Yes, guessing game doesn't help too much. As an Opera-specific fix one
could use:
selectObject.options.defaultSelected = false;
selectObject.options.selected = false;
That naturally raises other problems later like form reset behavior.

Interestingly enough explicit attribute removal doen't help:

sel.options[0].removeAttribute(sel.options[0].attributes['SELECTED']);
doen't produce any error by behavior-wise is silently ignored.

As you already noticed, w/o Opera, Inc. direct answer it is a pure
speculation, but the whole behavior seems to be too "logic consistent"
for a bug. I'm still affraid that someone in Opera team read W-paper in
the direct rather than in abstractically-spiritual way.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top