Bisect Information:
------------------------
You are probably looking for a change made after 422037 (known good), but no later than 422038 (first known bad).

CHANGELOG URL:
----------------
https://chromium.googlesource.com/chromium/src/+log/932d7f1488771d98c3519ffca0ca84deca523d05..93a39a3cfff736b8e10f65e9d7bf2612186a26c8

From the CL above, assigning the issue to the concern owner 

@lshang - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

I took a look at this and it looks like disabling the WebUI DataSource reload fixes this. This was done to fix the Loading... state of the synced device manager when the user signs in. We can probably do that another way and avoid the data source reloading here somehow.

I think lshang@ and I have figured out a decent approach:
-Remove the loadTimeData signin bool
-If the signin state goes from undefined => true, then the user is already signed in
-If the signin state goes from false => true, the user just signed in and we are loading tabs

The only possible problem I can see here is that we might flash the wrong UI for a moment. That can probably be worked around.

sooooooooo i dug more into this

a) we should fix the console error that happens when <iron-location>/<history-router> get initialized and try to show the synced tab page before the lazy load bundle is ready.  there's a lot of ways to do this, most of them result in flicker when loading /syncedTab.  ¯\_(ツ)_/¯ whatcha gonna do?  here's one way:
https://codereview.chromium.org/2456783006/

b) I was thinking that in order to avoid recreating the data sources a lot, we should package up a little update (like a base::DictionaryValue) and add an interface from content/public to *update* a WebUIDataSource.  you can basically be sure that one exists if the page is open, you just can't guarantee it's the same one if other pages have been created (they generally replace).  the updates would need to be applied on a different thread, but are probably guaranteed to be eventually consistent (just like a data source is guaranteed to eventually be associated with URL requests and are added on the IO thread via PostTask()).

I thought of a bunch of other hacks (i.e. inlining the image via grit instead), but it ultimately doesn't fix other types of data races that may apply from repeatedly re-creating data sources.  My proposal might also just trade the old problems for new one, we'll see.

btw, this seems to only happen when the page loads in the background

that means that session restore could probably tickle this, but it filters out even more cases it could happen

Issue is reproduced in Latest chrome canary M57 # 57.0.2926.0 .

@dbeam -- can we get latest update on this ??

Thanks!

Issue is still reproducible in Latest chrome canary M57 # 57.0.2935.0

dbeam@, Could you please take a look

i don't think this is particularly bad.  i'm not super happy with the solution i've come up with so far.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25af85bdf26ac7dbfa4a3ba1b408da2634c94345

commit 25af85bdf26ac7dbfa4a3ba1b408da2634c94345
Author: dbeam <dbeam@chromium.org>
Date: Fri Dec 09 03:34:37 2016

MD History: update (instead of re-create) data sources on sign in change

BUG= 659487 

Review-Url: https://codereview.chromium.org/2475593002
Cr-Commit-Position: refs/heads/master@{#437451}

[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/chrome/browser/ui/webui/history_ui.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/chrome/browser/ui/webui/history_ui.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/chrome/browser/ui/webui/md_history_ui.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/chrome/browser/ui/webui/md_history_ui.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_manager.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_manager.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_manager_backend.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_manager_backend.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_source_impl.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/url_data_source_impl.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/web_ui_data_source_impl.cc
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/browser/webui/web_ui_data_source_impl.h
[modify] https://crrev.com/25af85bdf26ac7dbfa4a3ba1b408da2634c94345/content/public/browser/web_ui_data_source.h

I think there is still an issue regarding buffering resources while data sources are rebuilt.

this CL ^ side-steps the issue, but I'm not sure how to easily fix the original issue because the only way I know how would be:

a) buffer an entire resource in memory, then slowly empty it into a request response
b) add or invoke some sort of invalidation API in URLDataSourceBackend

again, the initial issue is that a datasource's resources change in the middle of responding to a fake net request (from a chrome:// page).