Closed
Bug 311101
Opened 19 years ago
Closed 19 years ago
javascript fails to throw exception
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugs, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
621 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004 Firefox/1.6a1 Instead of throwing an expected exception, this JavaScript code just stops executing. var sCurrentLocation = ""; try { sCurrentLocation = String( parent.outerFrame.innerFrame.location ); } catch ( ex ) { sCurrentLocation = ""; } ... Reproducible: Always Steps to Reproduce: Expected Results: An exception should have been thrown and code should have resumed executing.
Comment 1•19 years ago
|
||
Something like this?
Updated•19 years ago
|
Component: General → DOM
Product: Firefox → Core
Version: unspecified → Trunk
Updated•19 years ago
|
Assignee: nobody → general
QA Contact: general → ian
Comment 2•19 years ago
|
||
Strange I get an alert with the url of bugzilla and alert 3, but I would expect alert 'failed' and alert 3.
This test case isn't what I'm experiencing as this case works the same in both 1.0.6 and 1.5 Beta 2. What I'm experiencing works in 1.0.6, but not in 1.5 Beta 2. I'll try to narrow down a test case which shows the problem.
Comment 4•19 years ago
|
||
Brad, any update on the testcase?
I've been a bit too busy to write up a test case that shows the bug, but I can walk you through reproducing it in the application where I am experiencing it. http://www.sane.com/demo/NetTracker/web/index.html 1. In the menu on the left, click "Visitor Analysis" 2. Click "Host" 3. Click the link "pppch158134.du.dacom.co.kr" This link loads a page off-site to perform a domain lookup. The menu at the left no longer functions as far as loading pages into the main frame. This works correctly in released versions of Firefox (and every other browser I've tried), but not in the daily build as of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051017 Firefox/1.6a1. Sorry I don't have anything more concise.
Comment 6•19 years ago
|
||
Ok, this regressed between 2004-07-21 and 2004-07-22: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-07-21+09%3A00%3A00&maxdate=2004-07-22+10%3A00%3A00&cvsroot=%2Fcvsroot Not really sure which checkin caused this change in behavior, though.
Updated•19 years ago
|
Keywords: regression
Comment 7•19 years ago
|
||
Ok, I tried backing out with bug 245890 and bug 252289, but they don't seem to be the cause of this regression. bsmedberg mentioned bug 242234 as a possible cause.
Comment 8•19 years ago
|
||
Hmm, this is WORKSFORME now with 2005-10-28 trunk build and 2005-10-29 branch build. Brad, could you verify?
WORKSFORME as of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Comment 10•19 years ago
|
||
Ok, great! Marking WFM then.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•