diff options
| author | yuzo@chromium.org <yuzo@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-24 02:30:59 +0000 |
|---|---|---|
| committer | yuzo@chromium.org <yuzo@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-24 02:30:59 +0000 |
| commit | e684a31a3733e0a3047c56c818a9cd42742b0ba4 (patch) | |
| tree | db54423972cdfd065182c9d125cef3bd43f1545e /skia | |
| parent | 20b89a1a9040b58769175c20bb35d641b2b102cc (diff) | |
| download | chromium_src-e684a31a3733e0a3047c56c818a9cd42742b0ba4.zip chromium_src-e684a31a3733e0a3047c56c818a9cd42742b0ba4.tar.gz chromium_src-e684a31a3733e0a3047c56c818a9cd42742b0ba4.tar.bz2 | |
Fix: Omnibox is not updated properly when the main frame results in a file download
This is the second attempt, to address the cases where downloadable
URLs are input multiple times.
It seems that depending on the thread execution order,
TabContents::DidFailProvisionalLoadWithError is sometimes called after
TabContents::OnStartDownload. In such cases, URL display invalidation
happens before the navigation entry removal. The result is
that the downlodable URL remains in the omnibox.
This change ensures that the URL invalidation happens right after
the navigation entry removal.
BUG=1904
TESTED=manually, gcl try
TEST=Type any URLs that causes download, e.g.,
ftp://ftp.vim.org/pub/vim/pc/gvim72.zip into the omnibox.
Observe that the URL is changed back to the original once the download starts.
Repeat this multiple times, with other URLs, to confirm it always works.
Review URL: http://codereview.chromium.org/147006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19094 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'skia')
0 files changed, 0 insertions, 0 deletions