With linux trunk 2005032305, if I try to save a file (via file->save, or right click->save link target as), I get a progress dialog, but it appears to never downloads anything. The Status line is empty, Time Left is Unknown and Time Elapsed is 00:00. In the JS console, I get: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsITransfer.init]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://communicator/content/contentAreaUtils.js :: internalSave :: line 376" data: no] This regressed between linux trunk 2005-03-22-05 and 2005-03-23-05 If I switch to the download manager, everything is fine.
Confirmed Win32 (Windows XP) Marking OS all
OS: Linux → All
The checkin for bug 287107 is the change that broke this Was there a problem with the patch or did it just expose a problem in file handling code?
OS: All → Linux
I believe this due to the patch in bug 287107, and is not the fault of the download manager implementation.
Assignee: file-handling → dbradley
Depends on: 287107
*** Bug 287529 has been marked as a duplicate of this bug. ***
Taking. While my patch for bug 287107 reverted xpconnect to behavior before rev 1.73 of xpcwrappedjsclass.cpp as far as XPCWrappedJSClass::CallMethod's treatment of non-failure pending results (Components.returnCode set to NS_COMFALSE from the JS method, that is), it must be the case that xpconnect had this bug then, or the bug came in independently but was masked by 1.73's change that broken COMFALSE "returns". I'd like to close bug 287107 so it can be verified, and fix this with a followup patch, but I'll wait to see how that patching goes -- if backing out 287107's patch is expedient, we'll want that left REOPENED. /be
Created attachment 178501 [details] [diff] [review] fix Do exceptions, as well as pending results, linger in a "pending" fashion after the CallMethod unwinds? I will check in a bit, but I invite reviewers to beat me to it! /be
Comment on attachment 178501 [details] [diff] [review] fix I spent some time going through this code and it seems like this is indeed needed, w/o this the pending resutlt can leak to calls on the stack. sr=jst
Attachment #178501 - Flags: superreview?(jst) → superreview+
Comment on attachment 178501 [details] [diff] [review] fix r=dbradley Exceptions shouldn't be an issue. It clears the exception if there is one, after retrieving it in CheckForException. Much like the pending_results does now.
Attachment #178501 - Flags: review?(dbradley) → review+
Fixed, sorry for the regression. /be
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
14 years ago
Component: File Handling → XPConnect
Brendan any chance this fix caused bug 287690 - FF crashes on Java and - Chatzilla throws error "Error creating socket" and refuses to connect (I am guessing)
forget previous comment The cause was found in another bug sorry for spamming
Verified FIXED with build 2005-03-26-05 on Windows XP Seamonkey trunk.
Status: RESOLVED → VERIFIED
Note bug 287846, which could be related or the same bug.
Thunderbird's View Message Source - Save Page As is still broken as well. In a 20050325 build, I still get the same error as in comment 0. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
the problem from comment 13 is actually a regression from the patch in this bug. but if this bug is going to track it, this is a smoketest blocker
Severity: critical → blocker
Summary: can't save any files with progress dialog → can't save any files with progress dialog -- filepicker fails to open
When I verified this bug, I tested it on Pinkerton's blog: http://weblogs.mozillazine.org/pinkerton/archives/007804.html, saving .mp3 files (which, oddly enough still works for me with build 2005-03-27-05, Windows XP). Testing it more completely after shame for a much-too-quick-verification, I see that it fails on many other sites. Is this site-dependant?
I backed out, and will take up the harder job of figuring out which JS QI impls are failing to handle what IIDs, etc., later. This is no longer a blocker, and it's technically fixed. Donner, I don't think this is site-dependent so much as code-path dependent in squirelly ways. More in bug 287846 when we know more. /be
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.