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)
Tracking
(firefox17 affected, firefox18 affected, fennec+)
RESOLVED
FIXED
Firefox 31
People
(Reporter: aaronmt, Assigned: james.gilbertson)
References
Details
(Whiteboard: [mentor=wesj])
Attachments
(1 file)
5.02 KB,
patch
|
wesj
:
review+
blassey
:
review+
|
Details | Diff | Splinter Review |
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?
Updated•12 years ago
|
Updated•12 years ago
|
tracking-fennec: ? → +
Comment 2•11 years ago
|
||
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
Updated•10 years ago
|
Whiteboard: [mentor=wesj]
Assignee | ||
Comment 3•10 years ago
|
||
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 4•10 years ago
|
||
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 5•10 years ago
|
||
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+
Assignee | ||
Comment 6•10 years ago
|
||
(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.
Assignee | ||
Comment 7•10 years ago
|
||
I'm not able to edit keywords for this bug, so can someone who can add the checkin-needed keyword for me? Thanks!
Comment 8•10 years ago
|
||
Done. Please request editbugs, https://bugzilla.mozilla.org/page.cgi?id=get_permissions.html
Keywords: checkin-needed
Comment 9•10 years ago
|
||
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]
Comment 10•10 years ago
|
||
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
Comment 11•10 years ago
|
||
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.
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•