- Dillo-dev - lists.mailman3.com

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

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

Sept. 5, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

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

Sept. 4, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

Sept. 4, 2011

page that redraws endlessly

by corvid＠lavabit.com

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.

Sept. 4, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

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... Cheers, Johannes On Sat, Sep 03, 2011 at 05:00:10PM +0000, corvid wrote: > > The following suffices to trigger it for me: > > <table> > <tr> > <td> > <div> > <button></button> > </div> > <div> > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > <button></button> > </div> > </td> > </table> > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 4, 2011

page that redraws endlessly

by corvid＠lavabit.com

The following suffices to trigger it for me: <table> <tr> <td> <div> <button></button> </div> <div> words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> <button></button> </div> </td> </table>

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

I wrote: > > http://www.dillo.org/test/redraws.html > > For me, it still breaks with default dillorc options, and also with a > dillo from April 2010. I put up a new version where I trimmed the body down to something comprehensible. The <style> in <head> is still a big mess.

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

http://www.dillo.org/test/redraws.html For me, it still breaks with default dillorc options, and also with a dillo from April 2010.

Sept. 3, 2011

prefs.show_url

by corvid＠lavabit.com

I just found that turning off prefs.show_url messes up the appearance of the UI.

Sept. 3, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Fri, Sep 02, 2011 at 01:48:29PM -0300, Jorge Arellano Cid wrote: > On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > > > [...] > > > > > Any help is appreciatted. > > > > > > > > My guess is that it could be something like > > > > first, one bw asks for a page, and that becomes conn->bw, > > > > and then another bw starts also asking for the page, and > > > > the first bw closes, invalidating the conn->bw, and then > > > > the second bw closes and the cancel expect code tries to > > > > use the old bw. > > > > > > "bw" is a bit a misleading name, bacause each tab is a bw. > > > > > > OTOH, each tab has its own control panel and thus becomes > > > a browser window object. > > > > > > In the case you propose there'd be two different bw. > > > > Right. Why do you feel that they can't be two bws that were > > both closed from the keyboard? > > I have no problems with that. > > What I don't see is two bws with the same memory address being > closed from the keyboard. > > But now I see what you mean: which is a lingering bw in conn, > (which is compatible with my analysis), as there's no need for it > to exist in the UI when the event arrives. > > So we'de have two close events handled OK by two perfectly sane > bws, but one call made on an already defunct bw (i.e. not present > in the UI). > > And you hit it on the nail, because now I can reproduce it!!! Patch committed. FWIW, the testcase I used produced: ==17336== ERROR SUMMARY: 115 errors from 76 contexts (suppressed: 13 from 10) without the patch, and ==17468== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 10) with it. :-) -- Cheers Jorge.-

Sept. 2, 2011