issues loading economist.com pages

Bug #979688 reported by Liviu Andronic
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Midori Web Browser
Expired
Undecided
Unassigned

Bug Description

Midori is slow-to-failing when trying to access economist.com pages, even with AdBlock on and with Netscape plugins off. Try [1].
[1] http://www.economist.com/blogs/newsbook/2012/04/syrias-ceasefire

On a good try it will be very slow to start rendering the page (I believe, because of the 'Trending topics' thingy on the right, that strangely appears even if the plugins are off), accompanied by soft and intermittent freezes of the entire Midori interface. Sometimes it takes ages and it still doesn't formally finish downloading the page. On a bad try, it will fail downloading the page, and only after _several_ retries will it deem to download it. I'm not sure what's going on, but disabling scripts makes Midori very snappy when downloading [1].

Another related issue that I seem to have spotted, when one tab never finishes downloading, another one will simply fail to start downloading. Try to load [2] while [1] keeps downloading forever. Then [2] will not start downloading and after some time will duly time out.
[2] http://www.economist.com/blogs/graphicdetail/2012/04/daily-chart-5

===
about:version

Version numbers in brackets show the version used at runtime.

Command line midori
Midori 0.4.4
WebKitGTK+ 1.2.7 (1.2.7)
GTK+ 2.20.1 (2.20.1)
Glib 2.24.1 (2.24.1)
libsoup 2.30.2
cairo 1.8.10 (1.8.10)
libnotify 0.4.5
single instance libunique 1.1.6
Platform X11; Linux x86_64
Identification Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/531+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Midori/0.4
Video Formats H264 [x]   Ogg Theora [x]   WebM [x]
Netscape Plugins:

flashplugin-alternative.so Shockwave Flash
parole-player.so Parole media player plugin-in
npwrapper.nppdf.so Adobe Reader 9.4
libjavaplugin.so IcedTea NPR Web Browser Plugin (using IcedTea6 1.9.13 (6b20-1.9.13-0ubuntu1~10.04.1))
gecko-mediaplayer-wmp.so Windows Media Player Plug-in
gecko-mediaplayer.so mplayerplug-in is now gecko-mediaplayer 1.0.5
gecko-mediaplayer-rm.so RealPlayer 9
gecko-mediaplayer-qt.so QuickTime Plug-in 7.6.9
gecko-mediaplayer-dvx.so DivX Browser Plug-In

Tags: javascript
Revision history for this message
Liviu Andronic (landronimirc) wrote :

The trouble comes from JavaScript. If you have it enabled, you will likely see the issues described above. If you disable JS, then the website loads snappily. I see similar issues on other web pages.

tags: added: javascript
Revision history for this message
Liviu Andronic (landronimirc) wrote :

Now I see such ~10sec loading times even on Wikipedia pages. [1] With JS disabled, the loading is instant.

As mentioned in Bug #1012721 [2], the problem seems to vanish if Midori is started like this:
midori -a http://www.economist.com

Moreover, I do not see the same issues when launching as root. Something is clearly off and makes Midori unsuitable for browsing, but what. How should go about debugging this to pinpoint the cause?

[1] http://en.wikipedia.org/wiki/Mountaintop_removal
[2] https://bugs.launchpad.net/midori/+bug/1012721/comments/5

Revision history for this message
gue5t gue5t (gue5t) wrote :

Perhaps userstyles or userscripts are acting up? Try disabling them if they're enabed.

Revision history for this message
v_2e (v-2e) wrote :

Disabling the userstyles didn't help in my case (as for userscripts, I didn't use them at all).

Revision history for this message
Liviu Andronic (landronimirc) wrote : Re: [Bug 979688] Re: issues loading economist.com pages

Although now I'm using them, userstyles and userscripts, I had none
enabled or in use when I first encountered and reported the issue.

To make sure, I disabled the extension, restarted Midori with scripts
disabled, enabled scripts and accessed the offending page: Same
loading slowness. Now disable JS and the page loads quickly.

On Fri, Jul 20, 2012 at 6:52 PM, gue5t gue5t <email address hidden> wrote:
> Perhaps userstyles or userscripts are acting up? Try disabling them if
> they're enabed.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/979688
>
> Title:
> issues loading economist.com pages
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/midori/+bug/979688/+subscriptions

--
Do you know how to read?
http://www.alienetworks.com/srtest.cfm
http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
Do you know how to write?
http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Revision history for this message
gue5t gue5t (gue5t) wrote :

Looking closer I think WebKitGTK+ 1.2.7 is probably to blame--JavascriptCore has changed a lot since then.

Revision history for this message
v_2e (v-2e) wrote :

I have WebkitGTK-1.10.2 installed on my system currently, and the behaviour does not seem to have changed. The problem with high CPU usage and slow response on user actions is still there. I can think of two points that may help find a root of the problem:
1. First of all, I use a couple of WebkitGTK-based browsers besides Midori, and there are no such problems with them.
2. Like I pointed out in my Bug #1012721 , starting Midori with the '-a' parameter makes it work much faster and use considerably less CPU time. For example,
    midori -a economist.com

Revision history for this message
Liviu Andronic (landronimirc) wrote :

Midori midori-gtk3-0.4.9~r5940 ((null))
GTK+ 3.4.2 (3.4.2) Glib 2.32.3 (2.32.3)
WebKitGTK+ 1.8.3 (1.8.3) libSoup 2.38.1

Although some slowness is still present, I think now loading economist.com pages is snappier. Not sure if the bug is still valid (or invalid). I *think* I get similar results with midori -a economist.com .

Cody Garver (codygarver)
Changed in midori:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Midori because there has been no activity for 60 days.]

Changed in midori:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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