6

I've attempted to make some modifications to a userscript to enable it to work under Chrome, but when I drag it into Chrome's window in order to install it, a dialog pops up and says 'Invalid Script Header'.

I've tried to use the Developer Tools, and built-in Javascript Console, to debug any errors occurring, but nothing appears to list any information.

Console.app does not list anything meaningful, except for the same error message I already know.

[0x0-0x2d02d].com.google.Chrome: [346:1547:16686819618022:ERROR:extension_error_reporter.cc(55)] Extension error: Invalid script header.

How can I reasonably debug this error message and figure out what about the header is incorrect?

I'm using Chrome 15.0.861.0 on the dev channel, under OS 10.7 Lion.

VxJasonxV
  • 951
  • 11
  • 35
  • 1
    I don't *think* there are any tools for this. If you post the actual code here, someone may be able to spot the error. Otherwise, you'd do it the old fashioned way: take a good script and the bad script and compare and half-split differences until the problem is determined. – Brock Adams Aug 28 '11 at 09:09
  • post the code at http://gist.github.com/ please – erikvold Aug 29 '11 at 15:32

3 Answers3

6

I finally stumbled across the answer to this question, amusingly via a Chromium Bug Report.

As it turns out, the answer to my question was in the (significantly brief) Userscript Documentation for Chrome page.

With Greasemonkey-style @include rules, it is not possible for Chrome to know for certain the domains a script will run on (because google.* can also run on google.evil.com). Because of this, Chrome just tells users that these scripts will run on all domains, which is sometimes scarier than necessary. With @match, Chrome will tell users the correct set of domains a user script will run on.

As it turns out, I had been using @match http://*musicbrainz.org in an attempt to match www.musicbrainz.org as well as musicbrainz.org, but per the quoted text, that doesn't save you from accidentally matching evilmusicbrainz.org. So, my solution was to use two lines:

@match http://*.musicbrainz.org
@match http://musicbrainz.org
VxJasonxV
  • 951
  • 11
  • 35
  • 1
    This would explain the script running on extra pages, it does not explain the error message. – Brock Adams Aug 29 '11 at 23:57
  • Chrome has very strong use and reuse of "same-origin" requests for security purposes. I could very well use `http://*/*` (and yes, I would have to specify `//*/*`), but if I specify a second level domain, it MUST be clean. You cannot glob in a second level domain. This means the TLD has to be clean too. Basically, you can blog a sub-domain, but if you do so it has to be delimited with a dot before specifying the second-level and TLD. – VxJasonxV Aug 30 '11 at 05:17
  • glob* a sub-domain – VxJasonxV Sep 19 '18 at 22:06
4

Type:

 debugger;

Somewhere in the code, and the Web Inspector will pop up in that location. I have answered similar question here Chrome debugger inject javascript

Community
  • 1
  • 1
Mohamed Mansour
  • 39,445
  • 10
  • 116
  • 90
1

I figured out while I got the same error message ( INVALID SCRIPT HEADER ) that it accoured cause of a typo between the // ==UserScript== Header info.

wronge line

// @run-at document.end

corrected line

// @run-at document-end
d3n1c1d3
  • 11
  • 1