Closed
Bug 391640
Opened 17 years ago
Closed 17 years ago
Unable to use the "Open" link in download manager
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.9alpha8
People
(Reporter: bzbarsky, Assigned: sdwilsh)
References
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
1.40 KB,
patch
|
Biesinger
:
review+
dmosedale
:
superreview+
bzbarsky
:
approval1.9+
|
Details | Diff | Splinter Review |
BUILD: Current trunk on Linux
STEPS TO REPRODUCE:
1) Download a file (I recomment a XUL file; that's what I was testing with)
2) Click the "Open" link in the download manager for that file
EXPECTED RESULTS: Open the file
ACTUAL RESULTS: Throws an exception
The issue is that nsExternalHelperAppService::GetProtocolHandlerInfo (called from nsExternalHelperAppService::LoadURI) in this case does:
(*aHandlerInfo)->SetPreferredAction(nsIHandlerInfo::alwaysAsk);
In this case |warn| is false, so this code:
1265 if (!warn ||
1266 !alwaysAsk && (preferredAction == nsIHandlerInfo::useHelperApp ||
1267 preferredAction == nsIHandlerInfo::useSystemDefault))
1268 return handler->LaunchWithURI(uri);
makes us call LaunchWithURI(), which throws because it can't handle this preferred action. I have no idea why the |warn| boolean is overriding the other part of the condition; I would have thought that the || should be an && or something, no?
Flags: blocking1.9?
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 1•17 years ago
|
||
Attachment #276164 -
Flags: superreview?(dmose)
Assignee | ||
Updated•17 years ago
|
Attachment #276164 -
Attachment is obsolete: true
Attachment #276164 -
Flags: superreview?(dmose)
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
Attachment #276170 -
Attachment is obsolete: true
Comment 4•17 years ago
|
||
Comment on attachment 276180 [details] [diff] [review]
v3.0
sr=dmose
Attachment #276180 -
Flags: superreview+
Updated•17 years ago
|
Attachment #276180 -
Flags: review+
Reporter | ||
Comment 5•17 years ago
|
||
Comment on attachment 276180 [details] [diff] [review]
v3.0
a=bzbarsky
Attachment #276180 -
Flags: approval1.9+
Assignee | ||
Comment 6•17 years ago
|
||
Checking in uriloader/exthandler/nsExternalHelperAppService.cpp;
new revision: 1.334; previous revision: 1.333
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Reporter | ||
Comment 7•17 years ago
|
||
Why litmus? This feels like it could be unit-testable....
Assignee | ||
Comment 8•17 years ago
|
||
I'm not really sure how to unit test it, but if someone comes up with a good suggestion, I'll make one.
Reporter | ||
Comment 9•17 years ago
|
||
One way is to set up a MIME info for a file:// in mochitest and try to run it. If the test times out (because of the dialog), you fail.
http://litmus.mozilla.org/show_test.cgi?id=3976
in-litmus+ (automation would rock!)
Flags: in-litmus? → in-litmus+
Comment 12•17 years ago
|
||
Any chance this check-in caused bug 392403?
Verified FIXED using:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020419 Minefield/3.0b3pre
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•