Closed Bug 757927 Opened 12 years ago Closed 10 years ago

No visible action for unsupported file association in the Downloads Manager

Categories

(Firefox for Android Graveyard :: Download Manager, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox17 affected, firefox18 affected, fennec+)

RESOLVED FIXED
Firefox 31
Tracking Status
firefox17 --- affected
firefox18 --- affected
fennec + ---

People

(Reporter: aaronmt, Assigned: james.gilbertson)

References

Details

(Whiteboard: [mentor=wesj])

Attachments

(1 file)

Currently when one attempts to open a file with no supported file association (e.g, *.tar.gz) there is no visible action aside from a row highlight flash. Perhaps at minimum we should mimic what the Android Download Manager does and flash a toast notification: "Cannot open file".

Finkle, thoughts?
tracking-fennec: --- → ?
tracking-fennec: ? → +
At the moment a message is displayed. Is this the behavior wanted or we should improve it? 

Firefox 25 Aurora (08/08)
Component: General → Download Manager
Whiteboard: [mentor=wesj]
With this patch, clicking on a download with an unsupported file association (from either a notification or about:downloads) now triggers ContentDispatchChooser.ask. That, in turn, displays a toast stating "Couldn't find an app to open this link" along with a search button linked to the Play store.

Unfortunately, the search is pretty useless, since it searches by the scheme of the file URI (i.e. it's always 'file').
Attachment #8409281 - Flags: review?(wjohnston)
Comment on attachment 8409281 [details] [diff] [review]
nsMIMEInfoAndroid::Launch*WithFile: return the result of LoadUriInternal instead of always returning NS_OK

Review of attachment 8409281 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to James Gilbertson from comment #3)
> Unfortunately, the search is pretty useless, since it searches by the scheme
> of the file URI (i.e. it's always 'file').

We can fix that :) You mind filing a bug?

This looks good to me (I like the cleanup). I don't think blassey is the closest thing we have to a peer for this code, so lets make sure he looks.
Attachment #8409281 - Flags: review?(wjohnston)
Attachment #8409281 - Flags: review?(blassey.bugs)
Attachment #8409281 - Flags: review+
Comment on attachment 8409281 [details] [diff] [review]
nsMIMEInfoAndroid::Launch*WithFile: return the result of LoadUriInternal instead of always returning NS_OK

Review of attachment 8409281 [details] [diff] [review]:
-----------------------------------------------------------------

::: uriloader/exthandler/android/nsMIMEInfoAndroid.cpp
@@ +38,5 @@
> +
> +  if (GeckoAppShell::OpenUriExternal(NS_ConvertUTF8toUTF16(uriSpec), mimeType)) {
> +    return NS_OK;
> +  }
> +  return NS_ERROR_FAILURE;

There's no functional change here right? Any reason for the refactor?
Attachment #8409281 - Flags: review?(blassey.bugs) → review+
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> Comment on attachment 8409281 [details] [diff] [review]
> nsMIMEInfoAndroid::Launch*WithFile: return the result of LoadUriInternal
> instead of always returning NS_OK
> 
> Review of attachment 8409281 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: uriloader/exthandler/android/nsMIMEInfoAndroid.cpp
> @@ +38,5 @@
> > +
> > +  if (GeckoAppShell::OpenUriExternal(NS_ConvertUTF8toUTF16(uriSpec), mimeType)) {
> > +    return NS_OK;
> > +  }
> > +  return NS_ERROR_FAILURE;
> 
> There's no functional change here right? Any reason for the refactor?

Correct, there's no functional change here. I refactored it because it took me ~5 minutes to figure out what the original was doing.
I'm not able to edit keywords for this bug, so can someone who can add the checkin-needed keyword for me? Thanks!
https://hg.mozilla.org/integration/fx-team/rev/d1ce42fc5cc3
Assignee: nobody → james.gilbertson
Keywords: checkin-needed
Whiteboard: [mentor=wesj] → [mentor=wesj][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/d1ce42fc5cc3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [mentor=wesj][fixed-in-fx-team] → [mentor=wesj]
Target Milestone: --- → Firefox 31
I do not see any new behavior at this moment on either one of the channels (Nightly 33, Aurora 32, Beta 31)
Accessing unsupported files triggers no action (no error, no pop up, no notification)

(In reply to James Gilbertson from comment #3)

> That, in turn, displays a toast stating
> "Couldn't find an app to open this link" along with a search button linked
> to the Play store.

This is not present. 

Filled Bug 1029495.
Depends on: 1029495
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.