On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote:
On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote:
On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote:
Johannes wrote:
Thanks for the cleaned up test case. It's still remarkably complex. I see the issue also with dillo-2.1.1. Nevertheless we should definately try to fix it. I will play with it a bit...
I wonder whether it is just the limit_text_width button problem dressed up in more complex clothing.
As funny as it sounds, hg bisect says it's rev 6a892184d498 where it starts the redraw loop! And indeed, if I do
--- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 @@ -219,10 +219,11 @@ setlocale(LC_NUMERIC, oldLocale); dFree(oldLocale);
- +#if 0 if (prefs.limit_text_width) { /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); prefs.limit_text_width = FALSE; } +#endif }
it loops with limit_text_width=NO and doesn't with limit_text_width=YES.
Ah wait! With limit_text_width=YES it's just not flickering. CPU is still at 100%.
The following test patch seems to stop it: --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 @@ -268,7 +268,7 @@ /** * \todo The argument to queueResize is not always true. (But this works.) */ - resource->queueResize (true); + resource->queueResize (false); } Maybe the comment isn't always right? Cheers, Johannes