So base::Bind returns a base::Callback that is currying the given arguments, and in this case still needs a history::WebHistoryService::Request* and const base::DictionaryValue* as you mentioned. But this is exactly the typedef of QueryWebHistoryCallback that WebHistoryService::QueryHistory expects, so the Callback is passed in and then actually invoked at https://cs.chromium.org/chromium/src/components/history/core/browser/web_history_service.cc?rcl=1481026846&l=549 which is basically just the results of a remote call.

Now, how do you get base::Bind to work like this, lots of confusing templates! https://cs.chromium.org/chromium/src/base/bind.h and https://cs.chromium.org/chromium/src/base/bind_internal.h would be good starting points.


As for your problem of not getting history synced between devices, unfortunately this is working as intended, at least for now. I'm pretty confident what's going on is that you have custom passphrase enabled, as shown by your sync dumps. If you look at https://support.google.com/chrome/answer/1181035 , you can see we try to call this out:

>> Your history won't sync across devices. Web addresses that you type in the address bar in Chrome will still sync.

What's going on is that "history" works a little differently than most datatypes. Your clients don't proactively download remote devices' history because we were worried (this decision was made a long time ago) it would be too much data/bandwidth/memory. It is unclear if this calculation still holds true for many Chrome users. Instead it is fetched on demand. Unfortunately, the way this is implemented, it doesn't work if you have a custom passphrase enabled.

But wait, you must be thinking, I didn't enable passphrases recently! But this string changed recently (at least I'm assuming you noticed this recently). Looking at your sync dumps

        {
          "is_valid": true,
          "stat_name": "Passphrase Time",
          "stat_value": "Monday, October 26, 2015 at 9:39:01 PM"
        }

That was just over a year ago when you enabled a custom passphrase. Now, I don't know the details of how the remote call for history works exactly, but how close to exactly 1 year is super suspicious. It would explain this behavior if anything over 1 year is excluded, at least from the default/first query. And so you used to get a tiny bit of stale history, but now you get no results, and so the UI text changed.


Okay, so next steps. Nuking local profile isn't going to change this. Instead you'd need to remove the custom passphrase, see https://support.google.com/chrome/answer/6386691?hl=en . Your clients will resync and use bandwidth to do this, on the order of 1-10 KB per sync entry, and you have 43183 entries. The first client to connect will upload this amount, and then the subsequent devices to connect will download this amount. Hopefully all merging goes through perfectly and we don't do anything unnecessarily. Though, your dumps show you have 27615 bookmarks, this seems like a lot to naturally accumulate. There might have been some old duplication bugs that bloated your data before they were fixed.

Alternatively, you were not actually using history sync for the last year, maybe you don't really need it. Open tabs should still be syncing for you. You could leave things as is.

I'm not going to create a follow up bug to try to be more correct this UI to more clearly reflect what's happening. The history page has actually received a big material design refresh, and the people doing this decided to remove this text. So we don't have this "problem" going forward.

Lastly, we on the Sync team strive to keep feature parity for all users, including the custom passphrase use case. We're not happy with this limitation that history sync doesn't work if you've enabled custom passphrases. I'm not sure how we want to address this, and it definitely won't be in the short term, but I hope that one day this will just work.

_Wow_. For a WontFix, the explanation you've provided is absolutely awesome, thanks so much for taking the time.

Regarding the C++ explanations, I'm trying my best to catch everything as it flies over my head :) but I sorta get it. At least I now know where the result was being generated - from code in a file in a totally different directory to the one I was in. :D

Regarding "will it use too many resources," this sounds like the perfect thing to throw telemetry at! I can see rearchitecting the entirety of the history subsystem just to test how well it would work being a bit crazy, maybe you could just generate garbage data that produces a similar resource load profile and see how well that works across the board.

I see chrome://history periodically reloads every few seconds, and if that's due to poll results coming in, I can see push working a whole lot better in terms of server resources (unless Chrome keeps so many connections open keepalive has a chance to help out).

One other thing I will say is that chrome://history could do with an overhaul, if I'm typing or about to click a link when it decides to reload, that kinda falls neatly into the "arg, the webpage moved while I was trying to use it" category. The yellow update flashes in chrome://sync-internals come to mind as inspiration for a possible redesign (with the base idea being that the page pulls in new results without needing to reload). I can report a separate bug to track this if you like.

*Sighs* so it was my passphrase :D hah. I've been using one for a while now, I think I set it immediately after setting sync up actually. But now I think about it, I just checked my alt profile (recently discovered the usefulness of multiple Chrome profiles!) and found it _doesn't_ use a custom passphrase... so yeah, I think that's where I saw the "showing history from all devices" thing; in any case I also opened things from my history I *know* I'd visited on other machines from *that* account, so that's clearly where the confusion came from.

As for my bandwidth considerations, I actually have 50GB/mo, but it disappears so quickly due to today's bloated interpretations of "how to even HTML5" (even with an ad-blocking hosts file!). I was considering users with even less bandwidth when I wrote that - I was trying to come up with an actionable use-case to justify fixing this.

Regarding the chrome://md-history redesign, I am mildly freaked out by the news that the indication is gone - as you said, you do try to call out the fact that a CUSTOM_PASSPHRASE disables history storage, but IMHO this is information that needs to be inside Chrome itself, perhaps even inside the chrome://settings/syncSetup modal. I'll admit I clicked the link, but didn't exactly read it, hah.

I cannot provide enough encouragement that (even brief) consideration be given to the fact that once this is removed, users will have no measurable metric of why "my history syncs but yours doesn't" (in the example of two people comparing devices side-by-side and trying to figure it out). From a human perspective, the kind of user who will enable a custom passphrase is also the nervous, flighty, and frequently kooky type, prone to superstition and loud screeching (in the Chrome forums) about their conspiracy theories; the poor moderators of that place already have a morbidly hilarious job on their hands, it doesn't need to be made worse... :P

In any case, I'm really glad to hear this will (eventually) be fixed - telemetry could make for an interesting start, if at least to get over the inertia of how things have been done for the past however long.

Finally, regarding my bookmarks, I actually do have that many (26,432); I constantly go "you know I read something about this that one time..." so I try to keep a vague idea of where everything is. Sadly the extension I use (Better Bookmark) is very buggy and has caused some duplication (not sure exactly how - may have been race conditions, Chrome is swapping at least 40% of the time on my systems); writing a better bookmark manager has been on the todo list for a while, but I'm not sure exactly how/where to start with fixing it, hilariously.