3

I am new to both JavaScript and Chrome development, and am trying to create an extension that injects content/CSS in certain web pages. Simple enough, but the catch is that to do so it requires looking through a significant amount of data in local storage. From what I've read so far, the correct way to do this would be either:

  1. Reading the required data (JSON serialized) from storage directly from the content script every time the page is visited, or
  2. Maintaining the state in the extension background page and transferring the required data (also JSON serialized) to the content script environment using message passing.

Either of these approaches, however, would be extremely inefficient due to large amounts of data being needlessly serialized and deserialized on every page load.

So, I want to know:

  • Is it in any way possible to maintain a shared memory cache in Chrome that content scripts injected in all tabs can access?

  • If not, is an alternate approach possible where the background page listens for the chrome.tabs.onUpdated event and somehow modifies the target DOM itself?

Alex L
  • 41
  • 2
  • Have you tried using [chrome.runtime.getBackgroundPage](https://developer.chrome.com/extensions/runtime#method-getBackgroundPage)? – abraham Aug 22 '14 at 18:40
  • Doesn't work, since an injected content script does not have access to that method. – Alex L Aug 22 '14 at 18:51

2 Answers2

0

1) I don't think this is possible. You seem to have exhausted the possibilities.

2) Content scripts are the only way to access/modify a normal tab's DOM.

Xan
  • 74,770
  • 16
  • 179
  • 206
0

1- Reading the required data (JSON serialized) from storage directly from the content script every time the page is visited.

But you have to do that every time your page is loaded which you want to avoid (I guess)

2- Maintaining the state in the extension background page and transferring the required data (also JSON serialized) to the content script environment using message passing.

The only way to make Content Scripts and Background scripts interact is via Message Passing. You are not actually looking to an alternative solution but you want to improve the process and avoid message passing each time a page is loaded.

For this, you can develop a spec. The spec states for which URLs or which Domains or based on some condition you want to get the data from Background. If your current URL/Tab agrees with spec only then pass a message to background.

Optionally, Background can also do the same and send message only if your spec is followed. Moreover, when your extension is loaded, you can also cache the storage into local variable.

Use Chrome Storage API to listen for changes in storage and update your local data copy accordingly.

You can also look at this code written by me using the same approach.

Sachin Jain
  • 21,353
  • 33
  • 103
  • 168
  • **False**, `chrome.storage` is directly accessible from content scripts. – Xan Aug 23 '14 at 10:12
  • @Xan Yes you are **right**. I should update my words. Actually I meant to say you should not have a cached copy of data in content scripts. You should only do that by background script. Because if you want to avoid multiple reads from chrome storage then content script should not read from storage. – Sachin Jain Aug 23 '14 at 10:19
  • That's not what you wrote though. And why can't a content script have it own cached copy, maintained by the same `onChanged` events? – Xan Aug 23 '14 at 10:20
  • Because cached copy will be destroyed when tab is loaded or say another URL is opened in new tab. Better approach should be to have it in background and ask background via Message Passing whenever page is loaded. – Sachin Jain Aug 23 '14 at 10:23
  • True. Now, observe you did not answer the OP's questions, which are further down in the text. – Xan Aug 23 '14 at 11:14