can't save any files with progress dialog -- filepicker fails to open

RESOLVED FIXED

Status

()

defect
--
blocker
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: ajschult784, Assigned: brendan)

Tracking

({regression, smoketest})

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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
OS: Linux → All
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. ***
Assignee: dbradley → brendan
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
Posted patch fixSplinter Review
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
Attachment #178501 - Flags: superreview?(jst)
Attachment #178501 - Flags: review?(dbradley)
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
Closed: 15 years ago
Resolution: --- → FIXED
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
i still can't save any bugzilla attachments, using a build that's about 10 hours
old, and does have the patch.

JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIFilePicker.init]" 
nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: poseFilePicker :: line 489"
 data: no]

(linux, both gtk1 and gtk2)
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
Keywords: smoketest
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
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.