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

Double buffering flicker on window resize.

by johnfound＠asm32.info

Hi, dillo developers! I observed another nasty bug in Dillo dev-3.1 Maybe it is known. If so, excuse my ignorance. :) When the option buffered_drawing=2 for double buffering and the browser window is resized by the user, it seems that the back buffer is drawn on the screen too early after the reallocation and is full of garbage instead of the rendered page. This way, during the resizing, very heavy flicker appears, which IMHO is not good for double buffering drawing scheme. Best Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 29, 2016

Dill 3.0.5 breaks on Mac OS

by Johannes.Hofmann＠gmx.de

could you please try with attached patch applied? Cheers, Johannes On Fri, Feb 26, 2016 at 08:58:36PM -0500, Yves de Champlain wrote: > Hi > > As I said in a subsequent mail, 3.0.4 does not work either anymore > > yves > > > > Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > > > interesting. could you please try again if dillo-3.0.4 still works > > with your current setup? > > > > Cheers, > > Johannes > > > > On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: > >> I tried to send email about this very issue to this mailing list, but the > >> mail failed for some obscure reason. > >> > >> Thanks for bringing this up. > >> > >> Cheers > >> > >> - Martin - > >> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > >> > >>> Hi > >>> > >>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : > >>> > >>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > >>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > >>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > >>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > >>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > >>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > >>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > >>> xembed.cc > >>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > >>> mv -f .deps/image.Tpo .deps/image.Po > >>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > >>> mv -f .deps/form.Tpo .deps/form.Po > >>> mv -f .deps/findbar.Tpo .deps/findbar.Po > >>> mv -f .deps/menu.Tpo .deps/menu.Po > >>> In file included from xembed.cc:18: > >>> In file included from /opt/local/include/FL/x.H:43: > >>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > >>> not found > >>> # include "../src/Fl_Font.H" > >>> > >>> > >>> It seems that dillo is trying to use X but on Mac, but fltk is using > >>> quartz. > >>> > >>> The problem has been reported on many systems. > >>> > >>> Dillo 3.0.4 was working fine. > >>> > >>> Thanks > >>> > >>> yves > >>> > >>> > >>> > >>> _______________________________________________ > >>> Dillo-dev mailing list > >>> Dillo-dev at dillo.org > >>> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >>> > > > >> _______________________________________________ > >> Dillo-dev mailing list > >> Dillo-dev at dillo.org > >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2016

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

Hi As I said in a subsequent mail, 3.0.4 does not work either anymore yves > Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > interesting. could you please try again if dillo-3.0.4 still works > with your current setup? > > Cheers, > Johannes > > On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: >> I tried to send email about this very issue to this mailing list, but the >> mail failed for some obscure reason. >> >> Thanks for bringing this up. >> >> Cheers >> >> - Martin - >> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: >> >>> Hi >>> >>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : >>> >>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. >>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' >>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include >>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include >>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE >>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti >>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o >>> xembed.cc >>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po >>> mv -f .deps/image.Tpo .deps/image.Po >>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po >>> mv -f .deps/form.Tpo .deps/form.Po >>> mv -f .deps/findbar.Tpo .deps/findbar.Po >>> mv -f .deps/menu.Tpo .deps/menu.Po >>> In file included from xembed.cc:18: >>> In file included from /opt/local/include/FL/x.H:43: >>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file >>> not found >>> # include "../src/Fl_Font.H" >>> >>> >>> It seems that dillo is trying to use X but on Mac, but fltk is using >>> quartz. >>> >>> The problem has been reported on many systems. >>> >>> Dillo 3.0.4 was working fine. >>> >>> Thanks >>> >>> yves >>> >>> >>> >>> _______________________________________________ >>> Dillo-dev mailing list >>> Dillo-dev at dillo.org >>> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >>> > >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Feb. 27, 2016

Solid rectangular placeholder for non-supported images

by jerome.borme＠gmail.com

Hello, I read a news flux where each news item comes with a small image. Dillo does not like the markup and replaces the image with a rectangular placeholder with a solid colour fill. This happens even when images loading is disabled (while other regular images are simply not displayed, but not replaced by a filled rectangle), and the colour fill seems to be randomly chosen at Dillo startup. I think this behaviour was not intentional. Right now the workaround is to not compile gif support. The placeholder is then replaced by the alt text, which I prefer to some brightly coloured rectangle. Version: Dillo 3.0.5 Page: http://www.lemonde.fr/actualite-en-continu/ Snippet: <img width="147" height="97" data-item-type="article" data-src="http://s2.lemde.fr/image/2016/02/26/147x97/4872606_7_843b_les-ministres-des…" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-lazyload="true" alt="Les ministres..." title="..." onload="lmd.pic(this);" onerror="lmd.pic(this);" class="lazy-retina"> Thanks, J?r?me

Feb. 26, 2016

Dill 3.0.5 breaks on Mac OS

by Johannes.Hofmann＠gmx.de

interesting. could you please try again if dillo-3.0.4 still works with your current setup? Cheers, Johannes On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: > I tried to send email about this very issue to this mailing list, but the > mail failed for some obscure reason. > > Thanks for bringing this up. > > Cheers > > - Martin - > On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > > > Hi > > > > When compiling dillo 3.0.5 on Mac OS 10.11, I get : > > > > /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > > -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > > -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > > -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > > -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > > -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > > -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > > xembed.cc > > mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > > mv -f .deps/image.Tpo .deps/image.Po > > mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > > mv -f .deps/form.Tpo .deps/form.Po > > mv -f .deps/findbar.Tpo .deps/findbar.Po > > mv -f .deps/menu.Tpo .deps/menu.Po > > In file included from xembed.cc:18: > > In file included from /opt/local/include/FL/x.H:43: > > /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > > not found > > # include "../src/Fl_Font.H" > > > > > > It seems that dillo is trying to use X but on Mac, but fltk is using > > quartz. > > > > The problem has been reported on many systems. > > > > Dillo 3.0.4 was working fine. > > > > Thanks > > > > yves > > > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Feb. 26, 2016

Dill 3.0.5 breaks on Mac OS

by matlads＠gmail.com

I tried to send email about this very issue to this mailing list, but the mail failed for some obscure reason. Thanks for bringing this up. Cheers - Martin - On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > Hi > > When compiling dillo 3.0.5 on Mac OS 10.11, I get : > > /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > xembed.cc > mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > mv -f .deps/image.Tpo .deps/image.Po > mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > mv -f .deps/form.Tpo .deps/form.Po > mv -f .deps/findbar.Tpo .deps/findbar.Po > mv -f .deps/menu.Tpo .deps/menu.Po > In file included from xembed.cc:18: > In file included from /opt/local/include/FL/x.H:43: > /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > not found > # include "../src/Fl_Font.H" > > > It seems that dillo is trying to use X but on Mac, but fltk is using > quartz. > > The problem has been reported on many systems. > > Dillo 3.0.4 was working fine. > > Thanks > > yves > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 26, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Thu, Feb 25, 2016 at 08:49:20AM +0100, Andreas Kemnade wrote: > hmm, current dillo gives a lot of errors with valgrind with that site. > Maybe that is a point to look at. I'm not seeing them. They may be connected with: https://www.openssl.org/docs/faq.html#PROG14 14. Why does Valgrind complain about the use of uninitialized data? When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings.

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by andreas＠kemnade.info

Hi, On Wed, 2016-02-24 at 12:21 +0200, John Found wrote: > After this code inserted, the crash seems to be fixed. Mentioned MS site is loaded normally. > > Thanks! > hmm, current dillo gives a lot of errors with valgrind with that site. Maybe that is a point to look at. Regards, Andreas

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

Now it crashes again. The output messages are in the attached file. On Thu, 25 Feb 2016 05:21:06 +0000 eocene <eocene at gmx.com> wrote: > On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > > Oh, sorry. I was happy to have it work and forgot to report. :) > > Here is the dump from the error, down to the end: > > > > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call > > Ah, openssl makes so little effort toward anything. > I see that apache, nginx, etc. started to see lots of those messages with > openssl 1.0.2f, so I tried that version, and still no error messages for me. > (1.0.2f apparently becomes somewhat strict about shutdown during handshake, > whereas it seems earlier versions would just report success and not do > anything.) > > There is an ERR_get_error_line() function which might help. Diff attached. > The manpage didn't bother to go into any normal detail about the buffer it > wants for the filename argument, of course, but we'll see. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > Oh, sorry. I was happy to have it work and forgot to report. :) > Here is the dump from the error, down to the end: > > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call Ah, openssl makes so little effort toward anything. I see that apache, nginx, etc. started to see lots of those messages with openssl 1.0.2f, so I tried that version, and still no error messages for me. (1.0.2f apparently becomes somewhat strict about shutdown during handshake, whereas it seems earlier versions would just report success and not do anything.) There is an ERR_get_error_line() function which might help. Diff attached. The manpage didn't bother to go into any normal detail about the buffer it wants for the filename argument, of course, but we'll see.

Feb. 25, 2016