| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When downloading content from a server that claims content to be
text/plain or application/octet-stream a guess is made of the proper
mime-type from a possible "file-extension" in the URL. When creating
the filename of the downloaded content any file extension that does
not match the mime-type is replaced with one derived from the
mime-type (.txt for text/plain, none for application/octet-stream).
However the guessed mime-type is not used in the filename
creation, so content with a proper file extension but a text/plain
mime-type will have its file extension replaced with .txt derived
from the incorrect mime-type.
This fix will use the guessed mime-type when creating the filename
to avoid replacing a correct file extension.
Change-Id: I5df642e94948914708af99a4d902b253ac8a48dd
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 5952386
Our java.net.URI implementation conforms to an old obsolete RFC and
it is very restrictive. Since in our download path, we use download
manager and so java.net.URI, this causes an odd bug (i.e. URIs that
are fetched fine by chromium http stack fails when download manager is
used). Also there is a second bug that when URI parsing fails and an
exception is thrown, we fail to catch it and crash. This CL fixes both.
Change-Id: I62ac289566efae97dd2161b8041b06a0a87211cb
|
| |
|
|
|
|
|
|
|
| |
FetchUrlMimeType doesn't need an Activity, an Application
Context will do.
Bug: 5084293
Change-Id: Ifcd400e0b639e0120f4f89c292acadfe467f92ab
|
| |
|
|
|
|
|
|
|
|
|
|
| |
downlaoded files should go into /sdcard/Download, like they used to
in GB and earlier.
But a minor difference in the download dir name:
it used to be /sdcard/download in before HC
/sdcard/Download in HC
how serious is this difference?
Change-Id: Ib56d8ee6a1393fd781399281be98b8c52831ebe1
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug:3189668
Do not create a DownloadHandler since the methods can all be
static.
Do not pass the length to DownloadHandler, since it is no longer
used.
Change-Id: I280160f62906d1acb263b45fde57062210005a0a
|
| |
|
|
|
|
|
|
|
|
| |
Bug: 3170671
First step towards a model/view/control design in Browser
introduced Controller object
started separating UI code
represent state of the app in one place only
Change-Id: Ica387d6bde2dcf1a4993c3db0cce498cf34ff60f
|
| |\
| |
| |
| | |
Change-Id: I55678d34730df191d541762d4b2025bff2f2460b
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Content-Disposition isn't used when downloading an
item by long-click the link. It'll result in different
file name if the item is downloaded by clicking the link
or if it's downloaded by long-click the link and select
Save link if the HTTP response includes the Content-Disposition
header with the filename attribute
Change-Id: I7eacfd1128da261e0674bbdc3064208a82e46ab3
|
| |/
|
|
|
| |
Bug:3116742
Change-Id: I5d0d9a12e1bd601cf6a95198578ce8f9acd81372
|
| |
|
|
|
|
|
| |
Use the new Proxy method getPreferredHttpHost to use proxy for
downloads.
Change-Id: I4224e29ba4b37bd570d84382764e08f9babe6530
|
| | |
|
| |
|
|
| |
Fixes http://b/issue?id=1671150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This boils down to using Downloads.Impl instead of Downloads
The APIs that were being used so far are going to disappear
to be replaced by a new set of APIs, but in order for the browser
to be able to continue using the old APIs a new copy of those APIs
was created "on the side" so that the browser doesn't need to
change much.
Bug: 2245521
Change-Id: I33c526331cce006710b1f934a4aeb64cdb95d62e
|
| | |
|
| |
|
|
|
| |
found by findbugs
http://b/issue?id=1856781
|
| |
|
|
|
|
| |
Conflicts:
src/com/android/browser/BrowserActivity.java
|
| | |
|
| | |
|
| |
|
