Web App Development

InspectorFrontendHost 28 July 2016

Spent the day trying to fix this issue. If you edit snippets in two different DevTools instances at the same time saved snippets are overwritten and lost.

The fundamental issue is that DevTools is loading all settings (including snippets) on page load. After that it never tries to load them again.

That means when you update a snippet in tab A then tab B won’t know about it. All snippets are always saved together as one big setting. So when you then save a snippet in tab B all snippet data will be overwritten and the change made in tab A is lost.

I wasn’t sure what the best way to go about the problem was and someone suggested listening to the “storage” event that fires when localStorage data is updated. DevTools settings are stored in localStorage… sort of.

I fixed the issue using the “storage” event, so when saving a snippet DevTools would base the next saved value on the current saved data, rather than replacing everything.


Throughout the day one thing confused me. Each setting has a storage attached to it, for example localStorage. But there seemed to be a lot of unnecessary complexity and abstraction. Even though some settings were marked as isLocal and others weren’t, all settings would be saved in localStorage.

That’s when I found out about InspectorFrontendHost.

While I still don’t quite get its purpose, InspectorFrontendHost seems to connect the DevTools frontend web app to the DevTools backend.

However, it turns out there are two versions. One appears to be used when running the DevTools UI on simple static-ish server, while the other is used in the integrated Chrome build.

Check out the getPreferences function in both implementations:

/frontend/devtools.js (integrated build)

getPreferences: function(callback)
    DevToolsAPI.sendMessageToEmbedder("getPreferences", [], /** @type {function(?Object)} */ (callback));

/frontend/host/InspectorFrontendHost.js (static-ish server)

getPreferences: function(callback)
    var prefs = {};
    for (var name in window.localStorage)
        prefs[name] = window.localStorage[name];

During development all settings are stored in localStorage, even the non-local ones!

That means my solution that relies on the “storage” event won’t work in the actual build.

There doesn’t seem to be a similar event for preferences that are stored in the Chrome profile. I could use getPreferences, but for now I’ve left a comment on the issue asking if that would be an acceptable solution.