Closed
Bug 397906
Opened 17 years ago
Closed 17 years ago
ed2k protocol (and others?) preferred application never remembered
Categories
(Firefox :: File Handling, defect, P2)
Firefox
File Handling
Tracking
()
VERIFIED
FIXED
Firefox 3 beta2
People
(Reporter: stevee, Assigned: dmosedale)
References
Details
(Keywords: testcase, Whiteboard: [proto])
Attachments
(2 files)
154 bytes,
text/html
|
Details | |
9.27 KB,
patch
|
Biesinger
:
review+
Biesinger
:
superreview+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007092720 Minefield/3.0a9pre ID:2007092720 1. New profile, start firefox 2. Load testcase page 3. click on ed2k:// link 4. The 'Launch Application' dialog appears. Choose to open the file with your favourite edonkey client, and tick "Remember my choice for ed2k links." 5. Click OK (Your edonkey client is opened, and the file is added to your download queue). 6. Remove the download from your edonkey client 7. In firefox, click on the ed2k link again Expected: - No 'Launch Application' dialog should appear (because you told firefox to remember how to handle ed2k links); ed2k link should be automatically passed into your edonkey client with no prompting. Actual: - 'Launch Application' dialog appears again, and re-asks you how to handle ed2k links, even tho you've told firefox to open them with your favourite edonkey client.
Flags: blocking-firefox3?
Reporter | ||
Comment 1•17 years ago
|
||
setting network.protocol-handler.warn-external-default to false makes everything work fine. So my questions are: 1) why is network.protocol-handler.warn-external-default set to true by default? 2) why doesn't my user-set preference wrt the newly-added ed2k protocol ("always open ed2k protocol links with eMule") over-rule network.protocol-handler.warn-external-default=true?
Comment 2•17 years ago
|
||
this happens with Azereus/Vuze's 'magnet:' links also...
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → dmose
Priority: -- → P3
Updated•17 years ago
|
Target Milestone: --- → Firefox 3 M10
Updated•17 years ago
|
Priority: P3 → P2
Assignee | ||
Updated•17 years ago
|
Whiteboard: [proto]
Assignee | ||
Updated•17 years ago
|
Whiteboard: [proto] → [proto][depends on 402771 feedback beltzner]
Assignee | ||
Updated•17 years ago
|
Whiteboard: [proto][depends on 402771 feedback beltzner] → [proto][needs new patch]
Assignee | ||
Comment 3•17 years ago
|
||
(In reply to comment #1) > setting network.protocol-handler.warn-external-default to false makes > everything work fine. So my questions are: > > 1) why is network.protocol-handler.warn-external-default set to true by > default? This is by design; see bug 402771 for the most recent iteration of this discussion. > 2) why doesn't my user-set preference wrt the newly-added ed2k protocol > ("always open ed2k protocol links with eMule") over-rule > network.protocol-handler.warn-external-default=true? This is the bug. Patch forthcoming.
Assignee | ||
Comment 4•17 years ago
|
||
The user's explicit alwaysAskBeforeHandling setting should override any default of the dialog popping up. So really, the warn preference just needs to be used to default that setting in the case where the user hasn't yet said anything explicitly.
Attachment #290936 -
Flags: superreview?(cbiesinger)
Attachment #290936 -
Flags: review?(cbiesinger)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [proto][needs new patch] → [proto] [has patch] [needs r,sr biesi]
Comment 5•17 years ago
|
||
Comment on attachment 290936 [details] [diff] [review] use warning pref to default alwaysAskBeforeHandling, v1 + (*aHandlerInfo)->SetAlwaysAskBeforeHandling(warn); + + } else { remove that blank line please
Attachment #290936 -
Flags: superreview?(cbiesinger)
Attachment #290936 -
Flags: superreview+
Attachment #290936 -
Flags: review?(cbiesinger)
Attachment #290936 -
Flags: review+
Assignee | ||
Updated•17 years ago
|
Whiteboard: [proto] [has patch] [needs r,sr biesi] → [proto] [has patch] [needs checkin]
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 6•17 years ago
|
||
Checked in, with the blank line removed.
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [proto] [has patch] [needs checkin] → [proto]
Comment 7•17 years ago
|
||
Verified FIXED with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre; the testcase in comment 0 works fine for me now.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•