- Dillo-dev - lists.mailman3.com

easy way to get many root certificates?
by corvid＠lavabit.com June 20, 2008

June 20, 2008

I'm tired of clicking on the "remote certificate cannot be verified" message. I added a couple of lines to https.c so that it would save certificates. When I encountered the next https page, "openssl x509 -text -in [certificate]" showed that Equifax was the issuer. I got their root certificate, stuck it in .dillo/certs, found the hash value with "openssl x509 -hash -in [certificate]", and linked it to [hash].0. And, hey, no more message! But I don't want to do that over and over for all of the common root certificates. It seems that you can get the certificates out of firefox if you have some program called certutil, but, so far as I can tell, this requires getting a bunch of mozilla code known as NSS that is something like six megs of source. This is nowhere near worth the headaches that would surely result from trying to compile such a thing. So, does anyone happen to know an easy and convenient way to deal with this?

3 5

[patch] fix FltkPlatform destructor
by Johannes.Hofmann＠gmx.de June 19, 2008

June 19, 2008

Hi, this fixes a small memory leak in FltkPlatform. Johannes

2 1

recent style/layout segfaults
by corvid＠lavabit.com June 18, 2008

June 18, 2008

I've seen occasional segfaults in recent weeks, and twice now I've been able to catch them when I remembered to have gdb going (and, well, zero times when I remembered to have ulimit -c unlimited) These two have been nearly identical. Here's the one I just got: #0 0x00000048 in ?? () #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, attrs=0x81dfc08) at layout.hh:253 #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, layout=0x815ca58) at style.cc:287 #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, layout=0x815ca58) at style.hh:587 #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) at style.hh:505 #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, widget=0x827b3b0) at layout.cc:175 #8 0x0805aea8 in a_Web_dispatch_by_type ( Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, Data=0x821d324) at web.cc:94 .. The layout in frame 3 was: p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}} and the layout in frame 7 was: p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}} Both look fairly layoutish. I only had one bw open at the time of crash. My guess at the problem: StyleTable will give you back whatever Style matches your attrs, but maybe that Style was created with a different layout.

3 11

patch: view gzipped local files
by corvid＠lavabit.com June 18, 2008

June 18, 2008

I'd been considering this for a while, but couldn't decide whether it had any real value. Then it occurred to me that if people are often using dillo as a local document viewer for minimalist systems, they may value the ability to compress those documents.

2 1

About the patch for Style-related crashes: +1 !
by onepoint＠starurchin.org June 18, 2008

June 18, 2008

It's gone a little quiet here, I hope everyone's OK! Anyway I just want to register a yes vote for the patch that was proposed last week to fix crashes from inside Style::unref() when closing windows. These crashes were making Dillo almost unusable for me, but I applied the patch on Sunday and life has been blissful ever since. (I sound like one of those awful TV ads, don't I?) The plan was to wait a week for comments before deciding. I hope it gets committed soon because a fix for these crashes is IMHO vital. Regards, Jeremy Henty

1 0

Valgrind: hashing StyleAttr objects accesses uninitialized data
by onepoint＠starurchin.org June 13, 2008

June 13, 2008

Ever since StyleAttr objects were cached in a hash to promote sharing, valgrind has reported nearly 1000 branches dependent on uninitialised data when dillo renders the splash page. These all come from StyleAttrs::hashValue() and StyleAttrs::equals() : if I hack hashValue() to return ((intptr_t) this) and equals() to return (this == otherAttrs) then the warnings disappear. Is this a problem? If these methods are accessing uninitialised data members then what happens when that data is initialised? The return values of hashValue() and equals() could change, which sounds like a potential source of bugs. Even if it's not a bug, if the value of hashValue() is unpredictable then we might not be sharing StyleAttr objects as much as we could and so we could be wasting memory. If it is correct to have code that raises these warnings, perhaps there could be a "#define VALGRIND" switch so developers could easily compile a dillo that doesn't raise them? (It's possible to silence them with a valgrind suppression file but that is tedious and risks hiding other warnings. It would be much more straightforward to have a valgrind-clean version of the code.) Comments are welcome, Jeremy Henty

3 6

form.cc: refactor DilloHtmlForm::eventHandler()
by onepoint＠starurchin.org June 11, 2008

June 11, 2008

Three small patches that clean up form event handling: 1: refactor file loading into DilloHtmlInput::readFile() 2: refactor form submission into DilloHtmlForm::submit() 3: refactor the input logic into DilloHtmlInput::activate() Regards, Jeremy Henty

2 1

RFC: removing the search dialog
by 4winter＠informatik.uni-hamburg.de June 11, 2008

June 11, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey :) I hacked up opera (at least I _think_ they do it this way) style search engine handling. I am not too happy with what I did to the config file parser, but it works for now :). The parser is beautiful in its simplicity, but it has its limitations (like not being able to handle dictionaries). I am not sure what I would like to see, but for the moment I'd go with dictionaries and the ability to include other files. This way we could ship some config files (think browser personalities) and the user could include the one he likes best and fine tune the settings in his personal dillorc. I was also unsure about the proper way to inform the user of errors and I believe the reason for this is simply that there is no mechanism to do this properly. I am thinking about using the browser widget to render error pages like most of the mainstream browsers. Any thoughts on this one? Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIN4EQoPmwNWhsaZYRAn93AJ9cVSrlojFB7rcRfDuuysS+iF9MrwCfY5rB Be/P/5ORephsPhmdBcyk+MM= =1rOv -----END PGP SIGNATURE-----

5 7

form.cc: select and option classes
by onepoint＠starurchin.org June 10, 2008

June 10, 2008

Two patches here. The first patch turns DilloHtmlSelect and DilloHtmlOption into classes and implements their constructors and destructors. It also makes DilloHtmlInput::DilloHtmlInput() responsible for creating the select object if necessary (as determined by examining the input type) and removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and DilloHtmlForm::addInput() . The second patch is a small followup that simplifies select handling elsewhere: instead of checking the input type we check if the input's select is non-NULL. Regards, Jeremy Henty

2 1

form.cc: private form methods
by onepoint＠starurchin.org June 9, 2008

June 9, 2008

More C++-ification of form.cc . Most of the static functions implement the internals of DilloHtmlForm::buildQueryUrl() , so let's turn them into private DilloHtmlForm methods since nothing else calls them. The first patch makes the changes, the second moves the definitions around (the diff is a little mangled for some reason but it really does nothing except move things). Regards, Jeremy Henty

2 1

form.cc: make Html_get_input_values a method
by onepoint＠starurchin.org June 8, 2008

June 8, 2008

Changes Html_get_input_values() to DilloHtmlInput::getInputValues() . The first patch makes the change, the second moves the definition to the right place in the file. Regards, Jeremy Henty

2 1

another segfault
by Johannes.Hofmann＠gmx.de June 8, 2008

June 8, 2008

Hi, now I've got some more info on that problem. The buffer on which Html_write_raw is operating (0x285c8000 in this case) is free'd by a_Cache_set_content_type(). I don't understand the details though. Do you have an idea? (gdb) bt #0 dFree (mem=0x285c8000) at dlib.c:59 #1 0x08071ae7 in dStr_free (ds=0x285c0ed0, all=677150720) at dlib.c:291 #2 0x08058ef1 in a_Cache_set_content_type (url=0x28539500, ctype=0x285d2000 "text/html; charset=us-asci i", force=0 '\0') at cache.c:499 #3 0x08061a82 in Html_tag_open_meta (html=0x28689e00, tag=0x285c80a5 "<META http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">\n </HEAD >\n <BODY BGCOLOR=\"#ffffff\">\n <h1>The Mercurial Archives </h1>\n <p>\n You can get <a h ref=\"http://selenic.com"..., tagsize=70) at html.cc:3995 #4 0x080616c4 in Html_write_raw (html=0x28689e00, buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., bufsize=1119, Eof=0) at html.cc:5653 #5 0x08061af1 in DilloHtml::write (this=0x28689e00, Buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., BufSize=675443204, Eof=0) at html.cc:967 #6 0x080621ba in Html_callback (Op=0, Client=0x28549bc0) at html.cc:5883 #7 0x08058433 in Cache_process_queue (entry=0x285d4200) at cache.c:1075 #8 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x285a1000 "HTTP/1.1 200 OK\r\nDate: Sat, 07 Jun 2008 09:35:46 GMT\r\nServer: Apache/1.3.34 (Deb ian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Sat, 07 Jun 2008 08:24:59 GMT\r\n ETag: \"271005-41b5-4"..., buf_size=1440, Url=0x28539800) at cache.c:871 #9 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x285c0340, Data2=0x80eb382) at chain.c:111 #10 0x08074440 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x285490c0, Data1=0x2848d5f0, Data2=0x0) at dpi .c:223 #11 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x2848d5f0, Data2=0x0) at chain.c:111 #12 0x08074d61 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28549ac0, Data1=0x285497c0, Data2=0x0) at IO.c :418 #13 0x08074eee in IO_callback (fd=<value optimized out>, io=0x285497c0) at IO.c:205 #14 0x08074fc7 in IO_fd_read_cb (fd=7, data=0xc) at IO.c:291 #15 0x080c2869 in fltk::wait () #16 0x080c2a19 in fltk::run () #17 0x0804e63d in main (argc=0, argv=0x0) at dillo.cc:125 (gdb) Cheers, Johannes

3 7

RFC: removing the search dialog
by weigelt＠metux.de June 8, 2008

June 8, 2008

* corvid <corvid(a)lavabit.com> schrieb: > > That would be really cool. A few days ago I thought of something > > like that for Gimp: > > > > * all important objects are made accessible via 9P > > * an shell (eg. bash) is extended to support 9P directly > > * an special terminal (eg. via splitvt) runs both shell and > > some status like app > > * user commands can be easily written as shellscript functions > > Yes, in my _real_ dream world, one of the global distributed system > projects would have taken over and we wouldn't have web browsers at all. You might like have a look at Plan9 and how things are done there. We can learn really much from it :) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

1 0

Small html and form cleanups
by onepoint＠starurchin.org June 8, 2008

June 8, 2008

How about some *small* patches for a change? :-) * "a_Html_free()" is only used in html.cc , so change it to "static Html_free()". * The form argument of Html_input _image is unused, so delete it. * The html.cc code that uses debug.h has moved to form.cc , so remove the '#include "debug.h"' and move the '#define DEBUG_LEVEL'. Regards, Jeremy Henty

2 1

patch: image input data submission
by corvid＠lavabit.com June 8, 2008

June 8, 2008

For image inputs, the dillo1 code would send name=value name.x=x-coord name.y=y-coord When I was getting this working for dillo2, I was uncertain whether name=value should be in there (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004085.html) I saw that firefox didn't send it, but I left it alone, since including it shouldn't hurt anything. I later saw that it was clearer in html3.2: "The x and y values of the location clicked are passed to the server: In the submitted data, image fields are included as two name/value pairs. The names are derived by taking the name of the field and appending ".x" for the x value, and ".y" for the y value." and just as clear as day in "web forms 2.0": "Image buttons, during this step, must be handled as if they were two controls, one with the control's name with .x appended, whose value is the x coordinate selected by the user, and the other with the control's name with .y appended, whose value is the y coordinate selected by the user. If the control's name is the empty string (e.g. if the name attribute is omitted) then the names x and y must be used instead." So I'll sneak in a patch before Jeremy gets back to form cleanup. (All that actually changes in buildQueryData() is that the DILLO_HTML_INPUT_IMAGE case goes up above Html_get_input_values() )

2 1

should zlib be required?
by corvid＠lavabit.com June 7, 2008

June 7, 2008

Should zlib be required? I notice that testing for zlib is currently just a part of deciding whether to enable png. I either need to make configure.in require it, or make zlib optional with some ifdefs. As for which, though, I don't have much of an opinion.

4 6

Executing commands via URL
by weigelt＠metux.de June 7, 2008

June 7, 2008

Hi folks, I'd like to use Dillo for an help system and control center on an end-user desktop appliance. Therefore I need it to execute certain commands. But Dillo itself should not fork/exec itself, instead send the commands to some special daemon via an 9P channel. An simple approach could be coding an dpi which just parses the requested URL and sends the actual command to the exec server through 9P. But I have to make absolutely sure that commands can only be sent when coming from certain pages. How can I achieve this ? thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

1 0

Splitting html.cc: common functions, part 1
by onepoint＠starurchin.org June 6, 2008

June 6, 2008

This patch moves some function declarations from html.cc to html_common.hh . It only does *some* of the renaming because the full patch breaks the list's moderation limit. I'll follow up to this message with the rest of the renaming. You may want to batch this patch and the followup together as a single commit. Please comment! Jeremy Henty

3 7

Splitting html.cc: the rest of the form code
by onepoint＠starurchin.org June 6, 2008

June 6, 2008

This is it!. These three patches complete the migration of all the form code to form.cc . They move respectively the receiver class, the input class and the class declarations (which were temporarily put in form.hh ). Now all the details of form handling are in form.cc and form.hh exports an opaque API to the rest of the Html module. Regards, Jeremy Henty

1 0

Splitting html.cc: the form class, part I
by onepoint＠starurchin.org June 6, 2008

June 6, 2008

The next task is to move the implementation of DilloHtmlForm into form.cc . This is a lot of code, so I'm splitting it into several parts. This part moves the constructor, destructor and most of the methods. Regards, Jeremy Henty

1 1

another segfault
by Johannes.Hofmann＠gmx.de June 5, 2008

June 5, 2008

Hi, here is another segfault I get consistently when clicking a certain sequence of links. I have no idea about the cause however. Cheers, Johannes Loaded symbols for /usr/libexec/ld-elf.so.2 Core was generated by `dillo-fltk'. Program terminated with signal 11, Segmentation fault. #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 5707 if (isspace(tag[i])) (gdb) bt #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 #1 0x080617d5 in Html_write_raw (html=0x28560300, buf=0x28481000 <Address 0x28481000 out of bounds>, bufsize=1119, Eof=0) at html.cc:5628 #2 0x08061acd in DilloHtml::write (this=0x28560300, Buf=0x28481000 <Address 0x28481000 out of bounds>, BufSize=0, Eof=0) at html.cc:961 #3 0x08062196 in Html_callback (Op=0, Client=0x284f8fa0) at html.cc:5855 #4 0x08058433 in Cache_process_queue (entry=0x28474d40) at cache.c:1075 #5 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x2854a000 "HTTP/1.1 200 OK\r\nDate: Thu, 05 Jun 2008 20:56:16 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Thu, 05 Jun 2008 16:16:48 GMT\r\nETag: \"271005-41b5-4"..., buf_size=1440, Url=0x284f9c00) at cache.c:871 #6 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x2850f230, Data2=0x80eb382) at chain.c:111 #7 0x08074444 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f40, Data1=0x284f73c0, Data2=0x0) at dpi.c:223 #8 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x284f73c0, Data2=0x0) at chain.c:111 #9 0x08074d65 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f60, Data1=0x284f8f80, Data2=0x0) at IO.c:418 #10 0x08074ef2 in IO_callback (fd=<value optimized out>, io=0x284f8f80) at IO.c:205 #11 0x08074fcb in IO_fd_read_cb (fd=6, data=0xc) at IO.c:291 #12 0x080c286d in fltk::wait () #13 0x080c2a1d in fltk::run () #14 0x0804e63d in main (argc=Cannot access memory at address 0x0

1 0

Splitting html.cc: form parsing I
by onepoint＠starurchin.org June 5, 2008

June 5, 2008

Now we move the form parsing code into form.cc . The 40K posting limit forces me send the patches in two batches. Here's the first lot. Jeremy Henty

1 1

Splitting html.cc: moving stuff into the form source
by onepoint＠starurchin.org June 5, 2008

June 5, 2008

These patches move some declarations into form.hh and the form API into form.cc . Note that the form class declarations will move into form.cc later, for now they must be in form.hh . Regards, Jeremy Henty

1 0

[patch]: replace form::Form and remove form.{cc,hh}
by onepoint＠starurchin.org June 5, 2008

June 5, 2008

The source files dillo2/src/form.{hh,cc} (which define the form::Form class) are modified copies of dw2/test/form.{hh,cc} . Dillo uses almost none of the code in these files. All dillo needs is a Receiver class that wraps a DilloHtmlForm and delegates calls to the event handlers to DilloHtmlForm methods. This patch removes all references to form::Form and form.{hh,cc} . It replaces form::Form with DilloHtmlReceiver. It also moves the event handler code into a DilloHtmlForm method and removes some unnecessary (void *) casting. This simplifies the code that bridges form events to DilloHtmlForm methods. WARNING: developers must run " make maintainer-clean ; ./autogen.sh " after this patch appears in their CVS working directory. This is because automake has to recreate Makefile.in , otherwise the build will try to compile form.cc which no longer works. After this patch is applied you can delete dillo2/src/form.{hh,cc} . Don't delete dw2/test/form.{hh,cc} though! Please comment! Regards, Jeremy Henty

2 9

fltk2 snapshot update
by Johannes.Hofmann＠gmx.de June 4, 2008

June 4, 2008

Hi, at fltk.org there is a new fltk2 snaphot (r6132) available. It contains a bugfix for the weird green artifacts in the FileChooser. I think we should update the download instructions. BTW, shouldn't we point users directly to fltk.org for downloading fltk2? Otherwise people might think that dillo2 needs a modified version of fltk2. Cheers, Johannes

4 6

why is SELECT a block container in Tags[]?
by corvid＠lavabit.com June 2, 2008

June 2, 2008

Why is SELECT a block container rather than an inline container in Tags[]?

2 6

Hooked a decoder for text/plain with charset.
by jcid＠dillo.org June 1, 2008

June 1, 2008

Hi, Just committed this patch. It makes things like: http://separat-lib.narod.ru/master.txt work. -- Cheers Jorge.-

2 8

[patch]: html.cc: DilloHtmlInput::connectTo()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

This implements DilloHtmlInput::connectTo() which is called by DilloHtmlForm::addInput and connects the input to the form. This is another API milestone: now only DilloHtmlForm methods access DilloHtmlForm::form_receiver . We are nearly done with the DilloHtmlForm API, there only a few locations left that directly access DilloHtmlForm data members. Regards,

2 2

[patch]: html.cc: remove DilloHtmlInput::widget
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

It turns out that the embed and widget members of the DilloHtmlInput class are always the same, so we can remove widget. Patch attached. Regards, Jeremy Henty

2 1

[patch]: html.cc: DilloHtmlForm::getRadioInput()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

This refactors code that looks for a radio input with a given name into a new method DilloHtmlForm::getRadioInput() . This marks a DilloHtmlForm API milestone: now only DilloHtmlForm member functions access the inputs data member. Everything else that needs to get an input from a form goes through the API. Regards, Jeremy Henty

2 1

[patch]: html.cc: remove MSG_HTML and rename Html_msg() to DilloHtml::message()
by onepoint＠starurchin.org May 30, 2008

May 30, 2008

Self-explanatory, I hope. This is a useful bit of yak-shaving to prepare for more refactoring of form handling code. The reasons for removing MSG_HTML are: * It doesn't belong in msg.h since it can only work when used in http.cc . * It's a UI function not a debugging function like the other MSG_* so it's misleading for it to look similar to the MSG_* macros. * Using it has no advantage over simply calling the function that it wraps. * It's fragile because it requires html to be in scope and have the right value. Regards, Jeremy Henty

2 1

Re: patch: cache Data allocation
by jcid＠dillo.org May 29, 2008

May 29, 2008

On Thu, May 29, 2008 at 05:51:02PM +0000, corvid wrote: > This is to make my unref()s cleaner. > As it was in the prototype code, I would always unref at IOClose time. > This made the reference count negative for file not found, which I didn't > like. I could've tested for GotHeader, but it seemed more natural to > test for data before unref()ing data. I'd prefer GotHeader because that's what Cache_process_queue() tests for, and thus Data doesn't become an implicit flag. > I think it's all right for me to put that Cache_process_queue(entry) inside > an entry->Data test -- at least I couldn't find anything bad happening. BTW, funny as it may seem, I don't yet know what data unref you're talking about! :-) -- Cheers Jorge.-

2 1

[patch]: simplify a_Html_form_event_handler()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

The a_Html_form_event_handler() function displays an amusing anti-pattern (which I wish I knew the name of) where it's not given enough data and has to go searching for the missing information. Specifically, it gets a pointer to the DilloHtml of the page, but not not the DilloHtmlForm that submitted it, so it has to search the form list of the DilloHtml to find the form. This patch passes the DilloHtmlForm to the handler and adds a pointer from the DilloHtmlForm to the DilloHtml , so the handler can now directly access the form and the html without messing around. Regards, Jeremy Henty

2 3

[patch]: convert Html_submit_form2() to DilloHtmlForm::buildQueryUrl()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

The function Html_submit_form2() does two jobs rolled into one: most of its code creates a url from a DilloHtmlForm and a few lines push the url to a DilloHtml . This patch takes advantage of the fact that Html_submit_form2() is only called from a_Html_form_event_handler() ; it moves the url push out into the caller and the rest of the code into a new method "DilloUrl *DilloHtmlForm::buildQueryUrl()". This separates concerns nicely: the DilloHtmlForm creates the url and a_Html_form_event_handler() pushes it to the DilloHtml . We're getting close to having a proper API for DilloHtmlForm , unfortunately some of the remaining code is very messy. I'll do the rest of the easy stuff and then summarise what's left. Regards, Jeremy Henty

2 1

Previous patches a la camelCase
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

In case Jorge prefers them, here are revised versions of today's patches with camelCased method names. Regards, Jeremy Henty

2 1

[patch]: html.cc: change Html_add_input() to HtmlForm::add_input()
by onepoint＠starurchin.org May 29, 2008

May 29, 2008

This changes the Html_add_input() function to an HtmlForm::add_input() method. As before I'm submitting this as a "change diff" + "move diff" to make it easier to review. Reviewers please tell me if it makes things harder instead! Regards, Jeremy Henty

2 1

[patch]: html.cc: change Html_make_multipart_boundary() to DilloHtmlForm::make_multipart_boundary()
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

More of the same. I'll hold off sending any more patches until these three have been reviewed. (Especially since I just remembered Jorge will probably want to camelCase the method names. D'oh!) Regards, Jeremy Henty

1 0

[patch]: html.cc: rename Html_build_query_data() to DilloHtmlForm::build_query_data()
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

Does what it says on the tin! There's no "move diff" for this one due to declaration order dependencies. I expect the move will happen after the functions that access DilloHtmlInput internals are converted to DilloHtmlInput methods. Regards, Jeremy Henty

1 0

html.cc: convert Html_*_reset functions to methods
by onepoint＠starurchin.org May 28, 2008

May 28, 2008

This changes Html_reset_form() to DilloHtmlForm::reset() and Html_reset_input() to DilloHtmlInput::reset() . It's part of the plan to move code that accesses DilloHtmlForm and DilloHtmlInput internals into methods and make the internals private. The patch is in two parts: the first makes the changes and the second moves the new methods to the right place in the file. If I roll the changes and the move into one then "diff" gets confused and creates an unreadable monster of a patch. I'd recommend feeding the two attachments to patch separately; it might do the right thing given the whole message in one go, but then again it might not. Comments are welcome. There are several other functions in html.cc that are really just methods in disguise and are future targets for the same treatment as Html_reset_form() and Html_reset_input() get here. Regards, Jeremy Henty

2 2

html.cc: small tweak for consistency and debugging
by onepoint＠starurchin.org May 27, 2008

May 27, 2008

This renames a local variable from "size" to "nf". This is consistent with the names of similar local variables elsewhere in the file and also ensures that the _MSG statement will compile if debugging is enabled. Jeremy Henty

1 0

Re: (working) prototype of charset decoding in cache.c
by jcid＠dillo.org May 27, 2008

May 27, 2008

Hi, On Fri, May 02, 2008 at 08:02:14PM +0000, corvid wrote: > I've been playing around with this now and then over the past few months > when I haven't had anything else going on. I've been running on it for > a day or so without incident, but I haven't gone through it with a > fine-toothed comb because I know there will be changes. > > It's 35K, so I realize I'm in little danger of hearing back too quickly :) > Besides, I know you said you have some nbsp thing that needs attention... I've made a second review over the code, and it doesn't look that bad to me. This is, the decoding in cache, even the stuffed cache-entry; if it can be isolated/tidied in the future better. The part that looks inconvenient to me is the charset choosing dialog. I'd prefer Dillo do this automatically. There's no need to try to recognize every charset in the world, but just a few "most used" ones like koi8-r. BTW, UTF-8 has become the preferred solution. The idea is that we can leave space for a expandable function just in case. BTW, there's an improved version of the data guesser in the ftp dpi. Please send me a koi8-r encoded page to test (or just let me know how to find it with google :). IIRC you sent me an explanation message on what this patch was for and remaining issues. I can't find it :(. Please resend it to me. > > There are plenty of issues. Going in order through the diff: > > - *_get_content_type(). I searched for some Russian text files where a > charset is given in the HTTP header. None of them were regarded as > text by the old test for ascii chars. > Maybe the way to go is to have tests for more filetypes and treat > unknown as text. Checking for all possible charsets would be no fun, > anyway. (Tests for more filetypes might be needed for file uploading, > as well.) The problem with "unknown as text" is that some HTTP servers send downloadable files as text. It is quite practical in this case to get a download dialog from dillo, intead of a binary rendering (especially for newbies). That's why the current data guesser is conservative. The data guesser can be improved. e.g. taking ASCCI control characters as a strong indication of a binary, and their absence as a text hint. I can give it a look after you send me the files. > - CacheEntry_t now has a horrifying amount of junk in it. Maybe it > would be good to pull out about half of it into some sort of Data thing. It's stuffed but still understandable. If it can be tidied in a second pass, better. > o TypeSet to be set from Meta or a user dialog. Meta can set it once; > the dialog can set it repeatedly. I'd like to avoid that dialog if possible. > o UTF8Data (LocalData?) that's been translated. cache.c has a lot of > "entry->UTF8Data ? entry->UTF8Data : entry->Data" in it now that > perhaps should be hidden behind something. Yes. > o DataReaders reference count. UTF8Data is destroyed when not needed. > o CharsetDecoder > > - a_Cache_unref_buf, a_Capi_unref_buf, a_Nav_unref_buf all just to > provide notification that the view source window isn't reading it anymore. > Ugh. Not pretty, but tolerable. I'm thinking along the line of getting the core of the patch committed and then polish the rough edges. > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > I don't know whether there's a timing issue with changing decoders > due to a meta tag at the same time that a view source window is being > opened. Yes there is. Simple to solve by allowing view source after parsing the HEAD element only. > (Why content-type and not charset? I find switching to text/plain to > use findtext on the source to be useful.) Sorry, I don't understand the question. > - Decode_charset() no longer free()s its input. This inconsistency would > be an excellent source of bugs, so it would probably be good to make it so > that none of the decoders free input. Yes, this is a must. Consistency should be our goal/horizon/friend/helper. :-) -- Cheers Jorge.-

2 6

[patch]: html.cc: DilloHtmlForm::getCurrentInput()
by onepoint＠starurchin.org May 27, 2008

May 27, 2008

This refactors DilloHtmlForm code into a new "inline DilloHtmlInput *getCurrentInput()" method. It's just like the earlier patch that created DilloHtml::getCurrentForm() . Comments are welcome, although I hope it is uncontroversial. Regards, Jeremy Henty

2 4

an experiment in widget coloring
by corvid＠lavabit.com May 27, 2008

May 27, 2008

I saw a page that reminded me that the matter of when to have light text vs. dark text on widgets was not decided. earlier discussion: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-February/003760.html trimmed-down bit of the page I saw: <form> <table bgcolor="#F8C473"> <tr><td> <input type="submit" value="I can hardly see the text"> </table> </form>

1 0

[patch]: html.cc cleanup: DilloHtml::currentForm()
by onepoint＠starurchin.org May 26, 2008

May 26, 2008

This patch adds a DilloHtml::currentForm() method and uses it to refactor wherever possible. This reduces the number of instances of the "foo->size() - 1" idiom in html.cc from 23 to 13! Regards, Jeremy Henty

3 8

[patch] dw2 memory reduction
by Johannes.Hofmann＠gmx.de May 26, 2008

May 26, 2008

Hi, attached is patch to reduce the memory usage of dw2: * Styles are now reused if they are equal. This brings down the number of Style objects on the mysql page from around 180000 to 23000 and reduces memory usage by about 25M at the cost of an additional HashTable. Maybe the hash table should be part of fltkplatform as the hash tables for Color and Font? There would be even more sharing of styles possible, if x_link would not be part of style. On the other hand about 3M for styles on the huge mysql page is pretty ok. * Size of struct Word is reduced by 4 integers by using shorts. I know that this is questionable, but I think in the case of struct Word that can be allocated a lot it is worth the hassle. Please check whether my assumption that space lengths and word lengths can be stored in shorts are valid in general. * SimpleVector no longer preallocates memory if it's not necessary. This actually saves some megabytes here! With these changes memory usage on the mysql page is 179M here. Cheers, Johannes

3 8

Fuzzing dillo
by 4winter＠informatik.uni-hamburg.de May 26, 2008

May 26, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi :) I was playing around with Michal Zalewskis html fuzzer 'mangle' trying to crash dillo and succeeded :). Furthermore I was able to reduce the ~100k page that was triggering a NULL pointer dereferencing to three tags (see the attached page). Some digging around (html.cc is a monster ^^) revealed that style_attrs.setBorderColor ( Color::createShaded(HT2LT(html), style_attrs.backgroundColor->getColor())); in Html_tag_open_table was failing due to the fact that style_attrs.backgroundColor was NULL. Html_tag_open_select sets the backgroundColor to NULL and this is inherited by the table tag since it's a child of the select tag. Greping through the code shows that there are at least two other functions that set backgroundColor (and color) to NULL (Html_tag_open_input and Html_tag_open_isindex) and twelve locations calling getColor() on either color or backgroundColor. I have no idea how to _properly_ fix this issue. Furthermore I'd suggest to break down html.cc into several files. It is about 6000 lines long (-> hard to dig into) and it takes gcc roughly five seconds to compile on my box. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIOUmmoPmwNWhsaZYRAprIAJ9X9HSzc4Isx+NyFWxlfSFPrwj/VACdF8GD x67scPvD6FCrOezl69NbaHA= =z0iv -----END PGP SIGNATURE-----

4 10

patch: http_proxyuser preference
by corvid＠lavabit.com May 26, 2008

May 26, 2008

After I sent the preferences mail yesterday, I found that I overlooked one. The headers look good, but I have no way to test it for real.

2 1

patch: goodbye to use_oblique and transient_dialogs
by corvid＠lavabit.com May 26, 2008

May 26, 2008

It's nice to get to delete things, and especially preferences, since they have a natural tendency to grow and grow and grow.

2 1

remaining preferences
by corvid＠lavabit.com May 26, 2008

May 26, 2008

# Dicache is where the Decompressed Images are cached (not the original ones). # If you have a lot of memory and a slow CPU, use YES, otherwise use NO use_dicache The code always behaves like use_dicache=NO /* * Unrefs the counter of a dicache entry, and _if_ no DwImage is acessing * this buffer, then we call Dicache_free to do the dirty job. */ void a_Dicache_unref(const DilloUrl *Url, int version) { DICacheEntry *entry; if ((entry = Dicache_get_entry_version(Url, version))) { /*if (--entry->RefCount == 0 && (entry->next || !prefs.use_dicache)) {*/ if (--entry->RefCount == 0) { Dicache_remove(Url, version); } } } Perhaps this was done for a reason. # If you prefer oblique over italic fonts, uncoment next line use_oblique FLTK doesn't know about oblique. I don't know whether anybody cares enough to change that. I don't. # Show tooltip popup for images? # Note: We use the "title" attribute and not "alt". # More info at: http://bugzilla.mozilla.org/show_bug.cgi?id=25537 show_tooltip I did the easy part of tooltips long ago, but I haven't been able to care enough to want to do the fltk part. # Set this to YES, if you want to limit the word wrap width to the vieport # width (may be useful for iPAQ) limit_text_width It doesn't do anything. I don't think it's ever done anything. It sure would be nice if it did something. But I don't have the expertise to change that. # Here you can choose to hide some widgets of the dillo panel... show_menubar Not currently used. Meaningless with the current panel-cycling with right click on the search button (which I imagine is not going to be the permanent way to do that). # Enabling this will restrain OpenUrl and FindText, but may be required # for the ION window manager. transient_dialogs from fltk::Window::child_of(): Tell the system that this window will not have an icon, it will dissappear and reappear when \a parent is iconized or shown, and it is forced to always be above \a parent. On X this is called a "Transient window", and Windows calls this a "overlapping child". \a parent is different than the parent(), which must be zero. (and down in fltk::CreatedWindow::create, there's a if (window->child_of() && window->child_of()->shown()) XSetTransientForHint(xdisplay, x->xid, window->child_of()->i->xid);) If Justus gets rid of the dialogs, obviously the pref can be removed. Enabling this means making our own dialogs for message(), choice(), input(). # When filling forms, our default behaviour is to submit on enterpress, # but only when there's a single text entry (to avoid incomplete submits). # OTOH, if you have to fill the same form lots of times, you may find # useful to keep away from the mouse by forcing enter to submit. enterpress_forces_submit The code currently always submits on enter. I like it that way and didn't realize that it wasn't supposed to.

3 7

[BUG]: Redirect to previous page + Reload crashes
by onepoint＠starurchin.org May 25, 2008

May 25, 2008

Dillo crashes as follows: * Point Dillo at http://starurchin.org:8080/dillo/here * Click the "There" link. Dillo is redirected back to the "Here" page. * Click the "Reload" button. * Dillo crashes inside a_Nav_reload() (nav.c) at the line "if (URL_FLAGS(url) & URL_Post) {" because url is NULL. I noticed this a few weeks ago but only just found a simple way to trigger it. Any ideas why this is happening? Regards, Jeremy Henty

3 6