Closed
Bug 287490
Opened 20 years ago
Closed 20 years ago
can't save any files with progress dialog -- filepicker fails to open
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ajschult784, Assigned: brendan)
References
Details
(Keywords: regression, smoketest)
Attachments
(1 file)
(deleted),
patch
|
dbradley
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 2•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
OS: Linux → All
Comment 3•20 years ago
|
||
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
Comment 4•20 years ago
|
||
*** Bug 287529 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: dbradley → brendan
Assignee | ||
Comment 5•20 years ago
|
||
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
Assignee | ||
Comment 6•20 years ago
|
||
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 7•20 years ago
|
||
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 8•20 years ago
|
||
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+
Assignee | ||
Comment 9•20 years ago
|
||
Fixed, sorry for the regression.
/be
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Component: File Handling → XPConnect
Comment 10•20 years ago
|
||
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)
Comment 11•20 years ago
|
||
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
Comment 13•20 years ago
|
||
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)
Comment 14•20 years ago
|
||
Note bug 287846, which could be related or the same bug.
Comment 15•20 years ago
|
||
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 → ---
Reporter | ||
Comment 16•20 years ago
|
||
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?
Assignee | ||
Comment 18•20 years ago
|
||
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: 20 years ago → 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•