Help opens web browser (Epiphany, Konqueror), Inkscape stays in modal state .

Bug #781397 reported by Tomasz Sztejka
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Medium
Unassigned
inkscape (Debian)
Confirmed
Unknown
inkscape (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Debian Linux only + Gnome. Inkscape versions tested: 0.46, 0.47, 0.48

When I do select "Manual", "Keys and mouse reference" and etc. form Help menu Inkscape pops-up a modal dialog:

  "Inkscape manual working... please wait"

and opens web browser with a link to a site containing a manual. However I do find this kind of approach unreasonable ( some people do work off-line you know ) it is not a subject of this bug report.

The problem is, that as long as a web browser is opened this modal dialog do not close and CANNOT be closed neither by cancel or close icon. Any attempt to click "Cancel" leads to Inkscape hanging till browser window is closed. Closing browser window makes Inkscape usable again.

This is rather an inconvenience than a bug but less experienced users may do not figure out how to access manual while working with a program.

Investigation:

In my config (debian+gnome) a default browser is Epiphany. If I do set "System->preferences->preferred applications->Internet->web browser" to "iceweasel" or "links2 in terminal" help works as expected. If I do set it to: "Epiphany" or "Konquerror" bug is exposed and Inkscape awaits for browser to be closed.

If I do however select: "Konqueror in terminal" help works as expected but additional terminal pops-up. This suggests, that script showing help assumes that called process will fork and return immediately. They do not. A simple test with a terminal shows, that "iceweasel" command forks and returns but "konqueror" and "epiphany" do not. "Links2" neither - it's even worse, since when set as a system browser without a terminal it does not pop-up a window but performs display i/o on stdin/stdout and in effect inkscape hangs.

Please detach from a child process when rising a help window by calling an external program.

Info: When I do start Inkscape from a console I can see a stream of:
"(inkscape:3504): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed"
I hope it is intended.

With regards,
 Tomasz Sztejka

su_v (suv-lp)
tags: added: extensions-plugins
removed: browser epiphany gnome hangs help konqueror
Revision history for this message
su_v (suv-lp) wrote :

Which python version do you have installed?

The browser process is spawned from this python script:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/view/head:/share/extensions/launch_webbrowser.py>

Earlier related reports:
Bug #449986 “"[...] working, please wait..." windows invoked by Help are blocking, and can not be closed”
Bug #306867 “when Help menu item opens in browser, inkscape dialog stuck until browser quits”
Bug #168226 “Launching Firefox freezes inkscape until browser exits”

<off-topic>
> "(inkscape:3504): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed"

Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0
</off-topic>

Revision history for this message
Tomasz Sztejka (sztejkat) wrote :
Download full text (6.7 KiB)

(...)Which GTK+ version do you have installed? That's a bug in GTK+ (see bug #576852), fixed in GTK+ >= 2.22.0(...)

2.20.1-2. Unfortunately using Debian stable means I'm a bit back in time. Thanks for information, I will check if it will disappear when I finally will do an upgrade.

(...)Which python version do you have installed?(...)
Python 2.6 is set as a default.

About lauch.... py script.

I'm not a pro with a python. Done few lines only. But from other experiences with other programming languages I do know, that starting a new thread is not enough to get in a background - the process will not terminate until all non-daemon threads are terminated. And if threads are daemon, they will be killed when all non-daemon threads terminates. In this case inkscape fires new process (python interpreter) and awaits for it's completion. So python interpreter must terminate while browser must go to another, independent process.

Also python manual says: "(...)global interpreter lock(...) The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time.(...)" what suggests that doing threads in python when not doing I/O or awaiting for an external process is ridiculous. Again, I'm not a pro with python.

I did modified script to remove threading and it works the same way: iceweasel behaves as typed in terminal - shows and returns. Epiphany exposes incorrect behavior.

The webbrowser.py module used in script is using subprocess.py to spawn subprocess with shell==false. Manual says, that it is reasonable because of safety but will result in os.execvp(). As expected on Unix clone, manual says that os.execvp do not return. However subprocess _execute_child do os.fork() so it is correct and cannot be a source of problem.

But some pieces of webbrowser.py contains dangerous "return not p.wait()". It seems it assumes that some style of calling, named "remote", will fork by itself and others will not. I do not understand WHY such a distinction. Closer look shows, that following classes of browsers defined in this webbrowser.py module will await till child process completes:

GenericBrowser
UnixBrowser (depening on arguments)

Selection of class is made by get() and available set is prepared by register_X_browsers() during module initialization. This method applies distinct assumptions about distinct commands. I do not understand why to wait for some browsers to complete? Does it matter? We are only willing to fire it up and forget, right? I think it is for python code running in terminal. That's the problem with a generic code - it does too much and is too uncertain.

For GNOME default browser is available through "gnome-open" system script. When checked in command line this script is always forking and returning. The webbrowser.py module recognizes it as a BackgroundBrowser what should be ok, as BackgroundBrowser do not wait for subprocess to complete. But it should not matter anyway, since "gnome-open" forks for both iceweasel and epiphany.

Unfortunately I did confirm, modifying launchwebbrowser to:
(...)
from webbrowser import BackgroundBrowser
bb=BackgroundBrowser("gnome-open")
bb.open(url=opt.url)
(...)
th...

Read more...

Revision history for this message
Tomasz Sztejka (sztejkat) wrote :

Note: Alternatively please check, what Inkscape is doing with I/O pipes passed to it's child process. It is beyond my capabilities to look at it. If it is in fact waiting for EOF then change it to wait for process completion regardless of stream state. The current python behavior is not ideal, as background browser is not 100% background, but it is acceptable. So maybe there is a cleaner solution at inkscape team side possible to achive?

Regards,
 Tomasz Sztejka.

su_v (suv-lp)
summary: - Help opens web browser, Inkscape stays in modal state.
+ Help opens web browser (Epiphany, Konqueror), Inkscape stays in modal
+ state .
Changed in inkscape (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Changed in inkscape:
status: New → Confirmed
importance: Undecided → Low
importance: Low → Medium
Changed in inkscape (Debian):
status: Unknown → Confirmed
Revision history for this message
Cojnel (cojnel) wrote :

Except for inkscape freezing,
this sounds very similar to the popup i'm getting.

When clicking on an item in the help menu that opens a webpage,
then two popups open in the center of the inkscape window,
and the webpage opens in the browser.

The first popup says:
'Keys and Mouse Reference' working, please wait...
[Cancel]

the text between the '' signs refers to what was clicked.

The second one says:
Inkscape has received additional data from the
script executed. The script did not return an error,
but this may indicate the results will not be as
expected.

(process:9189): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
[OK]

If the second popup is moved then one can see that the first one is still open behind it.

If one clicks OK on the first popup,
then they both go away, and inkscape works fine.

Tested with:
r12833 on linux mint 15 cinnamon 32bit
Firefox v25.0.1 is the default browser.

Revision history for this message
Hachmann (marenhachmann) wrote :

Getting the same (but longer :) ) error message with Inkscape 0.91pre3 opening firefox for manual/other websites on LM17:

(process:2824): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Error: No running window found
(process:2828): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised
(firefox:2828): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

Revision history for this message
Trent W. Buck (twb) wrote : subscribe

 subscribe

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.