midori becomes inresponsive when cookie bar pops up whilewhile the toolbar editor is open

[kardan]

SITUATION
* the cookie security manager plugin is enabled
* the toolbar editor is opened
* the cookie bar appears to offer sweeties, but none of the four buttons is clickable (active, but gives no feedback)
* the close button of the toolbar window is clickable but has no effect
* no keystroke (CTRL+w, CTRL+SHIFT+q, ALT+F4) works
EXPECTED BEHAVIOUR
* any of the offered buttons should work
* CTRL+w should close the toolbar dialogue
STEPS TO REPRODUCE
* activate cookie security manager plugin
* start loading a web page that requires a cookie
* open the toolbar editor (rightclick toolbar)
* wait for the cookie bar to appear

about:version

Version numbers in brackets show the version used at runtime.
Command line /usr/bin/midori
Midori 0.5.2~r6166 ((null))
GTK+ 2.24.10 (2.24.10) Glib 2.32.4 (2.32.4)
WebKitGTK+ 1.8.1 (1.8.1) libSoup 2.38.1
cairo 1.12.2 (1.12.2) libnotify 0.7.5
gcr No granite No
single instance libunique 1.1.6
Platform X11; Linux i686
Identification Mozilla/5.0 (X11; Linux) AppleWebKit/535.22 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/535.22 Midori/0.5
Video Formats H264 [x]   Ogg Theora [x]   WebM [x]

Netscape Plugins:
Shockwave Flash Shockwave Flash 10.1 r999.
Gnash 0.8.11dev, the GNU SWF Player. Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
Gnash comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of Gnash under the terms of the GNU General Public License. For more information about Gnash, see http://www.gnu.org/software/gnash.
Compatible Shockwave Flash 10.1 r999.

[Stephan Haller (nomad-p)]

The problem for me to reproduce this problem that way is that I do have an URL handy which tries to set a cookie later after the page has been loaded. All sites I remember are too quick in setting a cookie that I have no time to open the toolbar editor before the infobar becomes visible.

Could you provide an url for reproduction?

[Stephan Haller (nomad-p)]

Ok, I found a way to reproduce the problem. I created a simple PHP script at http://froevel.de/~<email address hidden>/cookiedelay.php for reproduction. It is a serious problem as a cookie might be set (by AJAX request) even minutes after the page was loaded initially. In the meantime you might open a modal dialog.

The problem now is that there two concurrent modal main loops - easily said. To be honest - I don't know how to solve this problem. Does someone know a proper way to determine if a MidoriBrowser instance or GtkWindow instance has a window which is transient for our instance and knows a way how to wait for our MidoriBrowser/GtkWindow get the only top-level window in an asynchronous way?

Currently I have the idea to create a while-loop which waits for the MidoriBrowser (where we will create the infobar at) to get the active one. The disadvantage is that it will we CPU intensive (100% cpu load). The advantage should be that it should enter our modal main loop only if it got the active window - that should only happen if the modal window like toolbar editor was closed. I have no idea to make it asynchronously to be nice to CPU.

[kardan (kardan+)]

Am Tue, 28 May 2013 20:05:32 -0000
schrieb Stephan Haller <email address hidden>:

> Currently I have the idea to create a while-loop which waits for the
> MidoriBrowser (where we will create the infobar at) to get the active
> one. The disadvantage is that it will we CPU intensive (100% cpu
> load). The advantage should be that it should enter our modal main
> loop only if it got the active window - that should only happen if
> the modal window like toolbar editor was closed. I have no idea to
> make it asynchronously to be nice to CPU.

The most simple implementation that came to my mind is to
* check if any dialog is open before the cookie bar is shown
* wait until it is closed (sleeping with 1s interval)
* show our question afterwards

I cannot reproduce it for the preferences window. Can you check what
is the difference to the toolbar dialogue?

All the best,
kardan

[Stephan Haller (nomad-p)]

I tried to implement such a while-loop even if it is CPU intensive but without success. As soon as I block the current thread with a while-loop the toolbar editor dialog gets unresponsive. I even tried to run g_main_context_iteration of the current active GMainContext to keep the event dispatcher running (I hope it is the right way to do - no idea) but the result was the same.

The difference of the toolbar dialog might be that it creates a GtkDialog and runs gtk_dialog_run which sets the GtkDialog modal, starts its own main loop and waits for this main loop to be quitted like I do in CookieSecurityManager. As far as I understood Glib and GTK+, the problem is that GtkDialog has higher priority to input events as it modal and waits for its GMainLoop to quit. But in the meantime the cookie infobar GMainLoop is created and started and has higher priority because it was the latest one started but it will never be quitted as it will no get any event because GtkDialog is being modal. It's a dead end.

It is not the solution I want but making the toolbar editor window not modal would be the easiest one. I could also imagine that making GtkDialog modal but calling gtk_dialog_run() could help. The preferences window of Midori or my extension did not block but are modal. That means you have to close these windows before you can click the info bar but they do not block or make Midori unresponsive.

[kardan (kardan+)]

> The preferences window of Midori or my extension did not block but
> are modal. That means you have to close these windows before you can
> click the info bar but they do not block or make Midori unresponsive.
I think this sounds like a clean solution. Do you think this is hard to
apply for the toolbar dialogue?

[Stephan Haller (nomad-p)]

I already looked at the code of the toolbar editor extension. I try to provide a patch soon as it looks not to be that hard.

[Stephan Haller (nomad-p)]

Attached is the patch to keep the toolbar editor window modal but not running its own modal GMainLoop.

Sorry, this patch is only against 0.4.8 but I believe the code hasn't changed. Please review!

[kardan (kardan+)]

Am Sat, 01 Jun 2013 11:12:22 -0000
schrieb Stephan Haller <email address hidden>:

> Attached is the patch to keep the toolbar editor window modal but not
> running its own modal GMainLoop.
>
> Sorry, this patch is only against 0.4.8 but I believe the code hasn't
> changed. Please review!
>
> ** Patch added: "Patch against 0.4.8 to fix aggressive modal toolbar
> editor window"
> https://bugs.launchpad.net/midori/+bug/1182603/+attachment/3691837/+files/midori-0.4.8-toolbar-modal-window-fix.patch
>

works very well for r6166. Thanks!

[Cody Garver (codygarver)]

Please submit your code in the form of a bzr launchpad merge request: http://wiki.xfce.org/midori/contribute

[Stephan Haller (nomad-p)]

Merge request created

[kardan (kardan+)]

Am Tue, 11 Jun 2013 20:05:02 -0000
schrieb Christian Dywan <email address hidden>:

> ** Changed in: midori
> Importance: Undecided => Medium
>
> ** Changed in: midori
> Status: New => Confirmed
>
> ** Changed in: midori
> Importance: Medium => High
>

Please check if this is the same bug. It heavily looks like.

SITUATION
An file upload was open together with the cookiebar and spinner
rotated endlessly. See the attached screenshot. I gdb attached the
process and killed it as no information could be seen there.

BTW: after relead a SIGSEGV happened (#1190283)

Thanks,
Kardan

[Stephan Haller (nomad-p)]

Hi Kardan,

I agree it really looks like the same problem but I cannot reproduce the same behaviour. I entered the URL http://validator.w3.org/#validate-by-upload as seen in the screenshot. As soon as the page was loaded the cookie infobar appeared. I navigated to "validate by file upload" and hit the "Choose file..." button. The file chooser appeared, I chose my file and everything worked as expected. But yes, the spinner keeps spinning as long as the cookie infobar is displayed and it was already display in this simple test. Did you do anything else?

Greetings,
Stephan

[kardan (kardan+)]

Am Wed, 12 Jun 2013 17:50:23 -0000
schrieb Stephan Haller <email address hidden>:

> But yes, the spinner keeps
> spinning as long as the cookie infobar is displayed and it was already
> display in this simple test. Did you do anything else?
>
> Greetings,
> Stephan

No, i can not remember a particular action. Sorry.
Actually the problem is with the file upload dialog as it should be
closed when the file has been picked, isn't it?

All the best,
kardan

[Stephan Haller (nomad-p)]

> Actually the problem is with the file upload dialog as it should be
> closed when the file has been picked, isn't it?

Yes, it should and it did as I tested it. I even could upload the file but got an error message of the validator because I choose an invalid file ;) But it worked for me.

[kardan (kardan+)]

This is not directly related to the bug, but belongs to the plugin:

As long as the cookie bar is shown, at least the quit (ctrl+shift+q)
shortcut is not executed. I did not check, if this is true for others
as well.
When I click on any button the, the browser quits as expected before.

Kardan