Closed Bug 642996 Opened 9 years ago Closed 9 years ago

Hide the "Save Link" context menu for some or all links


(Firefox for Android Graveyard :: General, defect, minor)

Not set


(Not tracked)

Firefox 9


(Reporter: mbrubeck, Assigned: mbrubeck)



(Keywords: mobile, ux-minimalism)


(1 file, 1 obsolete file)

From bug 637031 comment 3 - comment 5:

> We should be smarter about the inclusion of "Save Link" which is
> often useless when the page links to an html doc (I think it's
> there to allow saving of PDFs, etc.)

> We don't know reliably whether a link will return an HTML file or a PDF
> file until we follow it.  We could guess based on the file extension
> (e.g., hide the option if the URL ends in ".html") but this might be
> incorrect some of the time.  Would that be better or worse than showing
> it all the time?

> It seems to me that it almost always a not useful option, in a menu that we're
> trying to keep as short as possible. Most of the time, a link is a link to
> another page, in which case we just save the HTML which is not a feature I
> think we would ever prioritize (or even want, particularly). What is a file
> that a person _would_ want to save, sight unseen (i.e. vs. first seeing an
> image file and long-tapping it directly to save it)?  PDFs already end up in
> the download manager.
The one potentially-important use case I've seen is files without correct Content-type headers.  These may be displayed in the browser when they ought to be saved.  Some discussion of this problem here:
Another use-case (using PDF as the example) is saving a PDF that won't be auto-deleted. If you just tap a PDF link, we open it in a PDF viewer but we will delete the PDF file as soon as we can.

To keep the PDF locally as long as you want, you need to explicitly _save_ it.
(In reply to comment #2)
> If you just tap a PDF link, we open it in a PDF viewer but we
> will delete the PDF file as soon as we can.

Perhaps we should file a bug to change this in Fennec - it seems inconsistent with the way our download manager works.  (I thought we had already, but I can't find one.)  For desktop this is bug 191239.
Filed bug 643027 for not deleting files on exit.
Depends on: 643027
Attached patch patch (obsolete) — Splinter Review
I think we can do this safely now that bug 596370 is fixed, which removes the objection from comment 2.  The problem in comment 1 remains, but it's an edge case that happens only on sites that are broken in most or all browsers.
Assignee: nobody → mbrubeck
Attachment #553519 - Flags: review?(wjohnston)
Depends on: 596370
Attached patch patch v2Splinter Review
Remove some more code (thanks to Wes for comments via IRC).
Attachment #553519 - Attachment is obsolete: true
Attachment #553519 - Flags: review?(wjohnston)
Attachment #554552 - Flags: review?(wjohnston)
Comment on attachment 554552 [details] [diff] [review]
patch v2

Review of attachment 554552 [details] [diff] [review]:

Looks good! Thanks
Attachment #554552 - Flags: review?(wjohnston) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → Firefox 9
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110830 Firefox/9.0a1 Fennec/9.0a1
You need to log in before you can comment on or make changes to this bug.