Inkscape fails to open file from the web (via URL) on the command line (regression)

[su_v]

Steps to reproduce:

1) open a terminal window
2) launch Inkscape with the URL as argument, e.g.
$ inkscape http://www.w3.org/Graphics/SVG/svglogo.svg

Expected result:
A copy of the file opens in Inkscape.

Actual result:
Inkscape fails to open the file, with this message on the console:

** (inkscape-11300:50136): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

Reproduced with Inkscape 0.48.x r9901 and Inkscape 0.48+devel r11533
on Mac OS X 10.5.8 (32bit, glib 2.28.8) and OS X 10.7.4 (64bit, glib 2.32.3).

Testing with archived builds indicates that a change between r11297 and r11300 caused this regression:
Likely one of the two commits for Bug #695120 “cannot open relative paths using script extensions from command line”:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11299>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11300>

[Patrick Monnerat (patrick-monnerat)]

The attached patch (for trunk) checks if the filename has the form of an URI and suppresses relative path processing if so.
It can be easily be backported to 0.48.

[su_v (suv-lp)]

@Patrick - many thanks for the quick fix!

Initial tests with Inkscape 0.48+devel r11540+inkscape-0.49-urifix.patch (64bit debug build) on OS X 10.7.4 look ok.

@JazzyNico - any chance you could test with the Windows port for any negative side effects?

[ScislaC (scislac)]

I'm also confirming the patch works.

[Kris (kris-degussem)]

Still a crash on windows vista (second option also crashes, but through the exe, the console messages are not catched).

inkscape.com http://wiki.inkscape.org/wiki/images/6_Powerstroke.svg

** (inkscape.exe:2128): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(
const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FIL
E_TEST_EXISTS )' failed
RegistryTool: Could not set the value 'E:\Inkscapecode\inkscape\inkscape\inkscap
e.exe'

inkscape.exe http://wiki.inkscape.org/wiki/images/6_Powerstroke.svg

[Patrick Monnerat (patrick-monnerat)]

@Kris: I'm afraid I cannot help very much here, since I don't have a W$ dev/debug environment.
By looking at the patched code, the only way I can see for a failure to occur would be calling Inkscape::Extension::open() with a uri/filename expressed in a type not matching gchar *. Something like a real parameter being a wchar_t pointer while gchar is 8-bit. I don't know if that kind of figure is supposed to work.
I think someone with a windows debugger should look at it to have more details.
BTW: failing on Linux does not cause a crash: it simply fails to open the target file and displays an empty workspace. Do you really experiment a crash ?
Also the RegistryTool error does not seem related (in fact, despite the listing order, it probably occurs before the assertion failure).

[Kris (kris-degussem)]

Oops ... "crash" in comment 4 should be read as "failure to read from a web url".

Thanks for noticing ;-)

[su_v (suv-lp)]

@Kris - not sure that feature worked on Windows before: could you test with stable (0.48), or trunk <= r11297?

[Alvin Penner (apenner)]

the RegistryTool warning can be avoided if you open a DOS window as an administrator

[Alvin Penner (apenner)]

not entirely sure if this is relevant or not, but On Wondows 7 (32 bit) and Inkscape 0.48.3.1, I get the following error message (and the requested file does not load):

C:\Program Files\Inkscape>inkscape.com http://wiki.inkscape.org/wiki/images/6_Powerstroke.svg

** (inkscape.exe:3488): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

[jazzynico (jazzynico)]

Tested on Windows XP, Inkscape 0.48, 0.47, 0.46 and 0.45.1, and all fail with the same error message.

[su_v (suv-lp)]

@JazzyNico, Alvin, Kris - thanks for testing: based on your feedback, this regression does not seem to affect Windows builds (as the feature apparently is not supported at all).

Assuming that the patch doesn't introduce negative side-effects for Windows builds either, it seems save to commit 'inkscape-0.49-urifix.patch '?

[jazzynico (jazzynico)]

More tests on Windows. The URI used in SPDocument::createNewDoc contains the Inkscape install path before the correct URI (D:\Inkscape\inkscape-11550\http://wiki.inkscape.org/wiki/images/6_Powerstroke.svg when launched from my test directory).

[jazzynico (jazzynico)]

With the patch from comment #1 the path is no longer considered relative and the URI passed to createNewDoc is correctly formated. But on Windows, it still fails.
Investigating Inkscape::IO::file_test.

[Patrick Monnerat (patrick-monnerat)]

> With the patch from comment #1 the path is no longer considered relative and the URI passed to createNewDoc is correctly formated. But on Windows, it still fails.
This is the reason for my "character size" statement in comment #5: Before fix of bug #695120, the Inkscape::Extension::open() procedure used the filename pointer as an opaque pointer, although declared as gchar *. This is not the case anymore after fix for 695120 and the current patch.
As a consequence, code prior bug #695120 fix may have worked for non 8-bit characters in filename, providing the procedures called by Inkscape::Extension::open() (directly or indirectly) that really deal with the filename properly take care of the effective filename character type. I'can't check that: they are to many nested procedures called and as I said, I have no W$ to check it.
If this is the problem, this could explain the current behavior: since Inkscape::Extension::open() only deals with 8-bit characters (gchar), any non-null 16-bit LE character string is understood as a single 8-bit character string, thus the URI form detection cannot be successful.
The first thing I would check (if I could!) would be the real form of the filename upon procedure entry, to confirm or infirm this is the problem. Maybe someone with a W$ debugger can do it ?
Anyway, the real original problem (the one that required relative path processing) is the chdir() for extensions execution. The best fix would probably be to get rid of chdir(), but from the comments I've seen about long pathes on W$, I don't think it's realistic :-(

[su_v (suv-lp)]

IMHO the issue that the Windows port does not support opening URLs (URIs (?)) dirrectly from the command line should be tracked in a separate report (as feature request).

This one was filed about a regression in default linux/osx builds, introduced by a recent commit, and is fixed by the provided patch. AFAICT from the comments about tests on Windows, the proposed patch does not have a negative _side effect_ for the Windows port (which was my original question): the feature didn't work before on Windows, nor does it work with the patch, nor does the patch seem to break opening local files from the command line on Windows.

[jazzynico (jazzynico)]

PM> As a consequence, code prior bug #695120 fix may have worked for non 8-bit characters in filename,

AFAICT, it didn't work before (tested from 0.45.1 to now).

PM> providing the procedures called by Inkscape::Extension::open() (directly or indirectly) that really deal with the filename properly take care of the effective filename character type

Inkscape fails when calling Inkscape::IO::file_test (in src/io/sys.cpp:181). g_file_test always return false when the filename is an URI (tested with http:// and file:// schemes). Note that the filename is first tested and (if necessary) converted to utf8.
Thus I second ~suv. It looks like g_file_test() (and probably other g_file_* functions) doesn't support URIs on Windows. Unfortunately, I haven't found any relevant documentation on that potential issue.

~suv> the proposed patch does not have a negative _side effect_ for the Windows port

Yes. I suggest we commit the patch and open a new report to deal with the Windows issue.

[jazzynico (jazzynico)]

Testing on Ubuntu 11.04 just showed me that the trunk patched version, as well as 0.48.1 (packaged) and the branch (0.48.4) patch version all fail with the following message:

(inkscape:12819): libgnomevfs-CRITICAL **: gnome_vfs_uri_is_local: assertion `uri != NULL' failed
** (inkscape:12819): WARNING **: URI non valide
** (inkscape:12819): WARNING **: Error: Could not open file 'http://www.w3.org/Graphics/SVG/svglogo.svg' with VFS

Could someone with any GNU/Linux distro confirm?

[Patrick Monnerat (patrick-monnerat)]

the command 'inkscape http://www.w3.org/Graphics/SVG/svglogo.svg' works here properly with a patched 0.48.1 on Fedora 14 x86_64: the inkscape windows open and show the SVG.
However, there is a Gtk warning sent to the console telling file:///...../http://www.w3.orig/Graphics/SVG/svglogo.svg cannot be found. This wrong path is NOT resulting from the patched Inkscape::Extension::open() procedure since the relative-->absolute transformation in it is never executed.

[su_v (suv-lp)]

> Could someone with any GNU/Linux distro confirm?

See comment #3 - ScislaC is on Ubuntu (12.10 Quantal IIRC).

[jazzynico (jazzynico)]

Looks good on Debian testing. Must be something on my (quite) old Ubuntu.

[jazzynico (jazzynico)]

Fix committed in the trunk (revision 11556) and branch (revision 9903).
Thanks for the patch, Patrick.

[su_v (suv-lp)]

<off-topic>
> However, there is a Gtk warning sent to the console telling
> file:///...../http://www.w3.orig/Graphics/SVG/svglogo.svg cannot be
> found.

AFAIK that's a glitch in older versions of GTK+ 2.24: I get the same message with current trunk (r11556) on Mac OS X 10.5.8 with GTK+ 2.24.8, not only when opening a file from the web via cli, but whenever a new file is saved and subsequently added to the 'recently opened' file list (IIRC it's a upstream issue in GtkRecentManager which was addressed in 2.24.9 or 2.24.10 [1]).

[1] possibly related to <https://bugzilla.gnome.org/show_bug.cgi?id=662814>
</off-topic>

[John Paul Adrian Glaubitz (glaubitz)]

There is an easy way to fix this issue:

1. Revert the patch from https://bugs.launchpad.net/inkscape/+bug/695120
2. Apply the patch from https://bugs.launchpad.net/inkscape/+bug/911146

The patch from https://bugs.launchpad.net/inkscape/+bug/911146 has been applied to Inkscape 0.48.3.1-1.3 in Debian unstable (and testing) and opening SVG files via URL from the command line works without problems with the version in Debian which uses the attached patch.

Cheers,

Adrian

[John Paul Adrian Glaubitz (glaubitz)]

Plus, the suggested patch by Patrick is very ugly as it has to test every single character and it is very difficult to read and understand.

If you drop the patches by Patrick (https://bugs.launchpad.net/inkscape/+bug/1022719/+attachment/3219645/+files/inkscape-0.49-urifix.patch) and (the one by https://bugs.launchpad.net/inkscape/+bug/695120/+attachment/2180360/+files/inkscape-0.48.1-abs4chdir.patch), then apply the one by Michael Karcher, you will dramatically improve the readability of the the code and solve both Bug #695120 and #1022719. Plus, you are actually using C++ code instead of C which is kinda more fitting in a C++ source.

Cheers,

Adrian

[Liam P. White (liampwhite)]

This doesn't seem to be working with trunk r13508

$ trunk/install/bin/inkscape http://www.w3.org/Graphics/SVG/svglogo.svg

** (inkscape:17007): WARNING **: Can't open file: http://www.w3.org/Graphics/SVG/svglogo.svg (doesn't exist)

[su_v (suv-lp)]

On 2014-08-12 20:09 , Liam P. White wrote:
> This doesn't seem to be working with trunk r13508

Not confirmed with trunk build (r13508, on OS X 10.7.5) with gnome-vfs installed and detected at build time (URL opens just fine).