December 2012 - Dillo-dev - lists.mailman3.com

Unused?: the url tag in the DPI start_send_page command

by jcid＠dillo.org

On Sun, Dec 09, 2012 at 04:14:01PM +0000, Jeremy Henty wrote: > > Everything that sends the start_send_page DPI command also sends a url > attribute with it, but I think this attribute is always ignored. > > Dillo processes the command in capi.c but it does nothing with it > because the Cache is already set up to receive the following raw data. > So it doesn't look at any attributes. The only other thing that > receives a start_send_page is the view source DPI and it doesn't look > at any of the attributes either (it extracts a url from the previous > tag in the stream, which it then sends back to Dillo to be ignored). View source shows the URL as page title. > So what is this attribute for? Future use? Or is it something that > just never got used? In general terms, there were ideas that went unused, and some extensions that were necessary to solve an unforeseen situation; as dpi authentication to avoid a local socket spoofing attack. The dpi framework is the same for several quite different dpi programs (aka plugins). The interface was kept more or less uniform, and each dpi chooses whether to use the info or not. -- Cheers Jorge.-

Dec. 9, 2012

Unused?: the url tag in the DPI start_send_page command

by onepoint＠starurchin.org

Everything that sends the start_send_page DPI command also sends a url attribute with it, but I think this attribute is always ignored. Dillo processes the command in capi.c but it does nothing with it because the Cache is already set up to receive the following raw data. So it doesn't look at any attributes. The only other thing that receives a start_send_page is the view source DPI and it doesn't look at any of the attributes either (it extracts a url from the previous tag in the stream, which it then sends back to Dillo to be ignored). So what is this attribute for? Future use? Or is it something that just never got used? Regards, Jeremy Henty

Dec. 9, 2012

Dpi_connect_socket retry

by p37sitdu＠lavabit.com

Dpi_connect_socket function from src/IO/dpi.c (also duplicated in test/cookies.c) has retry argument. It is set to TRUE on first call, and Dpi_connect_socket calls itself recursively with retry == FALSE in case of error. This retry function is not working. If connection fails, at line 645 sock_fd is set, but ret is still set to -1. Even if the second attempt to connect is successful, -1 is returned and conected sock_fd is lost. It is possible to fix it by adding "ret = sock_fd", but I think it is better to just remove retries completely. It is unlikely that connecting using loopback interface will fail on first try and succeed on retry. Also, comment says "the server closes sock_fd on error". However, sock_fd should still be closed by client to free allocated file descriptor. OS don't know if Dillo is going to read from it (in which case error such as ECONNRESET should happen) so file descriptor can't be reused. File descriptor should be closed in case of error in a_Dpip_build_cmd too. Patch to fix this function and its calls in src/IO/dpi.c and test/cookies.c is attached.

Dec. 9, 2012

rm test/fltk_browser

by sgeerken＠dillo.org

On Sun, Dec 09, corvid wrote: > I'd like to delete test/fltk_browser.cc. > > I was just reimplementing FltkListResource to use Fl_Browser instead > of Fl_Tree (not to put in this release, although it seems to be working), > and the existence of that little file doesn't...test anything, or make > some obscure concepts clear, or anything... Oh, there is even my name in the copyright notice ... but I do not remember anything, so simply remove it. Sebastian

Dec. 9, 2012

rm test/fltk_browser

by corvid＠lavabit.com

I'd like to delete test/fltk_browser.cc. I was just reimplementing FltkListResource to use Fl_Browser instead of Fl_Tree (not to put in this release, although it seems to be working), and the existence of that little file doesn't...test anything, or make some obscure concepts clear, or anything...

Dec. 9, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > On Fri, Dec 07, corvid wrote: > > For instance, > > > > dillo -geometry 850x700 http://fltk.org > > > > makes the names of the snapshots very narrow, and if I try > > > > penalty_hyphen=inf > > > > part of the fltk-2 snapshot link is obscured by the image. I still see this, or at least the penalty_hyphen=inf case. I didn't try the default penalty_hyphen case. > On Sat, Dec 08, corvid wrote: > > Sebastian wrote: > > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > > far, but please take another look. > > > > Text files are giving me segfaults... > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, > > wordIndex=38684) at textblock_linebreaking.cc:676 > > 676 par->maxParMin = prevPar->maxParMin; > > I was not able to reproduce any of these bugs, but I found another > bug, by which <http://www.dillo.org/CSS.html> was rendered with much > too wide columns. > > Since this fixed a memory problems, chances are high that a couple of > other problems are fixed, so please test again. Not getting segfaults on the files that broke yesterday, but I note that I'm still getting messages from valgrind like: ==24632== Conditional jump or move depends on uninitialised value(s) ==24632== at 0x8115600: fl_utf8fwd (fl_utf.c:228) ==24632== by 0x80A275E: dw::fltk::FltkPlatform::nextGlyph(char const*, int) (fltkplatform.cc:594) ==24632== by 0x8099B1C: dw::core::Layout::nextGlyph(char const*, int) (layout.hh:316) ==24632== by 0x809836C: dw::Textblock::addText(char const*, unsigned int, dw::core::style::Style*) (textblock.cc:1469) ==24632== by 0x8071123: DilloPlain::addLine(char*, unsigned int) (plain.cc:146) ==24632== by 0x8071246: DilloPlain::write(void*, unsigned int, int) (plain.cc:179) ==24632== by 0x8071400: Plain_callback(int, _CacheClient*) (plain.cc:229) ==24632== by 0x8064F6A: Cache_process_queue (cache.c:1214) ==24632== by 0x80645A9: a_Cache_process_dbuf (cache.c:899) ==24632== by 0x80682F9: a_Capi_ccc (capi.c:742) ==24632== by 0x805F83C: a_Chain_fcb (chain.c:114) ==24632== by 0x808BC25: Dpi_parse_token (dpi.c:220)

Dec. 8, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Fri, Dec 07, corvid wrote: > Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > far, but please take another look. > > Is everything about hyphenation supposed to work at this point? It was supposed to work. > For instance, > > dillo -geometry 850x700 http://fltk.org > > makes the names of the snapshots very narrow, and if I try > > penalty_hyphen=inf > > part of the fltk-2 snapshot link is obscured by the image. On Sat, Dec 08, corvid wrote: > Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > > far, but please take another look. > > Text files are giving me segfaults... > > Program received signal SIGSEGV, Segmentation fault. > 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, > wordIndex=38684) at textblock_linebreaking.cc:676 > 676 par->maxParMin = prevPar->maxParMin; I was not able to reproduce any of these bugs, but I found another bug, by which <http://www.dillo.org/CSS.html> was rendered with much too wide columns. Since this fixed a memory problems, chances are high that a couple of other problems are fixed, so please test again. Sebastian

Dec. 8, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > far, but please take another look. Text files are giving me segfaults... Program received signal SIGSEGV, Segmentation fault. 0x0809f0b8 in dw::Textblock::handleWordExtremes (this=0x819fdd8, wordIndex=38684) at textblock_linebreaking.cc:676 676 par->maxParMin = prevPar->maxParMin;

Dec. 8, 2012

Extensions for hyphenation

by corvid＠lavabit.com

Sebastian wrote: > > Just pushed to http://hg.dillo.org/dillo. I've found no problems so > far, but please take another look. Is everything about hyphenation supposed to work at this point? For instance, dillo -geometry 850x700 http://fltk.org makes the names of the snapshots very narrow, and if I try penalty_hyphen=inf part of the fltk-2 snapshot link is obscured by the image.

Dec. 7, 2012

[patch] dpid/dpid.c unused variable

by corvid＠lavabit.com

p37sitdu wrote: > Patch removes unused variable usr_srv_num. Committed.

Dec. 7, 2012