Closed Bug 640800 Opened 14 years ago Closed 14 years ago

setting select.size=0 in DOM causes exception

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: adam, Assigned: mounir)

References

Details

(Keywords: regression, Whiteboard: [fixed by bug 639175])

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

This bit of JS, breaks FF4, but worked fine in FF3:

<script>
  var newSelection = document.createElement('select');
  newSelection.size=0;
</script>

Reproducible: Always

Steps to Reproduce:
1. Put he above JS snipped on any HTML page
2. view that page
3. look in error console
Actual Results:  
Get :

Error: uncaught exception: [Exception... "Index or size is negative or greater than the allowed amount" code: "1" nsresult: "0x80530001 (NS_ERROR_DOM_INDEX_SIZE_ERR)" location: "http://localhost/.. blah blah ... .html Line: 70"]

Expected Results:  
Should be fine and render a box with the same properties as select.size=1 ?
Perhaps this changed for html5

The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero.

http://www.w3.org/TR/html5/the-button-element.html#the-select-element
Yes, it probably did, but it might be good for FF to simply treat select.size=0 as select.size=1, or maybe ignore it and fall back to defaults, or perhaps throw a warning.

Throwing an exception sounds a bit harsh if previous FF versions (and all other browsers) happily handled it.
Mounir, looks like another site hitting the regression from bug 551846. (Three in a week after 9 months!)
Blocks: 551846
Severity: major → normal
Component: General → DOM: Core & HTML
Depends on: 639175
Keywords: regression
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Whiteboard: [should be fixed by bug 639175]
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → mounir.lamouri
Adam, I was wondering how you happened to run into this at this late date.  Was it in code you were writing just now, or was the release candidate the first version of Firefox 4 that you tested on some existing code?
Boris,

Testing FF4 was on the todo list, but just never got done unitl this week when we realised RC1 was here!

Totally our fault, priorities gone wrong. That will teach us :-) I think more attention will be paid to browser betas in the future....

The JS code is pretty old with quite a few tweaks to make it behave in other browsers. It is deployed on a lot of websites in the UK, so would be a real pain to update every single copy....
Status: NEW → ASSIGNED
This should be fixed in current trunk.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [should be fixed by bug 639175] → [fixed by bug 639175]
Target Milestone: --- → mozilla2.2
It should be fixed with the release of Firefox 4.0.1 (next minor release).
You need to log in before you can comment on or make changes to this bug.