[Chromium API] Disambiguous allowJavaScript from didFailToExecuteJavaScript
Created attachment 49141 [details] Patch
You might want to comment more (perhaps in comments on the function declarations?) on why a piece of code would care whether it can execute script if it doesn't actually intend to execute script. There are other possible APIs here whose usefulness probably depends on the answer. (I'm mostly worried about future code calling allowJavaScript() without calling didFailToExecuteJavaScript() when it should. Perhaps we should create a single access point you call when you want to run script that checks if it's legal and calls this callback if not, or something.)
Comment on attachment 49141 [details] Patch This patch is wrong because V8 cheatzors.
Created attachment 49146 [details] Patch
Done and done. This patch got a bit bigger and probably harder to merge, but I think you're right that we should force clients to be explicit about this bit so we do the right thing in the future.
Comment on attachment 49146 [details] Patch > +enum ReasonForCallingCanExecuteScripts { > + AboutToExecuteScript, > + NotAboutToExecuteScript > +}; I wonder if there could be a better name for the second choice... "NotPlanningToExecuteScript"? "JustCuriousAboutCurrentSetting"? I dunno :(. In any case it seems like rationale for this enum should be given in comments above it.
Comment on attachment 49146 [details] Patch > + [Chromium API] Disambiguate allowJavaScript from didFailToExecuteJavaScript As discussed elsewhere, I'd still much prefer a name for didFailToExecuteJavaScript that better indicates failure due to a policy decision as opposed to other problems such as a syntax error. How about renaming this method to didNotAllowScript? That nicely corresponds with allowScript.
Created attachment 49435 [details] patch v3 Renamed didFailToExecuteJavaScript() to didNotAllowScript(). Updated patch to apply against current tree.
Created attachment 49440 [details] patch v4 Last patch didn't fix everywhere because I didn't realize the first patch used two different function names (for no good reason)
Landed in r55207.