Various minor extension fixes

Various minor fixes:
* --load-extension no longer requires --enable-extensions
* No longer support chrome:// URLs for user scripts
* Remove old unused Greasemonkey test
* Enable Greasemonkey API emulation in linux/mac

BUG=16720, 16007, 4476
TEST=Added several unit tests

[Erik does not do reviews, 2009-07-14 20:22:38]

LGTM - just small suggestions

One other question - I didn't understand from the description why the
greasemonkey API test is unused and you removed it.  It seems useful.

http://codereview.chromium.org/149619/diff/1001/1003
File chrome/browser/extensions/extension_startup_unittest.cc (right):

http://codereview.chromium.org/149619/diff/1001/1003#newcode99
Line 99: void WaitForServicesToStart(int num_expected_extensions,
seems like it would be useful to have a num_expected_user_scripts as well

http://codereview.chromium.org/149619/diff/1001/1003#newcode174
Line 174: WaitForServicesToStart(3, true);
we've got multiple tests that depend on the number of extensions in
extensions/good/Extensions. it would be good if this were a constant that was
pulled out somewhere so that it was easy to fix for all tests if someone needed
to add/remove one.

http://codereview.chromium.org/149619/diff/1001/1006
File chrome/browser/profile.cc (right):

http://codereview.chromium.org/149619/diff/1001/1006#newcode573
Line 573: if (command_line->HasSwitch(switches::kLoadExtension)) {
By moving the load into here, this means you can't invoke chrome.exe with
--load-extension after chrome has already been launched.  Definitely a minor
edge case, but just wanted to make sure it was a conscious decision.

[Aaron Boodman, 2009-07-14 20:35:44]

http://codereview.chromium.org/149619/diff/1001/1003
File chrome/browser/extensions/extension_startup_unittest.cc (right):

http://codereview.chromium.org/149619/diff/1001/1003#newcode99
Line 99: void WaitForServicesToStart(int num_expected_extensions,
On 2009/07/14 20:22:38, Erik Kay wrote:
> seems like it would be useful to have a num_expected_user_scripts as well

It would be good. We can't do this easily now because UserScriptMaster doesn't
know how many user scripts there are. They are serialized to a big blob of
memory on the file thread.

http://codereview.chromium.org/149619/diff/1001/1003#newcode174
Line 174: WaitForServicesToStart(3, true);
On 2009/07/14 20:22:38, Erik Kay wrote:
> we've got multiple tests that depend on the number of extensions in
> extensions/good/Extensions. it would be good if this were a constant that was
> pulled out somewhere so that it was easy to fix for all tests if someone
needed
> to add/remove one.

There are two places that I see: ExtensionsServiceUnitTest and here. It doesn't
seem worth using a shared constant since the tests will fail (we'll still catch
the problem).

http://codereview.chromium.org/149619/diff/1001/1006
File chrome/browser/profile.cc (right):

http://codereview.chromium.org/149619/diff/1001/1006#newcode573
Line 573: if (command_line->HasSwitch(switches::kLoadExtension)) {
On 2009/07/14 20:22:38, Erik Kay wrote:
> By moving the load into here, this means you can't invoke chrome.exe with
> --load-extension after chrome has already been launched.  Definitely a minor
> edge case, but just wanted to make sure it was a conscious decision.

Hmm. No, not intentional. I moved the code here so that it could be tested.
InProcessBrowserTest was not triggering it in the old location. I guess it seems
like an ok tradeoff?

[Erik does not do reviews, 2009-07-14 20:46:39]

Also, could you answer my previous Q about the greasemonkey API tests?

http://codereview.chromium.org/149619/diff/1001/1006
File chrome/browser/profile.cc (right):

http://codereview.chromium.org/149619/diff/1001/1006#newcode573
Line 573: if (command_line->HasSwitch(switches::kLoadExtension)) {
On 2009/07/14 20:35:44, Aaron Boodman wrote:
> On 2009/07/14 20:22:38, Erik Kay wrote:
> > By moving the load into here, this means you can't invoke chrome.exe with
> > --load-extension after chrome has already been launched.  Definitely a minor
> > edge case, but just wanted to make sure it was a conscious decision.
> 
> Hmm. No, not intentional. I moved the code here so that it could be tested.
> InProcessBrowserTest was not triggering it in the old location. I guess it
seems
> like an ok tradeoff?

Yep.  I think it's fine like this.

[Erik does not do reviews, 2009-07-14 21:12:21]

thanks

[Gordjelin, 2010-05-09 18:40:00]

So WHY the GM_setValue and GM_getValue where removed?