diff options
| author | pkasting@chromium.org <pkasting@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-07-09 22:22:57 +0000 |
|---|---|---|
| committer | pkasting@chromium.org <pkasting@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-07-09 22:22:57 +0000 |
| commit | cb0a9937a4e393ebf154e3accee5e4c81f3f5f9a (patch) | |
| tree | 963dfcfe13c401c14706ab1d7a2e56927a0c402a /chrome/test | |
| parent | 5ee3d70fc4586a36b1d56037d806ec7846690f39 (diff) | |
| download | chromium_src-cb0a9937a4e393ebf154e3accee5e4c81f3f5f9a.zip chromium_src-cb0a9937a4e393ebf154e3accee5e4c81f3f5f9a.tar.gz chromium_src-cb0a9937a4e393ebf154e3accee5e4c81f3f5f9a.tar.bz2 | |
Merge 144201 - More comprehensive handling of NOTIFICATION_NAV_ENTRY_PENDING for GoogleURLTracker.
In particular, there are three cases that are improved:
(1) We didn't deal well with further searches in the same tab that was already showing an infobar. Depending on ordering, various kinds of badness could occur, in particular trying to deref infobar_map_.end().
(2) If we caught a PENDING search, but before the load committed the user performed some other navigation, we'd show the infobar on the commit for the later navigation, leading to infobars on random pages.
(3) In a generalization of (2), we now listen for PENDING in many more cases so that we know if the user is starting a new navigation, which may be the only way we get signalled that a previous navigation has been cancelled. (Note that if a pending navigation is simply stopped, and we were waiting for commit, we'll keep waiting, but this is harmless since eventually either the tab will be closed or the user will start another navigation.)
These changes should hopefully make GoogleURLTracker as robust about navigation-handling as AlternateNavURLFetcher already was.
Additionally, I reverted a previous change where a pending search would change the "search_url" of a visible infobar in that tab. Because we don't get notified when a load is stopped, we can't distinguish between "started a new search that hasn't committed" and "started but then cancelled a new search", and thus it's potentially wrong to search for the new URL (yet). We now once again wait until a search actually commits. In doing this I simplified things so that we only even pass in the search URL when a load commits.
BUG=133108
TEST=Edit your preferences file so that you get prompted about changing Google search URLs. Do a Google search in one tab, wait for the infobar to appear, then do another search in the same tab. The infobar should stick around and interacting with it shouldn't cause crashes.
Review URL: https://chromiumcodereview.appspot.com/10630022
TBR=pkasting@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/branches/1180/src@145760 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/test')
0 files changed, 0 insertions, 0 deletions