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)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9alpha8

People

(Reporter: bzbarsky, Assigned: sdwilsh)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

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: nobody → sdwilsh
Blocks: 385065
Keywords: regression
Target Milestone: --- → mozilla1.9 M8
No longer blocks: 385065
Depends on: 385065
Attached patch v1.0 (obsolete) — Splinter Review
Attachment #276164 - Flags: superreview?(dmose)
Attachment #276164 - Attachment is obsolete: true
Attachment #276164 - Flags: superreview?(dmose)
Attached patch v2.0 (obsolete) — Splinter Review
Attached patch v3.0Splinter Review
Attachment #276170 - Attachment is obsolete: true
Comment on attachment 276180 [details] [diff] [review] v3.0 sr=dmose
Attachment #276180 - Flags: superreview+
Comment on attachment 276180 [details] [diff] [review] v3.0 a=bzbarsky
Attachment #276180 - Flags: approval1.9+
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
Why litmus? This feels like it could be unit-testable....
I'm not really sure how to unit test it, but if someone comes up with a good suggestion, I'll make one.
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+
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: