Initial Greasemonkey support

Adds a bit of Greasemonkey support hidden behind the --enable-greasemonkey flag. Implementation follows the pattern of the visited links system.

Things still to be done:
- stop using a hardcoded script directory
- watch script directory and update shared memory when necessary
- move file io to background thread
- support for @include patterns -- now, all scripts are applied to all pages

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=3496

[Evan Martin, 2008-10-13 21:51:57]

On 2008/10/11 05:32:11, Aaron Boodman wrote:
> 

This looks pretty good to me... my comments are mostly details.
One top-level question: does all this code belong in its own directory?  I feel
like the browser/ directory is full of junk already...

[Evan Martin, 2008-10-13 21:52:16]

Ack, hit wrong button.  Here are the comments I promised.

http://codereview.chromium.org/7254/diff/241/243
File chrome/browser/greasemonkey_master.cc (right):

http://codereview.chromium.org/7254/diff/241/243#newcode29
Line 29: // figure out the size of shared memory to allocate
Capitals and period on this comment

http://codereview.chromium.org/7254/diff/241/243#newcode50
Line 50: return false;
-2 indent here

http://codereview.chromium.org/7254/diff/241/243#newcode59
Line 59: char *dest = static_cast<char*>(temp_shared_memory->memory());
Chrome style is stars on the left, e.g. "char* dest = ...".

http://codereview.chromium.org/7254/diff/241/243#newcode61
Line 61: // Size of memory block
period

http://codereview.chromium.org/7254/diff/241/243#newcode63
Line 63: dest += sizeof(int);
I wonder if all of this could be made easier with base/pickle.h:
// The Pickle class supports appending primitive values (ints, strings, etc.)
// to a pickle instance.  The Pickle instance grows its internal memory buffer
// dynamically to hold the sequence of primitive values.   The internal memory
// buffer is exposed as the "data" of the Pickle.  This "data" can be passed
// to a Pickle object to initialize it for reading.

http://codereview.chromium.org/7254/diff/241/243#newcode87
Line 87: SharedMemoryHandle *new_handle) {
star on the left

http://codereview.chromium.org/7254/diff/241/243#newcode102
Line 102: return StringPrintf(L"GVisitedLinks_%lu_%lu_%ls",
Probably don't want "VisitedLinks" here.

http://codereview.chromium.org/7254/diff/241/242
File chrome/browser/greasemonkey_master.h (right):

http://codereview.chromium.org/7254/diff/241/242#newcode23
Line 23: // Reloads scripts from disk into a new chunk of shared memory and
notify
Grammar typo:  "Reloads X and notify Zs."  I think you mean "notifies"?

http://codereview.chromium.org/7254/diff/241/242#newcode27
Line 27: // Duplicates the handle to the shared memory to another process.
It's not clear to me what this means.  "Duplicates the handle to ..." ?

http://codereview.chromium.org/7254/diff/241/242#newcode37
Line 37: std::wstring GetSharedMemoryName() const;
Private functions and variables need docs too.  :)

http://codereview.chromium.org/7254/diff/241/242#newcode42
Line 42: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeyMaster);
DISALLOW_COPY_AND_ASSIGN instead

http://codereview.chromium.org/7254/diff/241/244
File chrome/browser/render_process_host.cc (right):

http://codereview.chromium.org/7254/diff/241/244#newcode422
Line 422: // Send the process it's initial VisitedLink and Greasemonkey data.
s/it's/its/

http://codereview.chromium.org/7254/diff/241/244#newcode453
Line 453: DCHECK(handle_for_process);
If this fails we probably don't want to call channel_->Send below

http://codereview.chromium.org/7254/diff/241/250
File chrome/common/chrome_paths.cc (right):

http://codereview.chromium.org/7254/diff/241/250#newcode133
Line 133: cur = L"C:\\SCRIPTS\\";
Don't forget a TODO here to put these in the user profile dir.  (Or just fix
this to use the correct dir.)

http://codereview.chromium.org/7254/diff/241/247
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/7254/diff/241/247#newcode158
Line 158: // Notification that the Greasemonkey scripts have been updated.
Maybe this comment should match the one above with its details (what the
argument is, where the handle is valid).

http://codereview.chromium.org/7254/diff/241/259
File chrome/renderer/greasemonkey_slave.cc (right):

http://codereview.chromium.org/7254/diff/241/259#newcode7
Line 7: #include "chrome/renderer/greasemonkey_slave.h"
should be first #include

http://codereview.chromium.org/7254/diff/241/259#newcode27
Line 27: // create the shared memory object
capitals, periods

http://codereview.chromium.org/7254/diff/241/259#newcode47
Line 47: int num_scripts = *reinterpret_cast<int*>(source);
This (and following ints) could be bit_cast<> (see basictypes.h)

http://codereview.chromium.org/7254/diff/241/259#newcode58
Line 58: delete script;
If the script is deleted, you don't want to push it on the script list.  Better
something like

scoped_ptr<GMS> script(new ...);
if (parse succeeds) {
  scripts_.push_back(script.release());
}

http://codereview.chromium.org/7254/diff/241/259#newcode72
Line 72: // std::string and then again into WebCore::String.
That does suck, but on the other hand it only happens if the script applies to
the frame.

http://codereview.chromium.org/7254/diff/241/260
File chrome/renderer/greasemonkey_slave.h (right):

http://codereview.chromium.org/7254/diff/241/260#newcode5
Line 5: #ifndef CHROME_WIN_RENDERER_GREASEMONKEY_SLAVE_H__
The "WIN_" part isn't necessary, right?

http://codereview.chromium.org/7254/diff/241/260#newcode21
Line 21: StringPiece GetBody() const {
const StringPiece&  ?

http://codereview.chromium.org/7254/diff/241/260#newcode25
Line 25: bool Parse(const StringPiece &script_text) {
& on the left

http://codereview.chromium.org/7254/diff/241/260#newcode32
Line 32: StringPiece body_;
doc this (in particular the lifetime of the string pointed to)

http://codereview.chromium.org/7254/diff/241/260#newcode34
Line 34: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeyScript);
COPY_AND_ASSIGN

http://codereview.chromium.org/7254/diff/241/260#newcode38
Line 38: // Reads the link coloring database provided by the master. There can
be any
This comment is from the other code :)

http://codereview.chromium.org/7254/diff/241/260#newcode62
Line 62: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeySlave);
COPY_AND_ASSIGN

http://codereview.chromium.org/7254/diff/241/260#newcode65
Line 65: #endif // CHROME_WIN_RENDERER_GREASEMONKEY_SLAVE_H__
s/WIN_//

http://codereview.chromium.org/7254/diff/241/257
File chrome/renderer/render_view.cc (right):

http://codereview.chromium.org/7254/diff/241/257#newcode1368
Line 1368: if (!frame->GetURL().SchemeIs("chrome-resource")) {
Why this test?  Hrmmm... maybe we only want to inject on SchemeIs("http") ?

http://codereview.chromium.org/7254/diff/241/254
File webkit/glue/webframe.h (right):

http://codereview.chromium.org/7254/diff/241/254#newcode98
Line 98: const std::string &file_url) = 0;
& on the left

http://codereview.chromium.org/7254/diff/241/253
File webkit/glue/webframe_impl.cc (right):

http://codereview.chromium.org/7254/diff/241/253#newcode1595
Line 1595: const std::string &file_url) {
spacing

http://codereview.chromium.org/7254/diff/241/253#newcode1596
Line 1596:
frame_->loader()->executeScript(webkit_glue::StdStringToString("userscript"),
should this be using file_url?

http://codereview.chromium.org/7254/diff/241/255
File webkit/glue/webframe_impl.h (right):

http://codereview.chromium.org/7254/diff/241/255#newcode98
Line 98: const std::string &file_url);
& on the left

[Aaron Boodman, 2008-10-14 17:42:37]

Ok, new patch. Thanks for the pointer to Pickle. That makes things much cleaner.

As for moving the new files to a new directory, I don't have a strong opinion. I
did it this way because that is how visited links are implemented and I was
copying that. Is the convention stronger to group things into browser/render or
into verticals that cross browser/render processes?

http://codereview.chromium.org/7254/diff/241/243
File chrome/browser/greasemonkey_master.cc (right):

http://codereview.chromium.org/7254/diff/241/243#newcode29
Line 29: // figure out the size of shared memory to allocate
On 2008/10/13 21:52:16, Evan Martin wrote:
> Capitals and period on this comment

Done.

http://codereview.chromium.org/7254/diff/241/243#newcode50
Line 50: return false;
On 2008/10/13 21:52:16, Evan Martin wrote:
> -2 indent here

Done.

http://codereview.chromium.org/7254/diff/241/243#newcode59
Line 59: char *dest = static_cast<char*>(temp_shared_memory->memory());
On 2008/10/13 21:52:16, Evan Martin wrote:
> Chrome style is stars on the left, e.g. "char* dest = ...".

N/A because I changed this chunk of code. I tried to find all the
Google-style-is-star-on-the-right-but-not-in-Chrome-because-we're-special cases,
though.

http://codereview.chromium.org/7254/diff/241/243#newcode63
Line 63: dest += sizeof(int);
On 2008/10/13 21:52:16, Evan Martin wrote:
> I wonder if all of this could be made easier with base/pickle.h:
> // The Pickle class supports appending primitive values (ints, strings, etc.)
> // to a pickle instance.  The Pickle instance grows its internal memory buffer
> // dynamically to hold the sequence of primitive values.   The internal memory
> // buffer is exposed as the "data" of the Pickle.  This "data" can be passed
> // to a Pickle object to initialize it for reading.
> 

Oh, I didn't know about Pickle. Changed to use that.

http://codereview.chromium.org/7254/diff/241/243#newcode87
Line 87: SharedMemoryHandle *new_handle) {
On 2008/10/13 21:52:16, Evan Martin wrote:
> star on the left

Done.

http://codereview.chromium.org/7254/diff/241/243#newcode102
Line 102: return StringPrintf(L"GVisitedLinks_%lu_%lu_%ls",
On 2008/10/13 21:52:16, Evan Martin wrote:
> Probably don't want "VisitedLinks" here.

Yikes, nice catch. Fixed.

http://codereview.chromium.org/7254/diff/241/242
File chrome/browser/greasemonkey_master.h (right):

http://codereview.chromium.org/7254/diff/241/242#newcode23
Line 23: // Reloads scripts from disk into a new chunk of shared memory and
notify
On 2008/10/13 21:52:16, Evan Martin wrote:
> Grammar typo:  "Reloads X and notify Zs."  I think you mean "notifies"?

Done.

http://codereview.chromium.org/7254/diff/241/242#newcode27
Line 27: // Duplicates the handle to the shared memory to another process.
On 2008/10/13 21:52:16, Evan Martin wrote:
> It's not clear to me what this means.  "Duplicates the handle to ..." ?

Done.

http://codereview.chromium.org/7254/diff/241/242#newcode37
Line 37: std::wstring GetSharedMemoryName() const;
On 2008/10/13 21:52:16, Evan Martin wrote:
> Private functions and variables need docs too.  :)

Done.

http://codereview.chromium.org/7254/diff/241/242#newcode42
Line 42: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeyMaster);
On 2008/10/13 21:52:16, Evan Martin wrote:
> DISALLOW_COPY_AND_ASSIGN instead

Done.

http://codereview.chromium.org/7254/diff/241/244
File chrome/browser/render_process_host.cc (right):

http://codereview.chromium.org/7254/diff/241/244#newcode422
Line 422: // Send the process it's initial VisitedLink and Greasemonkey data.
On 2008/10/13 21:52:16, Evan Martin wrote:
> s/it's/its/

Done.

http://codereview.chromium.org/7254/diff/241/244#newcode453
Line 453: DCHECK(handle_for_process);
On 2008/10/13 21:52:16, Evan Martin wrote:
> If this fails we probably don't want to call channel_->Send below

Done.

http://codereview.chromium.org/7254/diff/241/250
File chrome/common/chrome_paths.cc (right):

http://codereview.chromium.org/7254/diff/241/250#newcode133
Line 133: cur = L"C:\\SCRIPTS\\";
On 2008/10/13 21:52:16, Evan Martin wrote:
> Don't forget a TODO here to put these in the user profile dir.  (Or just fix
> this to use the correct dir.)

I added a TODO. It's not immediately obvious where the scripts dir(s) should be,
so I'd rather leave this for a separate change.

http://codereview.chromium.org/7254/diff/241/247
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/7254/diff/241/247#newcode158
Line 158: // Notification that the Greasemonkey scripts have been updated.
On 2008/10/13 21:52:16, Evan Martin wrote:
> Maybe this comment should match the one above with its details (what the
> argument is, where the handle is valid).

Done.

http://codereview.chromium.org/7254/diff/241/259
File chrome/renderer/greasemonkey_slave.cc (right):

http://codereview.chromium.org/7254/diff/241/259#newcode7
Line 7: #include "chrome/renderer/greasemonkey_slave.h"
On 2008/10/13 21:52:16, Evan Martin wrote:
> should be first #include

Done.

http://codereview.chromium.org/7254/diff/241/259#newcode27
Line 27: // create the shared memory object
On 2008/10/13 21:52:16, Evan Martin wrote:
> capitals, periods

Done.

http://codereview.chromium.org/7254/diff/241/259#newcode58
Line 58: delete script;
On 2008/10/13 21:52:16, Evan Martin wrote:
> If the script is deleted, you don't want to push it on the script list. 
Better
> something like
> 
> scoped_ptr<GMS> script(new ...);
> if (parse succeeds) {
>   scripts_.push_back(script.release());
> }

Ah, good catch. Thanks.

http://codereview.chromium.org/7254/diff/241/259#newcode72
Line 72: // std::string and then again into WebCore::String.
On 2008/10/13 21:52:16, Evan Martin wrote:
> That does suck, but on the other hand it only happens if the script applies to
> the frame.

Ok. I tried changing ExecuteJavaScript to take StringPiece, but it becomes this
long chain of changes because also the utilities that do conversion to WebCore
types also have to be changed.

http://codereview.chromium.org/7254/diff/241/260
File chrome/renderer/greasemonkey_slave.h (right):

http://codereview.chromium.org/7254/diff/241/260#newcode5
Line 5: #ifndef CHROME_WIN_RENDERER_GREASEMONKEY_SLAVE_H__
On 2008/10/13 21:52:16, Evan Martin wrote:
> The "WIN_" part isn't necessary, right?

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode21
Line 21: StringPiece GetBody() const {
On 2008/10/13 21:52:16, Evan Martin wrote:
> const StringPiece&  ?

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode25
Line 25: bool Parse(const StringPiece &script_text) {
On 2008/10/13 21:52:16, Evan Martin wrote:
> & on the left

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode32
Line 32: StringPiece body_;
On 2008/10/13 21:52:16, Evan Martin wrote:
> doc this (in particular the lifetime of the string pointed to)

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode34
Line 34: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeyScript);
On 2008/10/13 21:52:16, Evan Martin wrote:
> COPY_AND_ASSIGN

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode38
Line 38: // Reads the link coloring database provided by the master. There can
be any
On 2008/10/13 21:52:16, Evan Martin wrote:
> This comment is from the other code :)

Whoops, fixed. Thanks.

http://codereview.chromium.org/7254/diff/241/260#newcode62
Line 62: DISALLOW_EVIL_CONSTRUCTORS(GreasemonkeySlave);
On 2008/10/13 21:52:16, Evan Martin wrote:
> COPY_AND_ASSIGN

Done.

http://codereview.chromium.org/7254/diff/241/260#newcode65
Line 65: #endif // CHROME_WIN_RENDERER_GREASEMONKEY_SLAVE_H__
On 2008/10/13 21:52:16, Evan Martin wrote:
> s/WIN_//

Done.

http://codereview.chromium.org/7254/diff/241/257
File chrome/renderer/render_view.cc (right):

http://codereview.chromium.org/7254/diff/241/257#newcode1368
Line 1368: if (!frame->GetURL().SchemeIs("chrome-resource")) {
On 2008/10/13 21:52:16, Evan Martin wrote:
> Why this test?  Hrmmm... maybe we only want to inject on SchemeIs("http") ?

I think it is fair game to inject scripts into ftp:// (fancy directory
listings), https:// (gmail), file:// (for testing), etc. chrome-resource:// is
the only one I can think of that doesn't make much sense, and I guess even that
is debatable.

http://codereview.chromium.org/7254/diff/241/254
File webkit/glue/webframe.h (right):

http://codereview.chromium.org/7254/diff/241/254#newcode98
Line 98: const std::string &file_url) = 0;
On 2008/10/13 21:52:16, Evan Martin wrote:
> & on the left

Done.

http://codereview.chromium.org/7254/diff/241/253
File webkit/glue/webframe_impl.cc (right):

http://codereview.chromium.org/7254/diff/241/253#newcode1595
Line 1595: const std::string &file_url) {
On 2008/10/13 21:52:16, Evan Martin wrote:
> spacing

Done.

http://codereview.chromium.org/7254/diff/241/253#newcode1596
Line 1596:
frame_->loader()->executeScript(webkit_glue::StdStringToString("userscript"),
On 2008/10/13 21:52:16, Evan Martin wrote:
> should this be using file_url?

Thanks, fixed.

http://codereview.chromium.org/7254/diff/241/255
File webkit/glue/webframe_impl.h (right):

http://codereview.chromium.org/7254/diff/241/255#newcode98
Line 98: const std::string &file_url);
On 2008/10/13 21:52:16, Evan Martin wrote:
> & on the left

Done.

[darin (slow to review), 2008-10-14 18:02:44]

http://codereview.chromium.org/7254/diff/268/270
File chrome/browser/greasemonkey_master.cc (right):

http://codereview.chromium.org/7254/diff/268/270#newcode19
Line 19: file_util::FileEnumerator enumerator(path, false,
what thread does this run on?  directory enumeration on the UI thread is BAD :)

it'd be good if this file had a high level overview of what threads are
involved, etc.

http://codereview.chromium.org/7254/diff/268/270#newcode82
Line 82: return StringPrintf(L"GGreasemonkeyScripts_%lu_%lu_%ls",
is the "G" prefix for google?  we tend to use "Chrome_" instead to prefix names.

http://codereview.chromium.org/7254/diff/268/271
File chrome/browser/render_process_host.cc (right):

http://codereview.chromium.org/7254/diff/268/271#newcode438
Line 438: CommandLine command_line;
nit: RenderProcessHost::Init is absurdly long.  not your fault, but it would be
great if the new functionality were moved into a helper method.

http://codereview.chromium.org/7254/diff/268/287
File chrome/renderer/greasemonkey_slave.h (right):

http://codereview.chromium.org/7254/diff/268/287#newcode63
Line 63: std::vector<GreasemonkeyScript*> scripts_;
nit: looks like this can be std::vector<GreasemonkeyScript> instead.

http://codereview.chromium.org/7254/diff/268/278
File chrome/renderer/render_thread.cc (right):

http://codereview.chromium.org/7254/diff/268/278#newcode156
Line 156: Singleton<GreasemonkeySlave>::get()->UpdateScripts(scripts);
why use Singleton here?  why not just make GreasemonkeySlave be a member of
RenderThread like visited_link_slave_?  if you just make it a member variable,
it will still only be allocated once per renderer process.

http://codereview.chromium.org/7254/diff/268/284
File chrome/renderer/render_view.cc (right):

http://codereview.chromium.org/7254/diff/268/284#newcode1369
Line 1369: if (!frame->GetURL().SchemeIs("chrome-resource")) {
maybe this should be a whitelist instead?  allowed to inject into "http",
"https", and nothing else?  or, maybe include "file" and "ftp"?  probably
doesn't make sense to inject into view-cache: or other crazy internal schemes. 
it could be a pain to have to update this list with all of the crazy internal
schemes when one of the crazy internal schemes changes.

http://codereview.chromium.org/7254/diff/268/281
File webkit/glue/webframe.h (right):

http://codereview.chromium.org/7254/diff/268/281#newcode98
Line 98: const std::string& file_url) = 0;
does file_url have to be a file:// URL?  i'm guessing no, but the name is kind
of confusing.  how about naming it "origin_url" and explain that it is the URL
corresponding to the origin of the js_code?  it is good to mention that this URL
is optional and not used to implement any security policy.  purely informational
only (e.g., shown in the JS console if an error occurs).

RenderView::OnMessageFromExternalHost should probably be changed to use this new
API.  Or, at least file a bug against Amit for that change.

[cpu_(ooo_6.6-7.5), 2008-10-15 23:50:15]

http://codereview.chromium.org/7254/diff/268/270
File chrome/browser/greasemonkey_master.cc (right):

http://codereview.chromium.org/7254/diff/268/270#newcode48
Line 48: false, // read-only
Why does it need a name? Unamed objects are more secure.

[Aaron Boodman, 2008-10-16 17:32:29]

Thanks Darin and Carlos. I've uploaded a patch that addresses your comments,
except where noted below...

http://codereview.chromium.org/7254/diff/268/270
File chrome/browser/greasemonkey_master.cc (right):

http://codereview.chromium.org/7254/diff/268/270#newcode19
Line 19: file_util::FileEnumerator enumerator(path, false,
On 2008/10/14 18:02:45, darin wrote:
> what thread does this run on?  directory enumeration on the UI thread is BAD
:)
> 
> it'd be good if this file had a high level overview of what threads are
> involved, etc.

I put a TODO where UpdateScripts() is called to move it off the UI thread.

http://codereview.chromium.org/7254/diff/268/270#newcode48
Line 48: false, // read-only
On 2008/10/15 23:50:15, cpu wrote:
> Why does it need a name? Unamed objects are more secure.

Good point, killed it.

http://codereview.chromium.org/7254/diff/268/287
File chrome/renderer/greasemonkey_slave.h (right):

http://codereview.chromium.org/7254/diff/268/287#newcode63
Line 63: std::vector<GreasemonkeyScript*> scripts_;
On 2008/10/14 18:02:45, darin wrote:
> nit: looks like this can be std::vector<GreasemonkeyScript> instead.

There will eventually be more strings in here (filename, include, etc) so I'd
rather leave as-is.

http://codereview.chromium.org/7254/diff/268/281
File webkit/glue/webframe.h (right):

http://codereview.chromium.org/7254/diff/268/281#newcode98
Line 98: const std::string& file_url) = 0;
On 2008/10/14 18:02:45, darin wrote:
> RenderView::OnMessageFromExternalHost should probably be changed to use this
new
> API.  Or, at least file a bug against Amit for that change.

I looked at changing everyone who is using javascript URLs to use this, but I
don't want to do it because it current callers sometimes escape, sometimes don't
escape, sometimes partially escape, and I don't want to break anything.

I will file bugs against the owners instead.

[Aaron Boodman, 2008-10-16 17:38:03]

BTW, I'm thinking more and more that the piggybacking on the loader would have
been a better way to implement this. One benefit would be that URLs for the
inspector would come for free. Also, there would be an easy path to implementing
the @resource and @require features of Greasemonkey, which allow scripts to rely
on auxiliary images, CSS, and JS libraries.

But, I'd still like to check this in for now to unblock Evan.

[Evan Martin, 2008-10-16 19:22:50]

LGTM, only minor nits

http://codereview.chromium.org/7254/diff/402/161
File chrome/browser/render_process_host.cc (right):

http://codereview.chromium.org/7254/diff/402/161#newcode441
Line 441: if (!visitedlink_master) return;
I think we put the "return" on its own line.

http://codereview.chromium.org/7254/diff/402/161#newcode453
Line 453: if (!command_line.HasSwitch(switches::kEnableGreasemonkey)) return;
I think we put the "return" on its own line.

http://codereview.chromium.org/7254/diff/402/169
File chrome/renderer/render_thread.h (right):

http://codereview.chromium.org/7254/diff/402/169#newcode129
Line 129: GreasemonkeySlave* greasemonkey_slave_;
coudl be a scoped_ptr, but whatev

[Aaron Boodman, 2008-10-16 23:36:35]

One more patch. Also changed the vector to contain GreasemonkeyScript instances
instead of pointers, per Darin.

http://codereview.chromium.org/7254/diff/402/169
File chrome/renderer/render_thread.h (right):

http://codereview.chromium.org/7254/diff/402/169#newcode129
Line 129: GreasemonkeySlave* greasemonkey_slave_;
On 2008/10/16 19:22:50, Evan Martin wrote:
> coudl be a scoped_ptr, but whatev

Just going to leave it so it's the same as VisitedLinkSlave.

[DoubleAW, 2008-10-25 19:42:35]

On 2008/10/11 05:32:11, Aaron Boodman wrote:
> - stop using a hardcoded script directory

Would there be a possibility to subscribe to scripts that are remotely hosted
elsewhere?