Hey Aaron -- That's a great idea, but I was under the impression - based on very limited play time with Chrome! - that content scripts had no direct access to the Javascript objects in the page?
Actually, I've just found http://www.aaronboodman.com/2009/04/content-scripts-in-chromium.html which is a fantastic intro. (A link to, or variation of this would be great on the new extension site). Is that blog post still accurate? Or perhaps more usefully for others reading this, is there a best practice for accessing in page variables? (e.g. gmonkey, the XHR prototype) The choices I can see... 1) contentWindow - you talk about closing this off, is it going to be around for the foreseeable future? 2) Inject a <script> element into the page with the wrapping code, and use DOM elements/events to pass data back out. It's great to be able to hear directly from you guys, any insight on this particular topic would be very useful indeed :) Andy On Oct 3, 5:32 pm, Aaron Boodman <[email protected]> wrote: > Hi Andy, > > First off, we'd love to have GTDInbox for Chrome, so we're really > happy to hear you're investigating support. > > Starting with a read-only version of the HTTP request interception API > seems reasonable to me. Unfortunately, we're really buckling down > right now on getting a minimum viable v1 out the door, so I don't > think we can do this, at least with the current core team. We do > recognize, thought, that it is a high priority for post-v1. > > As a short-term hack until then, have you considered wrapping > XMLHttpRequest? It seems like you could modify the XMLHttpRequest > constructor so that all the requests go through your code, and then > delegate that to the same core code you use in other browsers. > > - a > > On Sat, Oct 3, 2009 at 3:34 AM, Andy Mitchell <[email protected]> wrote: > > > Hi guys, > > > I'm beginning to look at porting GTDInbox for Gmail (http:// > >www.gtdinbox.com) to Chrome - a lot of our users are wanting to use > > Chrome! > > > The one major barrier holding us back is the inability to monitor HTTP > > requests. We absolutely rely on them to detect environment actions > > (e.g. thread label added/removed, new messages arrived, etc.) to keep > > our view of the user's data accurate. There's no other robust way for > > us to work with Gmail (we cannot bear to go back to DOM event > > monitoring!). > > > Note that we don't need to modify the HTTP Requests. We just need read- > > only access to them, whereupon we do some string parsing to extract > > the events that they represent. (In fact, most event monitoring only > > requires the URL parameter of the request, although it would be more > > robust to be able to read the additional data as well). > > > I think this is quite a generic requirement for anyone working with > > modern web apps, where the only way to stay up to date with state > > changes is to be able to watch those AJAX requests. > > > This aside, I'm really looking forward to porting to Chrome - it all > > seems very clean and refreshingly straightforward :) > > Andy > > > PS This is similar to the earlier > >http://groups.google.com/group/chromium-extensions/browse_thread/thre... > > . But, it seems the main objection there was performance wrt to the > > ability to also write to the request stack. I'm hopeful that a simple > > read-only solution, perhaps as a first step, would not incur such a > > cost. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
