- Dillo-dev - lists.mailman3.com

Recent problems with remote css and youtube

by corvid＠lavabit.com

I wrote: > bf wrote: > > Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? > > I can reproduce this. It probably has something to do with the > transparent borders change that I made in December... My transparent borders code and Jorge's border code were fighting with each other. Does the attached fix it for you? Jorge: Were any of those borderColor.top for a reason, or just oversights? If the latter, I can think of a simple change that would be less error-prone :)

Feb. 10, 2011

Recent problems with remote css and youtube

by corvid＠lavabit.com

bf wrote: > Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? I can reproduce this. It probably has something to do with the transparent borders change that I made in December...

Feb. 10, 2011

Recent problems with remote css and youtube

by bf2006a＠yahoo.com

Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? Regards, b. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/

Feb. 10, 2011

Valgrind errors from downloads.cc

by jcid＠dillo.org

On Wed, Feb 09, 2011 at 05:14:21PM +0000, corvid wrote: > Jeremy wrote: > > Valgrind is reporting uninitialised data in DLItem::update() in > > downloads.cc[1]. Here's the code with the offending lines (705, 706) > > marked. > > > > /* Rate */ > > if (csec >= 2) { > > tsec = (float) (curr_time - twosec_time); > > ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; > > ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); > > prRate->copy_label(str); > > prRate->redraw_label(); > > } > > > > I'm wondering what is happening here. DLItem::update() is scheduled > > to be run every second. I think that twosec_time is only set to an > > initialised value when the function has been run at least twice > > before. Also, csec is calculated from the difference between the > > current time and the initial time. Is it possible that the "csec >= > > 2" could be true even when the function has been run only once before? > > After all, the timing of callbacks is never exact. Perhaps the > > callback should explicitly count how many times it has been called > > rather than attempt to work it out from the timing? > > (The list software never did send me a copy of your msg...) Strange. Although I remember the wearlab was down a few days ago... > Would something like the following work? > > --- a/dpi/downloads.cc Tue Jan 11 01:18:28 2011 +0000 > +++ b/dpi/downloads.cc Sun Feb 06 20:40:53 2011 +0000 > @@ -318,6 +318,8 @@ > // Init value. Reset later, upon the first data bytes arrival > init_time = time(NULL); > > + twosec_time = onesec_time = init_time; > + > // BUG:? test a URL with ' inside. > /* escape "'" character for the shell. Is it necessary? */ > esc_url = Escape_uri_str(url, "'"); Most probably. I have a vague memory of noticing the issue when coding it long ago, but not caring much as the following second the display would be updated with correct data. -- Cheers Jorge.-

Feb. 9, 2011

Valgrind errors from downloads.cc

by corvid＠lavabit.com

Jeremy wrote: > Valgrind is reporting uninitialised data in DLItem::update() in > downloads.cc[1]. Here's the code with the offending lines (705, 706) > marked. > > /* Rate */ > if (csec >= 2) { > tsec = (float) (curr_time - twosec_time); > ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; > ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); > prRate->copy_label(str); > prRate->redraw_label(); > } > > I'm wondering what is happening here. DLItem::update() is scheduled > to be run every second. I think that twosec_time is only set to an > initialised value when the function has been run at least twice > before. Also, csec is calculated from the difference between the > current time and the initial time. Is it possible that the "csec >= > 2" could be true even when the function has been run only once before? > After all, the timing of callbacks is never exact. Perhaps the > callback should explicitly count how many times it has been called > rather than attempt to work it out from the timing? (The list software never did send me a copy of your msg...) Would something like the following work? --- a/dpi/downloads.cc Tue Jan 11 01:18:28 2011 +0000 +++ b/dpi/downloads.cc Sun Feb 06 20:40:53 2011 +0000 @@ -318,6 +318,8 @@ // Init value. Reset later, upon the first data bytes arrival init_time = time(NULL); + twosec_time = onesec_time = init_time; + // BUG:? test a URL with ' inside. /* escape "'" character for the shell. Is it necessary? */ esc_url = Escape_uri_str(url, "'"); > [1] > http://starurchin.org/dillo/valgrind.html > http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… > http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… > http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… > http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9… >

Feb. 9, 2011

Valgrind errors from downloads.cc

by onepoint＠starurchin.org

Valgrind is reporting uninitialised data in DLItem::update() in downloads.cc[1]. Here's the code with the offending lines (705, 706) marked. /* Rate */ if (csec >= 2) { tsec = (float) (curr_time - twosec_time); ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); prRate->copy_label(str); prRate->redraw_label(); } I'm wondering what is happening here. DLItem::update() is scheduled to be run every second. I think that twosec_time is only set to an initialised value when the function has been run at least twice before. Also, csec is calculated from the difference between the current time and the initial time. Is it possible that the "csec >= 2" could be true even when the function has been run only once before? After all, the timing of callbacks is never exact. Perhaps the callback should explicitly count how many times it has been called rather than attempt to work it out from the timing? Regards, Jeremy Henty [1] http://starurchin.org/dillo/valgrind.html http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9…

Feb. 7, 2011

for 1.3 port, latest fltk snapshot is required

by corvid＠lavabit.com

..because we're using some new stuff that they added for us http://fltk.org/newsgroups.php?s23204+gfltk.general+v23210+T0

Feb. 4, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

Anybody else notice the mouse wheel is slow within Dillo? Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower compared to Seamonkey. Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. -- Roger http://rogerx.freeshell.org/

Feb. 4, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

> On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. Yup. Bingo! Your latest commit fixed the scrollbar stagger/stall! -- Roger http://rogerx.freeshell.org/

Feb. 4, 2011

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

oh, btw, there appears to be no CPU/Memory excessive usage either. It just happens as if the code is missing a refresh cycle or waiting on something to return? > On Thu, Feb 03, 2011 at 05:49:45AM +0000, corvid wrote: >I'm not too clear on what you might be seeing, but I just pushed >a change that fixes _my_ main problem with the scrollbars, and >maybe they're the same thing. > >There's still the issue that we send events to the scrollbars >when they're hidden. We could check visible(), but perhaps >Johannes would prefer to do some more battle with the resizing >instead. > > >_______________________________________________ >Dillo-dev mailing list >Dillo-dev(a)dillo.org >http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2011