I am having (relatively new) issues with venkman not loading scripts outside the components/ directory in lightning; some are hosted in js/. The scripts are properly executed and listed (lightning works etc), but clicking them in venkman raises errors like: Error loading URL <file:/Users/dbo/profiles/thunderbird/mst/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calItemModule.js -> file:///Users/dbo/profiles/thunderbird/mst/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calAttendee.js>: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.asyncOpen]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://venkman/content/venkman-url-loader.js :: loadURLAsync :: line 79" data: no]. It seems this is related to bug 418356, and bug 418356 comment #67 suggested I should file a bug on venkman for that. I can reproduce it with lightning 0.8, thus can exclude a recent change in lightning has caused it.

Leave me a note if I can in any way help on this bug, because it's really hindering my works on lightning.

For reference: Debugging lightning 0.9pre on Thunderbird 2.0.0.14 works while Thunderbird 2.0.0.16 doesn't.

- does also happen on Thunderbird 1.9.1 builds (Shredder etc) - not related to Mac only (at least Linux shows this, too) Can we please get more traction on this bug?

(In reply to comment #3) > - does also happen on Thunderbird 1.9.1 builds (Shredder etc) > - not related to Mac only (at least Linux shows this, too) > > Can we please get more traction on this bug? Unfortunately, I was away for several months (July/August), and somehow missed this bug when going through bugmail. Additionally, I'm currently moving from .nl to London, UK, so I'm just a little bit busy. It should be easier in a week or two. I don't know anyone else still actively working on Venkman except perhaps Alex Vincent, WeirdAl on IRC. Or Karsten Düsterloh (Mnyromyr).

Not sure this is related to venkman directly, from debugging venkman a bit it seems even the debugger service provides the URL with "->" in it to venkman. I guess an ugly hack would be to fix venkman to filter out the correct url if it contains a " -> ". I don't know if its required by something else that jsds returns the url like that, but otherwise the fix is obviously there. I also notice this type of url when there are error console messages coming from a such file.

Caused by the patch for bug 418356.

In case the ugly hack is the way to go, from shallow testing this patch seems to fix it.

Hrm. I'm not sure this is the right patch. The URL of course gets used in many other places. I haven't investigated if those places should use the url as such (as some kind of identifier?) or if it would be OK to change the URL, say, in the constructor? The latter would ideally be the best hack we can pull, I think. What does ChromeBug do? (CC-ing JJB)

Actually, the same point should probably have a hackaround for bug 358286...

I'm not sure what the issue is here, but both this bug and bug 358286 involve file: URLs. The following comment in Firebug from Joe Hewitt might be helpful, // For some reason, JSD reports file URLs like "file:/" instead of "file:///", so they // don't match up with the URLs we get back from the DOM

Sorry for not finding this bug (instead of filing Bug 509210), and thanks for your workaround, Philipp!

I'd like to get this fixed, or at least hacked. I've had this patch applied for quite some time now, and I honestly don't know how apps that chromebug doesn't support yet manage debugging. This patch takes care by fixing up the url in the url-loader, which is probably the one and only interface such urls will pass through.

Comment on attachment 454915 [details] [diff] [review] Fix - v2 Seeing as nobody seems to be implementing a better way to deal with this, r=me.

Pushed to venkman <http://hg.mozilla.org/venkman/rev/007abfa3da81> -> FIXED