Chrome Version: 61.0.3151.0
OS: Win10

What steps will reproduce the problem?
(1) Find a loadTimeData value which can change during a browser session (for ease of reproduction, apply attached patch and visit settings)
(2) Open a WebUI page (ex. chrome://settings) and observe the loadTimeData value.
(3) Refresh the WebUI page and observe that the loadTimeData value does not change.
(4) Have the state change such that a different loadTimeData value will be sent next time the WebUI page is opened.
(5) Refresh the WebUI page and observe that the loadTimeData value did not change.
(6) Open a new tab or page of the same WebUI.
(7) Observe that the new tab uses the new loadTimeData value.
(8) Refresh the original WebUI page and observe the loadTimeData value. 

What is the expected result?
The original WebUI page's loadTimeData value should not have changed. 

What happens instead?
The original WebUI page's loadTimeData now contains the new loadTimeData value.


Alternative expected result: the result could have changed after step #4 and the new value observed in step #5. What's unexpected is that step #6 is what causes the value to change in the original WebUI after a refresh. Opening a new tab should not have an effect on existing WebUI tabs.


From @dpapad:
Regarding the question of why does tab#1 start returning loadTimeData B, I think I found the reason. When a new MdSettingsUI instance is created, it is registering its own html_source_ (instance of content::WebUIDataSource) in a global map/registry, see [1] below, overwriting any previous entries. So when chrome://settings/strings.js is requested the next time, is using the html_source_ of the 2nd tab. This is my theory, by inspecting the code, have not verified.

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/settings/md_settings_ui.cc?l=256
 

Deleted: reset_settings.patch 1004 bytes

reset_settings.patch 1004 bytes Download