Make it so that allow_js_access: false can be used with background pages created by window.open.

chrome/common/extensions/extension.cc

Index: chrome/common/extensions/extension.cc
diff --git a/chrome/common/extensions/extension.cc b/chrome/common/extensions/extension.cc
index 549566daf80e743e92acbd07db1fcdb1bc31a9c5..b4d4733c14bdda459bee90c58a058149ad444d76 100644
--- a/chrome/common/extensions/extension.cc
+++ b/chrome/common/extensions/extension.cc
@@ -1828,11 +1828,6 @@ bool Extension::LoadBackgroundAllowJSAccess(
     return false;
   }
 
-  if (!has_background_page()) {
-    *error = ASCIIToUTF16(errors::kInvalidBackgroundAllowJsAccessNoPage);

[Charlie Reis, 2012/03/26 17:56:51]

Normally, we expect people to set allow_js_access to false, since it defaults to
true.

However, what if the manifest explicitly sets allow_js_access to true, without
specifying a background page?  Are we ok with the app creating background pages
manually and scripting them?  (Note that they will have process-per-site in that
case.)

If so, do we also allow an empty "background" block (with no mention of page or
allow_js_access) in the manifest to get this behavior?  Or should we keep it an
error for allow_js_access to be true without specifying a background page?

[Mihai Parparita -not on Chrome, 2012/03/27 01:16:07]

Not quite sure I understand this. Being able to create a background page not
tied to the "background" section in the manifest,  but instead to the
"background" permission. Apps today can already create same-process background
pages and script them, and I don't think we can change that.

[Charlie Reis, 2012/03/27 23:19:27]

Here's what I meant.  Suppose the manifest looked like this:
  "permissions": ["background"],
  "background": {
    "allow_js_access": true
  }

That's equivalent to:
  "permissions": ["background"],
  "background": {
  }

I think this used to be illegal syntax, but now we appear to be saying it's ok. 
I just wanted to confirm that it's legal.  (It means we don't create a
background page for the app until it calls window.open for one, but when we do,
it stays in process and can be scripted.  Seems ok to me, but I think it wasn't
a case we supported before.)

[Mihai Parparita -not on Chrome, 2012/03/28 20:29:01]

I'm pretty sure this was legal, and that manifest does load in M18. We never
check for the presence/absence of the background section itself, just keys
within it (kBackgroundPage, kBackgroundScripts, etc.).
This how window.open(..., "background") has worked since it was introduced in
Chrome 10 (same-process, scriptable).

-    return false;
-  }
-
   return true;
 }