What steps will reproduce the problem? 1. Include the uncompressed-svg.js file rather than svg.js 2. Configure the data-path attribute on the script element.

What is the expected output? What do you see instead? I expect it all to work. Instead the system fails to find 'svg.swf' The reason for this is due to http://code.google.com/p/svgweb/source/browse/trunk/src/svg.js#867 Where the code searches for 'svg.js' and not 'svg-uncompressed.js' or 'svg.js' .. perhaps a regular expression /svg(-uncompressed)?.js/ would be a safer test?

What version of the product are you using? On what operating system, browser, and version of Flash? N/A

Please provide any additional information below. Reduced test cases are always appreciated!

Another report of this in Issue 236.

I think the problem is that these routines (getLibraryPath, doDebugging, getHTCFilename) all use this criteria:

if (scripts[i].src.indexOf('svg.js') != -1)

However, the "definitive" getSVGScripts call uses this criteria for our tags:

if (scripts[i].type == 'image/svg+xml')

I think they should all use the type check and will make this change soon unless Brad has a different solution. The routines all look for a specific SVG Web parameter so I think the additional check is mostly unnecessary anyway.

Does this mean any pre-existing script tags we have will need changing to have a type attribute added to them ?

Forget my idea in comment #1. I was confusing embedded svg script tags with svg.js script tag. If we were reading these parameters from the image tags it would make sense.

@grick23: Yeah, they are different SCRIPT tags. I just need to change that indexOf to be something like

f (scripts[i].src.indexOf('svg.js') != -1 || scripts[i].indexOf('svg-uncompressed.js') != -1)

r836 fixes this.

thx :)