Community
Participate
Working Groups
Request for ability to - intercept and prevent downloads - programmatically set download location if permitted
Status: 1. Download is supported on Windows (IE). It works on Mozilla but it currently relies on unfrozen API and is therefore fragile. Download needs to be implemented on the Mac. Mac: TBD Need to look into WebKit API webView decidePolicyForMimeType and for code like: if ([WebView canShowMIMEType:type]) [listener use]; else [listener download]; Then look into download: decideDestinationWithSuggestedFilename API 2. - intercept and prevent downloads Current API supports filtering of URL loading. See org.eclipse.swt.browser.LocationListener.changing notification. It can be used to filter URLs to be navigated to - including documents the native Browser has no registered viewer for and will attempt to download. Notification contains a doit flag to cancel the loading. e.g when the user clicks on the HTTP Eclipse download page for the eclipse build, he/she receives a LocationListener.changing notification: http://fullmoon.ottawa.ibm.com/downloads/drops/R-3.0-200406251208/eclipse-SDK- 3.0-win32.zip Setting the event doit flag to false will block the download. Location target cannot be currently set programmatically. 3. - programmatically set download location if permitted Note for Windows. Need to investigate FileDownload and IDownladManager API. Note for Mozilla. We are currently implementing unfrozen API nsIDownload nsIProgressDialog nsIWebProgressListener nsIHelperAppLauncherDialog to provide a download dialog when embedding Mozilla. As a result the download scenario is fragile on that platform. We should not add API that rely on these unfrozen interfaces. We need to get these APIs - or new API - frozen in future version of Mozilla to support this use case.
See Mozilla request at: https://bugzilla.mozilla.org/show_bug.cgi?id=252627
*** Bug 101750 has been marked as a duplicate of this bug. ***
*** Bug 128119 has been marked as a duplicate of this bug. ***
Bug 128119 suggests progress events as well.
How do you figure that progress events bug 128119 is a duplicate of this? Intercept and prevent downloads.....programatically set download location???? That seems a far stretch. I just wanted progress events for downloading...no control over anything!
They're not the same, but from the implementation perspective these functions likely live together in the native browsers and would be exposed in a common machanism (eg.- a download listener). I've updated the title to ensure that the progress events part is not lost in the comments.
Is there any progress on this?
