"[...] working, please wait..." windows invoked by Help are blocking, and can not be closed

[Helmut Walle]

Platform configuration:

- openSUSE 11.1
- inkscape-0.47pre3 (built from tarball)
- Firefox 3.0.14

Description:

When invoking one of the items from the Help menu that automatically connect to the Internet, a new tab is opened in the web browser (Firefox) with the respective content. However, the Inkscape window with title "<2>", and content "'Keys and Mouse Reference' working, please wait..." remains there indefinitely. This blocks using Inkscape. Clicking the Cancel button in window <2> does not close this window either. Closing the tab with the help content in Firefox does not help to get rid of window <2> either. The only thing that "helps" is killing Inkscape.

The other items on the Help menu that automatically open a browser tab show the same behaviour.

Steps to reproduce:

1. Open Firefox, open a few tabs there, whatever URLs.
2. Run Inkscape
3. Select from menu: Help -> Keys and Mouse Reference

Suggestion:

It is a bit annoying that some of the Help menu items are connecting to the Internet in the first place, because not everyone is on a fast connection all the time, and waiting for more than a moment just to get a key or mouse reference is not what it should be. It would make sense to include a copy of documentation like this with the build, and make the Help action default to using the local copy. Connecting to the Internet on certain Help items could be made configurable via the Preferences (which would obviously increase complexity).

As a minimum fix, the "working, please wait..." window should be made non-blocking, so that even with a slow or broken connection, it would be possible to continue working. Also, hitting the Cancel button on that window should close it, which it does not appear to do currently.

[su_v (suv-lp)]

Not reproduced with Inkscape 0.46+devel r22457 on OS X 10.5.8, Python 2.6.2 and Inkscape 3.5.3

The webbrowser is called by the python extension 'launch_webbrowser.py' which was added in revision 18270. It defines
  class VisitWebSiteWithoutLockingInkscape(threading.Thread):
which seems intentionally named to indicate the known issue is taken care of... wonder why that fails on certain linux distributions?
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/launch_webbrowser.py?view=markup>

Which python version do you have installed? The script 'launch_webbrowser.py' additionally uses the modules 'webbrowser' and 'threading' (part of the standard python library).

related bugs:
Bug #168226 “Launching Firefox freezes inkscape until browser exits” (ubuntu)
Bug #306867 “when Help menu item opens in browser, inkscape dialog stuck until browser quits” (ubuntu)
Bug #428181 “Display garbled in BASIC TUTORIAL” (ubuntu)

[Helmut Walle (hwalle)]

Python versions here: I had python-2.6.0-2.21.1 (rpm from SUSE 11.1) when I noticed the problem, and I have now upgraded to
python-2.6.2-19.1 (and have taken the other python packages up to match that version as well). The problem persists.

I have then reverted to inkscape-0.46-62.36 and found that it suffers from the same problem.

[Helmut Walle (hwalle)]

One more attempt: upgrading to Firefox 3.5.3 has not resolved the issue either. It still persists, both on inkscape 0.46 and 0.47pre3.

One more detail I noticed: when clicking the Cancel button on Window "<2>", the button goes dark (as buttons usually do when clicked), and it just remains dark indefinitely. inkscape is still blocked.

[Alex Valavanis (valavanisalex)]

Confirmed with Ubuntu 11.04 32-bit, using inkscape_0.48.1-2ubuntu2.

* Set Firefox as default browser, close any running instances of FF
* Start Inkscape, select Help->Inkscape manual
>> Firefox opens with Inkscape manual as expected
>> Inkscape displays persistent "'Inkscape Manual' working, please wait..." dialog.
>> Inkscape becomes unresponsive
>> Dialog cannot be closed by hitting "Cancel" button
>> Dialog closes, and Inkscape responds when FF is closed.

[Alex Valavanis (valavanisalex)]

I have linked a similar report from Debian. The only difference there is that Konqueror is used as the browser.

I can also confirm the same behaviour in kubuntu 10.10 32-bit, using inkscape_0.48.0-1ubuntu1.2 and rekonq.

[su_v (suv-lp)]

IIRC additional information about the situation on some linux desktops was provided earlier in
Bug #781397 “Help opens web browser (Epiphany, Konqueror), Inkscape stays in modal state .”

[Alex Valavanis (valavanisalex)]

Oops - I forgot that this had already made it onto launchpad. I think it's pretty safe to mark this as a duplicate of bug #781397... there's more information in that report