Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(73)

Issue 4880003: Fix a number of problems with the GoogleURLTracker (Closed)

Created:
10 years, 1 month ago by Peter Kasting
Modified:
8 years, 8 months ago
Reviewers:
Ilya Sherman
CC:
chromium-reviews, Paweł Hajdan Jr., ben+cc_chromium.org
Visibility:
Public.

Description

Fix a number of problems with the GoogleURLTracker, mostly around the multiple-searches-simultaneously use case: * The old code used members to track things like "what's the search URL". But since there's one GoogleURLTracker and potentially many simultaneously open tabs doing searches, this caused problems with searches overwriting the data for previous searches, leading to infobars that would redo the wrong search. The new code stuffs this sort of data into the infobar delegate so it's safe to have many simultaneous infobars, which are now tracked in a map. * Related to the above issue, we'd call registrar_.RemoveAll() any time an infobar was closed or we got a committed or closed notification. But since multiple tabs could in theory be listening for notifications, this was wrong. This could cause infobars to sometimes not appear when doing searches in multiple tabs. Now we are more surgical with our notifications. * Made accepting one infobar close all of them and trigger all of them to re-search. Similarly, canceling any one infobar now cancels them all. * The unittest code has been made more robust, if a bit confusing. I changed the way the helper code provided mock search domain responses to make it safe to provide a response whether or not a query had actually happened. This way if something goes wrong and we don't query at the places we think we should, we won't have hangs or data corruption or anything else. The downside here is that in order to avoid actually needing a WebContents*, NavigationController*, InfoBarTabHelper*, etc. to be constructed, I instead use simple ints that are reinterpret_cast<>()ed to the various types to serve as unique pointers. The GoogleURLTracker itself doesn't actually deref these pointers, so this is safe, and it neatly sidesteps having to mock out a bunch of different things, but it's fairly unorthodox. * More unittests for cases that the original code didn't cover, e.g. multiple simultaneous infobars. This does NOT yet deal with a major cause of bug 110158 that the GoogleURLTracker does not correctly handle instant (and maybe also prerendering). I wanted to make the underlying framework more sane and robust before trying to fix that. BUG=54274, 110158 TEST=Moving to different countries causes a "you moved" infobar to trigger when the user does a search. No matter how many tabs have infobars, accepting or rejecting the new Google TLD should close them all, and if the TLD was accepted, redo all their searches on the new TLD. Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=133598

Patch Set 1 #

Total comments: 3

Patch Set 2 : '' #

Patch Set 3 : '' #

Patch Set 4 : #

Total comments: 15
Unified diffs Side-by-side diffs Delta from patch set Stats (+484 lines, -201 lines) Patch
M chrome/browser/google/google_url_tracker.h View 1 2 3 7 chunks +29 lines, -14 lines 8 comments Download
M chrome/browser/google/google_url_tracker.cc View 1 2 3 11 chunks +147 lines, -88 lines 7 comments Download
M chrome/browser/google/google_url_tracker_unittest.cc View 1 2 3 13 chunks +308 lines, -99 lines 0 comments Download

Messages

Total messages: 11 (0 generated)
Peter Kasting
10 years, 1 month ago (2010-11-12 21:25:59 UTC) #1
Ilya Sherman
http://codereview.chromium.org/4880003/diff/1/chrome/browser/google/google_url_tracker.cc File chrome/browser/google/google_url_tracker.cc (right): http://codereview.chromium.org/4880003/diff/1/chrome/browser/google/google_url_tracker.cc#newcode423 chrome/browser/google/google_url_tracker.cc:423: DCHECK(need_to_prompt_); Why does |need_to_prompt_| have to be true? Suppose ...
10 years, 1 month ago (2010-11-16 00:17:46 UTC) #2
Ilya Sherman
http://codereview.chromium.org/4880003/diff/1/chrome/browser/google/google_url_tracker.h File chrome/browser/google/google_url_tracker.h (right): http://codereview.chromium.org/4880003/diff/1/chrome/browser/google/google_url_tracker.h#newcode94 chrome/browser/google/google_url_tracker.h:94: const GURL&); On 2010/11/16 00:17:47, Ilya Sherman wrote: > ...
10 years, 1 month ago (2010-11-16 00:19:52 UTC) #3
Peter Kasting
10 years, 1 month ago (2010-11-16 00:39:22 UTC) #4
Ilya Sherman
LGTM, thanks
10 years, 1 month ago (2010-11-16 01:01:41 UTC) #5
ukai
LGTM
10 years, 1 month ago (2010-11-16 02:21:08 UTC) #6
Ilya Sherman
Peter, did you want to get this in for M9?
10 years ago (2010-12-10 23:47:00 UTC) #7
Peter Kasting
It's blocked behind my infobar rewrite.
10 years ago (2010-12-10 23:47:36 UTC) #8
Peter Kasting
Ilya, since you looked at this long ago and there really aren't any great reviewers, ...
8 years, 8 months ago (2012-04-19 23:25:16 UTC) #9
Ilya Sherman
LGTM https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/google/google_url_tracker.cc File chrome/browser/google/google_url_tracker.cc (right): https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/google/google_url_tracker.cc#newcode112 chrome/browser/google/google_url_tracker.cc:112: // so that infobars in background tabs don't ...
8 years, 8 months ago (2012-04-24 00:30:47 UTC) #10
Peter Kasting
8 years, 8 months ago (2012-04-24 01:53:01 UTC) #11
Landing.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
File chrome/browser/google/google_url_tracker.cc (right):

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.cc:133: if (google_url_tracker_)
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: Should this also check the state of |showing_|?

No.  The infobar is present in the tracker's map regardless of whether it is
showing.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.cc:460: // irrelevant as the associated
infobars are gone.
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: You don't mention NAV_ENTRY_PENDING in this comment -- should that be
> listed as well?

The reason for that is that it's (supposed to be) impossible to have
NAV_ENTRY_PENDING registered for the long term and thus it should never be
registered when we reach this point.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
File chrome/browser/google/google_url_tracker.h (right):

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.h:94: GoogleURLTrackerInfoBarDelegate*>
InfoBars;
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: Perhaps name this "InfoBarMap", so there's at least some hint to a reader
> of what the backing data structure is?

Good idea.  Changed type and variable name.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.h:103: void InfoBarClosed(const
InfoBarTabHelper* infobar_helper);
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: I think we generally prefer passing by const-ref rather than
const-pointer.

Doing this would break the test code that needs to cast an int to this type.

I tried replacing "const InfoBarTabHelper*" with a typedefed type "MapKey" in
all the places where we used it as a key rather than as a class to call methods
on, in an attempt to make this clearer.  Unfortunately this devolved badly for a
variety of reasons, and after some experimentation with template types I
eventually gave up and came back to the current implementation.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.h:133: const GURL& search_url);
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: const params generally should precede non-const (out-) params.  (Perhaps
> |infobar_helper| should be const too?)

|infobar_helper| isn't an outparam here, but can't be non-const because we need
to call a method on it.

https://chromiumcodereview.appspot.com/4880003/diff/21001/chrome/browser/goog...
chrome/browser/google/google_url_tracker.h:138: int type);
On 2012/04/24 00:30:47, Ilya Sherman wrote:
> nit: const params generally should precede non-const (out-) params.  (Perhaps
> |infobar_helper| should be const too?)

Made this one const.

Powered by Google App Engine
This is Rietveld 408576698