Closed Bug 669107 Opened 14 years ago Closed 10 years ago

Changing window.location in Javascript to a URL with an unknown scheme DoSes the user with a dialog

Categories

(Core :: JavaScript Engine, defect)

5 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: min, Unassigned)

References

(Blocks 1 open bug, )

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110622232440 Steps to reproduce: 1. Didn't have the Google Talk browser plugin (or whatever else is necessary to handle the link) 2. Went to http://min.dvir.us/contact/ 3. Clicked on the gtalk: link Actual results: 1. Got a dialog box saying Firefox doesn't know how to handle the link. 2. Clicked "OK". 3. Back to step 1. Expected results: 1. Get a dialog box saying Firefox doesn't know how to handle the link. 2. Click "OK".
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Offending Javascript is in http://min.dvir.us/static/style/blue/open_close.js, line 26.
Blocks: eviltraps
OS: Other → All
Please use URL as referenced by the bug. http://jsbin.com/osaroc/6/edit for the lazy.
bz, have you seen this? It looks like a bug in the site itself. I tried it in some other browsers, and they don't get the "stuck" behavior, but possibly simply because they navigate to a "I don't know how to handle this" page instead of showing a modal dialog.
The basic issue here is that the location.href set throws because we can't even convert the string to a URI object. Arguably we should load an error page instead; I thought we had a bug on that, but can't find it. In any case, the setter throws. And it looks like jQuery's animate() stuff will just keep calling tick() which calls all the callbacks and only calls stop() if all of them deregistered... which means that if any callback throws we'll keep calling it over and over, never removing it from the timer list. Hence the repeated invokation of the |complete| callback here. I think that's a jQuery bug.
Reproducible for me on Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110728 Firefox/8.0a1
Assignee: general → nobody
The testcase redirects to the error page correctly now (as comment #4 suggested).
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.