45760 - Accessing HTMLOptionElement.selected property unaccessible if Select is hidden

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Kahli Burke]

I have seen this occur with M16, as well as recent daily builds of Mozilla.  I
only have access to WinNT so I'm not sure if it affects other platforms.  I will
leave the OS as WinNT unless someone can reproduce on other platforms.

When a select form element is hidden (display style property set to "none"),
accessing the option.selected property causes an unhandled exeption (in
Javascript) to occur.

If the select form is visible (e.g. display = "block") this does not occur.

Here is the exception:
Error:  uncaught exception: [Exception..."Component does not have requested
interface" code:"-2147467262" nsresult:"0x80004002 (NS_NOINTERFACE)"
location:"http://melvin/guimain/include/investevent.js Line: 361"]

I will attach a test script to help you track it down.

Reproducability: Always
Steps:

1) Load the attachment below.
2) You can change the selections in the select box and test the results by
clicking on the Check Selection link.  Alert boxes will display the object as
well as the value and selected properties.
3) Hide the select box by clicking on the Swap Display link.
4) Click the Check Selection link again and you will see that the JS stops
executing when it tries to access the selected property.  A JS exception should
be generated.

Expected Results: The selected attribute is accessible.
Actual Results: The selected attribute generates a JS exception and the JS
function stops executing.

I am assuming that this is incorrect behavior.  The same test page works in IE5.
 This isn't a case of IE not conforming to the spec is it?  All properties for
HTML elements should be accessible even if the element is not currently
displayed, correct?

Right now I have to use a workaround by creating another array to track the
values of the select box, populating it when the select box is created, and
tracking changes through the onChange event handler for the select element.

Comment 1

[Kahli Burke]

Attachment: Test case that demonstrates this bug

Comment 2

[Bernd Mielke]

*** Bug 45758 has been marked as a duplicate of this bug. ***

Comment 3

[Kahli Burke]

Sorry about the double posting of this bug, I used the browsers back button and
it reposted my submission form to Bugzilla...:)

Comment 4

[Asa Dotzler [:asa]]

confirmed with 071808 mozilla buils on NT4

Comment 5

[Johnny Stenback (:jst)]

Accepting bug and nominating for beta3. The problem here is that the option core
relies on the layout frames for the selection state and if the option is not
displayed there's no frames to ask the state from. The fix for this is to
request the selection state from the presentation state in the presshell (or
context).

Comment 6

[Nisheeth Ranjan]

Marking nsbeta3- for now.

Comment 7

[Johnny Stenback (:jst)]

I looked into the problem with this exception, the following patch fixes the
exception, but this patch doesn't make the selection state of an option element
accessible if the option is not displayed:

Index: html/content/src/nsHTMLOptionElement.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/content/src/nsHTMLOptionElement.cpp,v
retrieving revision 1.57
diff -u -r1.57 nsHTMLOptionElement.cpp
--- nsHTMLOptionElement.cpp     2000/08/23 17:26:11     1.57
+++ nsHTMLOptionElement.cpp     2000/08/29 23:55:28
@@ -222,6 +222,9 @@
 NS_IMETHODIMP 
 nsHTMLOptionElement::GetSelected(PRBool* aValue) 
 {
+  NS_ENSURE_ARG_POINTER(aValue);
+  *aValue = PR_FALSE;
+
   nsIFormControlFrame* formControlFrame = nsnull;
   nsresult rv = GetPrimaryFrame(formControlFrame);
   if (NS_SUCCEEDED(rv)) {
@@ -233,7 +236,8 @@
       *aValue = value.EqualsWithConversion("1");
     }
   }
-  return rv;
+  // else { use nsIPresState to get at the slected state... }
+  return NS_OK;
 }
 
 NS_IMETHODIMP 
@@ -252,7 +256,8 @@
       }
     }
   }
-  return result;
+  // else { use nsIPresState to set the slected state... }
+  return NS_OK;
 }
 
 //NS_IMPL_BOOL_ATTR(nsHTMLOptionElement, DefaultSelected, defaultselected)


Rods agreed to look into the problem with the selection state not being
accessible if the option is inside a hidden select, reassgning. I think this
could be solved by adding code that stores/retrieves the currently selected
state from the nsIPresState in the option code (as I show in the comment in the
patch). We might need to modify the option frame code to work with this as
well...

(removing nsbeta3- for re-evaluation)

Comment 8

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 9

[rods (gone)]

fixed

Comment 10

[ckritzer (gone)]

Marking VERIFIED FIXED on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial