February 2011 - Dillo-dev - lists.mailman3.com

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

dillo fltk-1.3 scroll bar delay

by rogerx.oss＠gmail.com

When using the scrollbar to scroll, the scrollbar & page will stop scrolling even though you are still trying to use the scrollbar to move up or down. However, if you use pgdown/pgup... are just click on the bottom or top of the scrollbar, scrolling will proceed page by page without stopping. This bug occurs when the user tries to smooth scroll the page up or down and ceases to exist when moving up or down by page height. I pulled this git yesterday. I'll re-pull/upgrade today sometime. > 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

dillo fltk-1.3 scroll bar delay

by johannes.hofmann＠gmx.de

On Thu, Feb 03, 2011 at 01:53:03AM +0000, Roger wrote: > > I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 > port. Here's what I get so far. Can you please explain the exact issue you are seeing? Is scrolling generally slow (also with PageDown or drag scrolling), or is it just scrollbar related? For me scrolling is pretty snappy since quite some time now. Cheers, Johannes

Feb. 3, 2011