Closed Bug 344067 Opened 18 years ago Closed 18 years ago

Passing +-Infinity or NaN as index to options.add() halts script execution instead of throwing an exception

Categories

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

1.8 Branch
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: ddkilzer, Unassigned)

Details

(Keywords: testcase)

Attachments

(3 files)

When passing an index value of negative infinity, positive inifinity or NaN to options.add(), JavaScript execution simply halts in the current script rather than throwing an exception.  Tested on Firefox 1.5.0.5rc3 on Mac OS X 10.4.7 (8J135/PowerPC).

Note that I have confirmed that this has been fixed (an exception is thrown instead of execution halting) in the Firefox nightly 3.0a1 build for July 09, 2006.

Found while writing test for options.add() implementation on WebKit.

http://bugzilla.opendarwin.org/show_bug.cgi?id=9179
The test case should print a line after the bug description starting with a green "PASS" word.
Attached file Test case for NaN
The test case should print a line after the bug description starting with a green "PASS" word.
The test case should print a line after the bug description starting with a green "PASS" word.
Summary: Passing +-Inf or NaN as index to options.add() halts script execution instead of throwing an exception → Passing +-Infinity or NaN as index to options.add() halts script execution instead of throwing an exception
(In reply to comment #0)
> Note that I have confirmed that this has been fixed (an exception is thrown
> instead of execution halting) in the Firefox nightly 3.0a1 build for July 09,
> 2006.

That means it will work in Gecko 1.9 (FF 3.0).  Because FF 1.5 and 2.0 are based off of the stable Gecko 1.8 branch, they likely won't get the fix that fixed this unless the drivers are convinced it is important.  If you don't think it's  important, go ahead and well mark this bug WORKSFORME.  If you do think a fix for this is important, please explain why this is important for the branches.
(In reply to comment #4)
> (In reply to comment #0)
> > Note that I have confirmed that this has been fixed (an exception is thrown
> > instead of execution halting) in the Firefox nightly 3.0a1 build for July 09,
> > 2006.
> 
> That means it will work in Gecko 1.9 (FF 3.0).  Because FF 1.5 and 2.0 are
> based off of the stable Gecko 1.8 branch, they likely won't get the fix that
> fixed this unless the drivers are convinced it is important.  If you don't
> think it's  important, go ahead and well mark this bug WORKSFORME.  If you do
> think a fix for this is important, please explain why this is important for the
> branches.

If no one else thinks it's important enough to fix on the branch, then I don't think it's that important to fix.  I was just noting differences while working on the WebKit implementation.  I think WONTFIX would be a more accurate resolution status as the current implementation in Gecko 1.8 doesn't work the way it should.

Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
This bug is for the 1.8.0 branch only. The test cases work properly in windows and mac os x for minefield and bonecho from today. I don't see that this is a javascript engine bug at all but is more of a dom issue. flipping there to let them deal with it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
> dom0
Assignee: general → general
Status: REOPENED → NEW
Component: JavaScript Engine → DOM: Level 0
OS: Mac OS X 10.4 → All
QA Contact: general → ian
Hardware: Macintosh → All
WORKSFORME, since this has been fixed, we just don't know by what.
Status: NEW → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
(In reply to comment #8)
> WORKSFORME, since this has been fixed, we just don't know by what.

It's only fixed on the Trunk, though, not the 1.8.0 Branch.
(In reply to comment #9)
> It's only fixed on the Trunk, though, not the 1.8.0 Branch.

Yes, I realize that. If you'd like, you could go ahead and find a "fixed-range" and determine which bug fixed this on the trunk, and then it could be evaluated for inclusion on the branch. I suspect it was an unrelated change though, and since this bug is not a regression, it isn't very likely to be included on the 1.8.0 branch unless someone has a strong desire for it to be fixed there.
(In reply to comment #10)
> Yes, I realize that. If you'd like, you could go ahead and find a "fixed-range"
> and determine which bug fixed this on the trunk, and then it could be evaluated
> for inclusion on the branch. I suspect it was an unrelated change though, and
> since this bug is not a regression, it isn't very likely to be included on the
> 1.8.0 branch unless someone has a strong desire for it to be fixed there.

Fair enough.  I'm not going to pursue this any further.  If someone else wants to take up the torch, though, feel free!
just to clarify: it is broken on 1.8.0, but works for me on 1.8 and 1.9.
Status: RESOLVED → VERIFIED
It was fixed on the 1.8 branch between July 6 and July 10 (today), in case anyone is interested.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: