- Dillo-dev - lists.mailman3.com

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

Q: why does Nav_stack_clean() free the data and Nav_stack_truncate() not?
by onepoint＠starurchin.org May 25, 2008

May 25, 2008

While reviewing nav.c to figure out the reload crash bug I noticed something that seems inconsistent: both Nav_stack_truncate() and Nav_stack_clean() remove items from the navigation stack, yet Nav_stack_truncate() does not free the data it removes and Nav_stack_clean() does. Is this a bug? If not, what haven't I understood? Regards, Jeremy Henty

2 3

Profiling works!
by onepoint＠starurchin.org May 24, 2008

May 24, 2008

I added -pg to LDFLAGS, CFLAGS and CXXFLAGS and dillo generated a nice gmon.prof ! However, it puts it in /tmp (perhaps that's why it didn't seem to be working). Dillo also dumps its core to /tmp when it crashes, perhaps for the same reason? Regards, Jeremy Henty

2 2

patch: trim Local_Buf
by corvid＠lavabit.com May 24, 2008

May 24, 2008

3 2

Uncluttering dillo, part II: the findbar
by 4winter＠informatik.uni-hamburg.de May 24, 2008

May 24, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) attached is a patch that transforms dillos find in page dialog box into a firefox style toolbar. There are some issues that I cannot put my finger on... see the comments in the event handler. Maybe there's some magic about fltks event model that I did not fully understand... then again it might be fltks fault. Anyway, I'd be happy for some hints. Jorge, could you update your coding conventions with respect to c++ specific language features? Cheers, 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 iD8DBQFIM0pmoPmwNWhsaZYRAi1VAJwO/e+JWmCoMsjOF/hYuF4X1DUOWwCePB96 +X++Veu0Gyv854m0TxSwI7Q= =rc5Z -----END PGP SIGNATURE-----

4 9

memory statistics
by Johannes.Hofmann＠gmx.de May 23, 2008

May 23, 2008

Hi, to see which part of dillo consumes which amount of memory, I hacked together a version of dlib.c that counts memory that was allocated via dMalloc(). A malloc_tag allows to assign the mallocs to specific parts in the code. In the patch below I use malloc_tag = 1 for cache stuff, malloc_tag = 2 for text strings that are passed dw2 and malloc_tag = 0 for everything else. It's fun to see how memory get's allocated and free'd while loading. Here is the output once the huge mysql manual page is loaded: ====> malloc size 5185114 26967623 6602392 0 So that's 6M for text strings, 26M cache and 5M other. Of course there is also all the dw2 stuff that is not taken into account here. BTW, textblock delete's the text strings that are allocated using malloc(). That's not allowed and might cause unexpected behaviour on some platforms. Cheers, Johannes

3 10

patch: free parse data
by corvid＠lavabit.com May 23, 2008

May 23, 2008

Johannes had suggested freeing Local_Buf when parsing was completed...

2 1

RFC: human interface guidelines
by 4winter＠informatik.uni-hamburg.de May 21, 2008

May 21, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) I was thinking about improving the dillo experience by adding some functionality / shortcuts people have come to expect. But what people expect is influenced by their background, their choice of desktop environment and platform. We could pick one / some user interface guideline(s) ([1] lists some) and try to adhere to it / them. Or we could pick one popular browser and copy its 'feel'. Attached are two patches mapping 'reload' to F5 and 'help' to F1. Let me know what you think of them and the whole interface thing. Justus 1: http://en.wikipedia.org/wiki/Human_Interface_Guidelines - -- 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 iD8DBQFIM0jvoPmwNWhsaZYRAveJAJ9ROk+E0VWLzK6G99qcTlpNjeB5igCeJ7r9 Grz4wtWQ+BIEbWrIY8PDCFg= =JnX2 -----END PGP SIGNATURE-----

2 1

[patch] minor memory reduction
by Johannes.Hofmann＠gmx.de May 21, 2008

May 21, 2008

Hi, attached is a small patch to improve memory usage. It creates a single word for a sequence of spaces in PRE mode instead of one word per character. The second part is just a minor simplification. Cheers, Johannes

2 4

Uncluttering dillos UI - getting rid of the dialog boxes
by 4winter＠informatik.uni-hamburg.de May 21, 2008

May 21, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone :) somewhere deep inside the "Future of Dillo" monster thread I suggested to get rid of the location dialog box but Johannes pointed out that this breaks the fullscreen mode. So, here is my proposed solution: * on ctrl-l: focus location bar * if in fullscreen mode: temporarily show toolbars until the user pressed enter I am not familiar with the fltk event model, so I just hijacked the existing event handler which works reasonably well. It would be nice to also capture any "on-blur" events, but I could use some hints (the fltk2 documentation only mentions 6 WHEN_* events, though some googling suggests that there might be UNFOCUS events... uh?). Anyway, the patch is attached. let me know what you think. 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 iD8DBQFILd5xoPmwNWhsaZYRApqEAJ9glSSkR3Q9oU0BmmUf9/ErG/ItfwCfVs5M asgEwaQAMk4ggsfzO2toTc0= =MHCi -----END PGP SIGNATURE-----

3 10