Midori: Webkit Web browser

Download dialog doesn't render

Reported by ManDay on 2011-05-09
132
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Midori
High
Unassigned
libsoup
Fix Released
Medium

Bug Description

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) wrote :
ManDay (manday) wrote :

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

Michael Moroni (airon90) on 2011-05-13
tags: added: download
v_2e (v-2e) on 2011-07-12
Changed in midori:
status: New → Confirmed
anubis2591 (anubis2591) wrote :

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.

André Stösel (ivaldi) on 2011-09-09
Changed in midori:
importance: Undecided → High
Peter Weber (peter-weber) wrote :

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

André Stösel (ivaldi) wrote :

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

Changed in midori:
assignee: nobody → André Stösel (ivaldi)
André Stösel (ivaldi) wrote :

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) wrote :

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) wrote :

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) wrote :

so you confirmed my guess about libsoup being the problem

Changed in midori:
status: Confirmed → Invalid
gue5t gue5t (gue5t) wrote :

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.

Changed in midori:
status: Invalid → Confirmed
tags: added: downloads
removed: download
Changed in libsoup:
importance: Unknown → Medium
status: Unknown → New
Changed in libsoup:
importance: Medium → Unknown
status: New → Unknown
Changed in libsoup:
importance: Unknown → Medium
status: Unknown → New
André Stösel (ivaldi) wrote :
Changed in libsoup:
status: New → Fix Released
gue5t gue5t (gue5t) wrote :

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?

Christian Dywan (kalikiana) wrote :

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) wrote :

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) wrote :

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

gue5t gue5t (gue5t) wrote :

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.

André Stösel (ivaldi) on 2012-04-24
Changed in midori:
assignee: André Stösel (ivaldi) → gue5t gue5t (gue5t)
JohnDoe_71Rus (johndoe99) wrote :

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) wrote :

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) wrote :

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".

Christian Dywan (kalikiana) wrote :

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.

Changed in midori:
status: Confirmed → Fix Committed
Michael (uskovm) wrote :

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

Christian Dywan (kalikiana) wrote :

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

Changed in midori:
status: Fix Committed → In Progress
Christian Dywan (kalikiana) wrote :

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) wrote :

Updates solve the problem.

JohnDoe_71Rus (johndoe99) wrote :

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

Christian Dywan (kalikiana) wrote :

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

Changed in midori:
status: In Progress → Confirmed
assignee: gue5t gue5t (gue5t) → nobody
Changed in midori:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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