Download dialog doesn't render

[ManDay]

On some downloads, the download dialog which normally has buttons "Save" "Save As" "Open" and "Cancel" pops up but is an empty GTK window with no widgets inside. Pulling the window arround over the screen "wipes" the screen behind with the background color of the winodw (screen attached).

This doesn't happen for all downloads. For certain download it (seems to) happens always, for other never, for again others in some cases. Webkit 1.4.0.

PS: The "buffer wiping" or whatever you would like to call it happens over the complete window of midori (only).

[ManDay (manday)]

PS: Download dialog can still be used by clicking the buttons blind.

[anubis2591 (anubis2591)]

This happens to me on every download from http://www.mediafire.com. I haven't run into this bug on any other sites so far.

[Peter Weber (peter-weber)]

Happens here with PDF, most other file-types work.

[André Stösel (ivaldi)]

i'm pretty sure that the reason for this is that gtk_dialog_run blocks the main loop.

[André Stösel (ivaldi)]

hm,... I misread the description of gtk_dialog_run:
 "Blocks in a recursive main loop until"...
It doesn't block the main loop, just the caller.
However, after webkit_web_view_mime_type_decision_cb is finished, the dialog looks fine.

Any ideas?

[André Stösel (ivaldi)]

Every time the dialog doesn't render, the mime type callback (webkit_web_view_mime_type_decision_cb) is called before the "SoupSocket::readable" signal ends.
So it looks like some kind of locking issue in libsoup.

[pimander (marcofal)]

Hi all,
I'm using gentoo and the same problem appeared upgrading libsoup and libsoup-gnome to 2.34.3, this pulled in glib-networking-2.28.7 as dependence. The last is devoted to networking, probably the bug originates here...
Downgrading to old libsoup-2.32.2 and libsoup-gnome-2.32.2 fixed the problem.

marco

[André Stösel (ivaldi)]

so you confirmed my guess about libsoup being the problem

[gue5t gue5t (gue5t)]

While this bug does have its origin in libsoup, I'm changing it to confirmed so it will show up in launchpad bug searches; users are still running into this a lot and it should help to avoid duplicates. In addition, there still might be something midori can do to work around this, and it's a significant problem still. "Confirmed" might not be the most accurate status but it's not strictly "invalid" either.

[André Stösel (ivaldi)]

FYI - there is a patch upstream: https://bugzilla.gnome.org/attachment.cgi?id=212002

[gue5t gue5t (gue5t)]

Given current understanding of this bug, is it possible (and worthwhile) for us to write a workaround for older glib versions, or is it reasonable to assume that no significant number of users will be running an intersection of library versions that exhibit this bug for much longer?

[Cris Dywan (kalikiana)]

One thing we could do, is have a blog post about it, aimed at package maintainers to get the fix in libsoup out there asap.

[gue5t gue5t (gue5t)]

This patch works around the bug in the affected versions of the libraries. glib 2.33.1 is the first version that contains the patch on the glib end (<http://git.gnome.org/browse/glib/commit/?id=a49568ceccb133c5a99524f3fdb842f0c05eb0b3>), and libsoup 2.33.4 was the first libsoup version after the soup commit (<http://git.gnome.org/browse/libsoup/commit/?id=97bacf3057b7c45c29a6d025c67a6dd588144e05>) that triggered the glib bug.

[natano (natanoptacek)]

The patch works fine for me on Ubuntu Precise with glib 2.32.1 and libsoup 2.38.1.

[gue5t gue5t (gue5t)]

I've noticed some cases where the patch doesn't work quite properly (causing momentary hangs of its own, and not working with multiple concurrent downloads) which indicate that the simplistic approach it takes isn't quite right. I'll see if I can get it working in all cases soonish; consider the current one a proof-of-concept.

[JohnDoe_71Rus (johndoe99)]

bug present

Description: Ubuntu 12.04 LTS

midori:
  Установлен: 0.4.5+r4803-0~precise1

ibsoup2.4-1:
  Установлен: 2.38.1-1

libsoup-gnome2.4-1:
  Установлен: 2.38.1-1

[gue5t gue5t (gue5t)]

This modification of the patch should work much better--it fixes the lack of rendering when downloading multiple files at once and also shouldn't be upset by GSource id number churn (an implementation detail of the previous version of the patch). User testing is again appreciated.

[gue5t gue5t (gue5t)]

That last patch lacks the wscript modification to check against the relevant libsoup version. *This* patch should be applicable to latest git and work after "./configure && make".

[Cris Dywan (kalikiana)]

I split off the datasource NULL-check and added a midori_ prefix to the functions. If this doesn't cause any problems, this can go in the release in a few hours.

[Michael (uskovm)]

Midori 0.4.5 from Midori PPA. Ubuntu 12.04 LTS. Affects me too.

[Cris Dywan (kalikiana)]

Re-opening and backing out work-around due to remaining crashers for some people. An empty dialog is still somewhat better than a crash.

[Cris Dywan (kalikiana)]

So here's an alternative suggestion to work-around the GLib bug. Modeless dialog. WebKitWebView::download-requested explicitly allows as per documented API that you can asynchronously _start and _cancel. Unfortunately it doesn't work, so I went with blocking all downloads but creating a new one on the fly. There's a case where it's stuck at 0 Bytes and never actually loads - no solution for that yet.

I'm thinking we can go one step further and delay the policy decision itself, hopefully that's more reliable.

[robytrevi (robytrevi)]

Updates solve the problem.

[JohnDoe_71Rus (johndoe99)]

looks like midori_0.4.6+r4924-0~precise1_i386.deb fix bug to me

[Cris Dywan (kalikiana)]

Maybe we should just leave this as it is, now that distributions are indeed updating to get the fix.