Significant idle CPU usage with GTK 3

Mi X CPU is in mora than 50% :(

The essence is infinite redrawing of the web view. After hiding the tabbar the issue disappears (toggle fullscreen or activate tab panel extension).
Disabling the KatzeThrobber doesn't make a difference.
Disabling notebook label resizing has literally no effect in GTK+3.
Disabling tab label ellipsizing misteriously disables resizing of tabs.

This issue is completely reproducible in midori 3.4 using webkitgtk 1.6.3 and gtk 3.2.3.

Test regimen:

Test 1:

- Run midori with one open blank window/tab.
- CPU should baseline at 0%
- Load a static page: /usr/share/doc/midori/faq.html
- Observe CPU. Should still be at 0%

(conclusion: issue is unrelated to static web content)

Test 2:

- Run midori
- Load a web page from the internet that is either static or has no repeating javascript events
- Observe CPU. Should still be at 0%

(conclusion: issue is not directly related to any page content from network sources)

Test 3:
- Run midori using an empty page (set your default to an empty page or empty speeddial)
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Minimize midori
- CPU should be at 0%
- Un-minimize midori
- CPU should be at 0%
- Select the first tab
- CPU usage climbs to around 30 - 40% (depending on your CPU)
- Select the second tab
- CPU stays high
- Minimize
- CPU stays high
- Un-minimize
- CPU stays high
- Close the 2nd tab
- CPU stays high

(conclusion: midori code that controls the tab selection or view repaint code is not deregistering the new tab view from repaint or update event. unrelated to any underlying X redraw or backing store refresh)

 Test 4:

- open midori with an empty page
- open a new empty tab
- close the new empty tab
- CPU climbs to 30-40%

(conclusion: since the close event forces an implicit "change view" then it doesn't have anything to do with the user actually selecting the tab. It's very likely that a change or bug in the gtk3 API for registering redraw events causes this. It's also possible that gtk3 API finally properly implements its redraw registration API which exposes a bug in midori or possibly webkitgtk [although that would be unlikely since epiphany/gtk3 doesn't exhibit this behavior])

Addition to comment #3:

After rebuilding midori with full debugging enabled it seems somewhat less sensitive to this CPU consumption bug. Namely:

1. Creating empty tabs and then just closing a tab has no effect

However, Creating two tabs and then selecting the 1st tab still works.

Other combinations produce the effect, but I haven't seen a pattern yet.

Addition to Comment #4:

Two more comments regarding the debug version:

1. The bug manifests whenever you manually switch to a new tab.
2. Even compiled with profiling and debugging information I haven't been able to gather profiling statistics. Has anyone else tried this?

Christian noted that he validated that problem is the continuous redraw events that are occurring. But does webkit think that it should continously redraw? Could it be a resource cacheing issue in Webkit? If there is a cache error that never updates the expiration time of page resources then as soon as the user selects a tab the faulty cache code sees an expired webview and redraws. After redraw the event engine sees the expired resources again and does a redraw.

Let me check and see if forcing a manual reload of the page properly updates any resource expiration time.

I believe the issue can be narrowed down to page cache resource expiration times being invalidated when a previous page is loaded. If this is true, then a manual reload of the page should stop the continuous page redraws:

Test:

1. Start midori with no more than one page loaded
2. Load a relatively static web page: (eg: www.debian.org)
3. Using top or htop observe the avg midori cpu usage. It should settle down to 0%
4. Open a new tab on www.debian.org. Observe that avg cpu usage is still 0% after a few seconds
5. Select the first tab. Observe avg cpu usage rises to approximately 35%
6. Force a reload on that page
7. Observe that the avg cpu usage returns to 0%
8. Select the second tab
9. Observe that the avg cpu usage again climbs to 35%
10. Force a reload on the page
11. Observe that the avg cpu usage drops to 0%

This very likely has something to do with the cache expiration time on an existing web page either being invalidated when it is no longer the current page or when a pre-existing web page is brought back into view.

Can someone look at the page resource expiration times or check the expiration and resource reload code to see if there's a bug in there somewhere? Could this have crept into webkit in between versions?

Two issues:

1. I don't know what this has to do with an upgrade from gtk2 to gtk3, but there's probably some interaction or patch that's breaking this.

2. A couple links that I've seen to the same type of issue in maxthon and safari are the following:

http://www.maxthon.com/mx3/changelog/
  (search for 'resource reload')

http://www.stevesouders.com/blog/2011/06/27/unexpected-reloads-in-webkit/

Apparently GTK+ 3.2.3 WebKitGTK+ 1.6.3 doesn't have the bug.

This issue is not fixed in GTK+ 3.2.3[introspection xinerama] with WebKitGTK+ 1.6.3 [gstreamer introspection spell webgl] on Hardened Gentoo. No change from WebKitGTK+ 1.6.1.

See extra information in Gentoo bug report: https://bugs.gentoo.org/show_bug.cgi?id=409697

Bug #1002183

Similiar?

why moved to unconfirmed without any further explanation? that's not the way to deal with bug reports

Actually, I cant reproduce this myself either, its steady at around 0-5% here.

Command line midori
Midori midori-gtk3-0.5.5~r6411 ((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
cairo 1.10.2 (1.10.2) libnotify 0.7.5
gcr No granite No
Platform X11; Linux i686
Identification Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; en-us)
Video Formats H264 [x] Ogg Theora [x] WebM [x]

Incomplete = Needs more info, may not be valid, or not reproducible.

This "bug" is purely symptomatic and people with totally different prerequisites claim to see the "same" issue. You can literally see a person commenting after me saying the exact opposite of my testing:
> Apparently GTK+ 3.2.3 WebKitGTK+ 1.6.3 doesn't have the bug.
> This issue is not fixed in GTK+ 3.2.3[introspection xinerama] with WebKitGTK+ 1.6.3

There is nothing wrong with Midori, WebKit or GTK+. Whatever the problem is, it's evidently something else.

> There is nothing wrong with Midori, WebKit or GTK+. Whatever the problem is, it's evidently something else.
If it is, maybe it would be useful to check the Bug #1012721 for the similar problem? I reported it rather long ago, but the situation remains unchanged till now. And also I provided some requested additional information there, but unfortunately, did not receive any response. So maybe it is good to check and close (if resolved) all the "high CPU usage" bugs at once?

Note that the bug was duped onto bug 1103102. In any case all of those bugs have no clear-cut context explaning *when* CPU is running unexpectedly. In all cases the deciding factor causing the issues is unknown.

As an example there used to be a JavascriptCore bug which caused high CPU usage when closing a website at the wrong point in time, the work-around being to re-open the exact tab, that is to say it was a race condition within WebKit. It would occur in particular on stackoverflow and askubuntu.
If you can narrow down what you're seeing similar to this I would highly appreciate it. Otherwise there's nothing I or anyone else can investigate.

The only thing that seems useful is the following. In my initial bugreport discussion you asked me:

"Could you try if "midori -a about:blank" or "midori -p" suffers in the same way?"

And I responded that I tested this and found that:

"Both of the modes you suggested work fast and do not consume so much CPU time (not more than 30% during page loading)!"

So I thought it meant something important, but did not receive any further questions or suggestions. Does this information help to trace the problem or not? In any case I am ready to perform some other tests to help with this bug.

Commonly if your answer to "does it also occur with midori -p" is "yes" it points towards a WebKit/ JavascriptCore problem. As it doesn't we can assume it's something not found in private browsing, for example anything related to writing files (use strace to watch for excessive activity), DBus, extensions, session management. Still if I advise you to investigate any of these it's a shot in the dark, I have no concrete leads and that's why I refrained from specific suggestions.

  Hello!
  Here are some news. I deleted everything in

~/.cache/midori
~/.config/midori
~/.local/share/midori

and now MIdori does not consume too much of CPU power. At first, I thought it was because of the "~/.local/share/midori/styles/scrollfix.user.css" stylesheet which I used to fix some problems in Midori long ago, but I could not reproduce the bug even putting this user script back. So now I am not sure about what was causing the problem.

I don't suppose you still have the folders in your wastebin and would be able to check which of these was the offender?

Unfortunately, you are right. I was stupid enough to delete everything with 'rm -r' and not save for the test. The only thing I have is a list of files which were present there.

Is it possible for you to attach the list in a possibly stripped form? I can't say what I expect to see but something in there resolved the issues for you and if we get anybody else to reproduce something may turn up.

Sure. Here is the list of files I deleted in order to get Midori work properly:

/home/vova/.cache/midori
/home/vova/.cache/midori/web
/home/vova/.cache/midori/thumbnails/1941c6906587a3ce7524598c74421ae3.png
. . .
/home/vova/.cache/midori/thumbnails/dba9c2f3da2242f2ad330a4036ad912f.png
/home/vova/.cache/midori/web/1004769730
. . .
/home/vova/.cache/midori/web/986319997

/home/vova/.config/midori
/home/vova/.config/midori/accels
/home/vova/.config/midori/bookmarks.db
/home/vova/.config/midori/bookmarks.db.back
/home/vova/.config/midori/bookmarks_v2.db
/home/vova/.config/midori/config
/home/vova/.config/midori/cookies.db
/home/vova/.config/midori/cookies.db-journal
/home/vova/.config/midori/cookies.txt
/home/vova/.config/midori/extensions
/home/vova/.config/midori/history.db
/home/vova/.config/midori/history.db-shm
/home/vova/.config/midori/history.db-wal
/home/vova/.config/midori/hsts
/home/vova/.config/midori/search
/home/vova/.config/midori/session.xbel
/home/vova/.config/midori/speeddial
/home/vova/.config/midori/speeddial.json
/home/vova/.config/midori/tabtrash.xbel
/home/vova/.config/midori/extensions/libadblock.so
/home/vova/.config/midori/extensions/libaddons.so
/home/vova/.config/midori/extensions/libcolorful-tabs.so
/home/vova/.config/midori/extensions/libcookie-manager.so
/home/vova/.config/midori/extensions/libcookie-permissions.so
/home/vova/.config/midori/extensions/libcopy-tabs.so
/home/vova/.config/midori/extensions/libdelayed-load.so
/home/vova/.config/midori/extensions/libexternal-download-manager.so
/home/vova/.config/midori/extensions/libfeed-panel.so
/home/vova/.config/midori/extensions/libformhistory.so
/home/vova/.config/midori/extensions/libhistory-list.so
/home/vova/.config/midori/extensions/libmouse-gestures.so
/home/vova/.config/midori/extensions/libshortcuts.so
/home/vova/.config/midori/extensions/libstatus-clock.so
/home/vova/.config/midori/extensions/libstatusbar-features.so
/home/vova/.config/midori/extensions/libtab-panel.so
/home/vova/.config/midori/extensions/libtabs-minimized.so
/home/vova/.config/midori/extensions/libtoolbar-editor.so
/home/vova/.config/midori/extensions/libadblock.so/config
/home/vova/.config/midori/extensions/libaddons.so/addons
/home/vova/.config/midori/extensions/libformhistory.so/forms.db
/home/vova/.config/midori/extensions/libformhistory.so/forms.db-journal
/home/vova/.local/share/midori
/home/vova/.local/share/midori/styles
/home/vova/.local/share/midori/styles/scrollfix.user.css
############ End of list #############

I personally don't think the files in '.cache' directory had any impact, but the ones in the '.config' directory could.

Hello! Today I noticed the similar problem in Midori's behaviour. However, this time I decided to delete the suspicious files one by one in order to find the guilty.
It turned out to be the
  ~/.config/midori/cookies.db
At least, when I delete it, the problem vanishes; when I put it back there, the problem appears again.

hmm do you have cookie manager (the panel view of cookies) extension enabled by any chance v_2e? I think slows down the whole browser considerably in some cases.

@Paweł Forysiuk (tuxator)
Yes! You are right! I had the cookie manager plugin turned on. When I turn it off, the problem disappears. When I turn it on, the problem returns back, so no it seems to be a perfectly reproducible issue. Thanks for the tip!