Sure, that would work, although there may be a case for the content script being able to access both. Since the content script runs in the context of the page, the current behavior of "localStorage" referring to the page's localStorage is arguably correct. To access the extension's localStorage, the content script could go through a chrome-specific API, as is currently the precedent when the content script needs to communicate with the rest of the extension.
On Sat, Nov 28, 2009 at 2:11 PM, Aaron Boodman <a...@google.com> wrote: > On Sat, Nov 28, 2009 at 1:49 PM, Phil Crosby <phil.cro...@gmail.com> wrote: >> Hey Aaron, thanks for the followup. I have the content script set to >> run at document_start. >> >> I'm not sure I follow about the localStorage limitation in content >> scripts; I wrote a small test which demonstrates that referencing and >> modifying "localStorage" in a content script modifies the same >> localStorage that the webpage has access to. This is with Mac Chrome >> 4.0.249.12. > > That's surprising. My understanding was that it did not work, but > hooray, I guess that has been fixed. > >> I could use the page's localStorage as a cache but as you mentioned >> that has the downside of creating localStorage all over the place, >> which is likely to never go away. A more tidy hack would be to use >> session storage (which I think is coming soon to Chrome) as a cache, >> but then I would have access to the data I need only on subsequent >> loads of the page during that browser session -- not the first load. >> >> I guess the ideal solution for my needs would be for content scripts >> to be able to access the background page's localStorage directly, and >> barring that, to have a lower-latency connection to the background >> page. Since the latency was purposefully engineered for performance >> reasons, the former is probably the more realistic feature request. > > Yeah, I think we already have things setup so that multiple processes > can access local storage synchronously (note that behind the scenes > this implies a global lock). > > We would just need to make it so that access from a content script > acesses the extensions' local storage, not the page's. > > - a > -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
