- Dillo-dev - lists.mailman3.com

Previous patches a la camelCase

by onepoint＠starurchin.org

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

May 28, 2008

[patch]: html.cc: change Html_make_multipart_boundary() to DilloHtmlForm::make_multipart_boundary()

by onepoint＠starurchin.org

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

May 28, 2008

[patch]: html.cc: rename Html_build_query_data() to DilloHtmlForm::build_query_data()

by onepoint＠starurchin.org

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

May 28, 2008

[patch]: html.cc: change Html_add_input() to HtmlForm::add_input()

by onepoint＠starurchin.org

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

May 28, 2008

html.cc: convert Html_*_reset functions to methods

by onepoint＠starurchin.org

On Tue, May 27, 2008 at 02:18:29PM -0400, Jorge Arellano Cid wrote: > On Tue, May 27, 2008 at 05:03:13PM +0100, Jeremy Henty wrote: > > > > 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. > > [...] BTW, here diff made a nice single patch. I might have messed up the cut and paste on the first attempt and moved more code than I intended, which is why I got the monster diff. However I think that splitting up the patch into a change diff and a move diff might be better for reviewers as it gives them a diff that shows exactly what has changed rather than forcing them to manually compare a delete chunk in one place with an add chunk elsewhere. So I might continue splitting up diffs this way, unless you and the other reviewers think it just makes more work. > BUG: Please notice that forms "reset" doesn't reset selection > lists. (it also wasn't working before the patch). to_do_list++; Regards, Jeremy Henty

May 28, 2008

html.cc: convert Html_*_reset functions to methods

by jcid＠dillo.org

On Tue, May 27, 2008 at 05:03:13PM +0100, Jeremy Henty wrote: > > 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. Patch committed. BTW, here diff made a nice single patch. BUG: Please notice that forms "reset" doesn't reset selection lists. (it also wasn't working before the patch). > 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. OK. -- Cheers Jorge.-

May 27, 2008

html.cc: convert Html_*_reset functions to methods

by onepoint＠starurchin.org

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

May 27, 2008

html.cc: small tweak for consistency and debugging

by onepoint＠starurchin.org

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

May 27, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 08:50:19PM +0000, corvid wrote: > Jorge wrote: > > > But I mean it finishes seeing the first head, enables view source, > > > user views the source, and then the charset in the second head causes > > > a repush. Is the parser avoiding that? > > > > Yes, once you are IN_BODY, HEAD can't be re-opened, > > and META doesn't work outside HEAD. > > But if I give it a page containing > > <html> > <head> <title>first head</title> </head> > <body> body </body> > <head> > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > </head> > </html> > > I get > > .. > META Content-Type changes charset to: iso-8859-1 > .. > META Content-Type gave charset as: iso-8859-1 > a_Nav_expect_done: repush! That's a corner case bug. It passed because you closed BODY explicitly (i.e. if you remove the </body> tag, the fault is caught. Patch committed. > > I'd prefer to try the dpi before optimizing. > > I don't know dpis, so to me that's the difficult way... Then let's focus in the decoder. -- Cheers Jorge.-

May 27, 2008

[patch]: html.cc: DilloHtmlInput class: WAS: DilloHtmlForm::getCurrentInput()

by jcid＠dillo.org

On Tue, May 27, 2008 at 10:43:51AM +0100, Jeremy Henty wrote: > > This turns DilloHtmlInput into a class and adds a constructor and > destructor to manage its data members. Note that > DilloHtmlForm::inputs is now a vector of pointers instead of structs. > This is consistent with the earlier change to DilloHtml::forms . OK. Committed. -- Cheers Jorge.-

May 27, 2008

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by jcid＠dillo.org

On Tue, May 27, 2008 at 01:26:26AM +0100, Jeremy Henty wrote: > > Except that I didn't include the patch. Here it is. Committed. -- Cheers Jorge.-

May 27, 2008

[patch]: html.cc: DilloHtmlInput class: WAS: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

This turns DilloHtmlInput into a class and adds a constructor and destructor to manage its data members. Note that DilloHtmlForm::inputs is now a vector of pointers instead of structs. This is consistent with the earlier change to DilloHtml::forms . I think the next task is to move code that accesses DilloHtmlInput internals into DilloHtmlInput methods. In particular, if we can make the type member private we can consider replacing it in favour of a class hierarchy. Comments are welcome, Jeremy Henty

May 27, 2008

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

Except that I didn't include the patch. Here it is. Jeremy Henty

May 27, 2008

an experiment in widget coloring

by corvid＠lavabit.com

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>

May 27, 2008

[patch]: html.cc: DilloHtmlForm::getCurrentInput()

by onepoint＠starurchin.org

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

May 27, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

> corvid wrote: > > > I just remembered that inputs don't have to be in forms according to > > the spec, > > Ouch, yes. I guess this is because JavaScript can read inputs > whether or not they are inside a form? Yes, although I ran into it when I was looking up information about inputs. The pages liked to show examples of them, but dillo would give me bug meter messages instead.

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > > But I mean it finishes seeing the first head, enables view source, > > user views the source, and then the charset in the second head causes > > a repush. Is the parser avoiding that? > > Yes, once you are IN_BODY, HEAD can't be re-opened, > and META doesn't work outside HEAD. But if I give it a page containing <html> <head> <title>first head</title> </head> <body> body </body> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> </head> </html> I get .. META Content-Type changes charset to: iso-8859-1 .. META Content-Type gave charset as: iso-8859-1 a_Nav_expect_done: repush! > I'd prefer to try the dpi before optimizing. I don't know dpis, so to me that's the difficult way...

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by jcid＠dillo.org

On Mon, May 26, 2008 at 09:07:46PM +0100, Jeremy Henty wrote: > > A revised version of the previous patch that applies cleanly against > the latest CVS. No other changes. Committed. -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

corvid wrote: > I just remembered that inputs don't have to be in forms according to > the spec, Ouch, yes. I guess this is because JavaScript can read inputs whether or not they are inside a form? > ... so maybe it won't be as easy to move so much to form.cc (unless > form.cc is given an html-ui-widgety general sort of name...) I think the real obstacle is circular data structures and dependencies. DilloHtml objects have pointers to DilloHtmlForm objects, which have pointers to ::form::Form objects which in turn depend on DilloHtml objects. So the code can't be split up as it stands. My tentative solution is to factor things through APIs that treat pointers as black boxes. For example, "delete form_ptr;", which requires the DilloHtmlForm class definition, could be wrapped inside a function "Html_form_delete (DilloHtmlForm *form_ptr);", which only requires the declaration "class DilloHtmlForm;". I'm sure it can be done but it may be too messy to be worth doing. At the moment I am doing cleanups that I think are clearly worth doing anyway and hoping that they will also help us to split up html.cc in a useful way. Regards, Jeremy Henty

May 26, 2008

[patch]: DilloHtmlForm class: WAS: Re: [Dillo-dev] [patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

A revised version of the previous patch that applies cleanly against the latest CVS. No other changes. Jeremy Henty

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 07:31:14PM +0000, corvid wrote: > Jorge wrote: > > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > > [...] > > > > > - 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. > > > > > > Do you think badly-formed html with, e.g., > > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > > is worth worrying about? > > > > This is already handled in the parser. > > But I mean it finishes seeing the first head, enables view source, > user views the source, and then the charset in the second head causes > a repush. Is the parser avoiding that? Yes, once you are IN_BODY, HEAD can't be re-opened, and META doesn't work outside HEAD. > > But now that you mention this, we have to be careful with > > reload. It deletes the entry from the cache before making the > > request. > > > > A simple solution is just to close the view-source window in > > this corner case. > > Ah, yes. Stupid corner cases! :) > > > I was saying that I was pushing around content-type instead of charset > > > because I liked changing it to text/plain in the dialog. > > > If there's no dialog, maybe I'll go back to charset. > > > > > > "View source" as a bw is not a bad idea. It reuses code and > > adds findtext for free, but currently loses the line numbers. > > (which match nicely with the bug meter). > > > > This is a separate problem. > > > > One way to have both features in "View source" is with a dpi > > that gets the source from dillo and sends back an html page. The > > simple way is to prefix line numbers and wrap with PRE. > > > > It can be sent with a no-cache directive, or removed from cache > > upon window close. > > > > The problem of sending back and forth a huge page may be not > > as bad as it looks because huge pages are seldom inspected for > > source from a browser, and it can be handled anyway. > > Maybe adding a callback that stuffs in line numbers before going into > the regular plain callback would work and be tiny. > a_Capi_open_url(Web, our_special_callback, ...) > Oh well, I realize it's premature to dream too hard about > this at this point :) I'd prefer to try the dpi before optimizing. Having one path helps a lot with... Oh, I already gave that lines. ;) The ones that read the paper, please raise your hands. :-) -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

I just remembered that inputs don't have to be in forms according to the spec, so maybe it won't be as easy to move so much to form.cc (unless form.cc is given an html-ui-widgety general sort of name...)

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > [...] > > > > - 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. > > > > Do you think badly-formed html with, e.g., > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > is worth worrying about? > > This is already handled in the parser. But I mean it finishes seeing the first head, enables view source, user views the source, and then the charset in the second head causes a repush. Is the parser avoiding that? > But now that you mention this, we have to be careful with > reload. It deletes the entry from the cache before making the > request. > > A simple solution is just to close the view-source window in > this corner case. Ah, yes. Stupid corner cases! > > I was saying that I was pushing around content-type instead of charset > > because I liked changing it to text/plain in the dialog. > > If there's no dialog, maybe I'll go back to charset. > > > "View source" as a bw is not a bad idea. It reuses code and > adds findtext for free, but currently loses the line numbers. > (which match nicely with the bug meter). > > This is a separate problem. > > One way to have both features in "View source" is with a dpi > that gets the source from dillo and sends back an html page. The > simple way is to prefix line numbers and wrap with PRE. > > It can be sent with a no-cache directive, or removed from cache > upon window close. > > The problem of sending back and forth a huge page may be not > as bad as it looks because huge pages are seldom inspected for > source from a browser, and it can be handled anyway. Maybe adding a callback that stuffs in line numbers before going into the regular plain callback would work and be tiny. a_Capi_open_url(Web, our_special_callback, ...) Oh well, I realize it's premature to dream too hard about this at this point :)

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

On Mon, May 26, 2008 at 02:57:09PM -0400, Jorge Arellano Cid wrote: > Committed as: > > inline DilloHtmlForm *getCurrentForm (); Cool, but that name change will break the second patch I just submitted. :-( I'll resubmit a fixed version. Regards, Jeremy Henty

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by jcid＠dillo.org

On Mon, May 26, 2008 at 04:24:37PM +0100, Jeremy Henty wrote: > > 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! Committed as: inline DilloHtmlForm *getCurrentForm (); -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

Here's the next patch: it turns DilloHtmlForm into a class with a constructor and destructor to manage the data members. It depends on the previous patch. Note that this changes DilloHtml slightly to manage DilloHtmlForm pointers instead of DilloHtmlForm structs. This improves consistency as DilloHtml already manages DilloLinkImage and DilloUrl objects by pointers. Next I plan to refactor common code into DilloHtmlForm members just as I did with DilloHtml, then address DilloHtmlInput, DilloHtmlSelect and DilloHtmlOption in the same way. I expect this to be straightforward. Then we will be ready to consider moving the form handling code to a separate file and replacing the DilloHtmlInput case statements with virtual methods. This will probably be trickier and need some more planning. (I already tried once to move out the form handling code and gave up because it is so entangled. Hopefully the above cleanups will make it feasible.) Please comment on the patch and the plan, especially if you have an interest in how html.cc should be cleaned up. Regards, Jeremy Henty

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > [...] > > > - 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. > > Do you think badly-formed html with, e.g., > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > is worth worrying about? This is already handled in the parser. But now that you mention this, we have to be careful with reload. It deletes the entry from the cache before making the request. A simple solution is just to close the view-source window in this corner case. > > > (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. > > I was saying that I was pushing around content-type instead of charset > because I liked changing it to text/plain in the dialog. > If there's no dialog, maybe I'll go back to charset. "View source" as a bw is not a bad idea. It reuses code and adds findtext for free, but currently loses the line numbers. (which match nicely with the bug meter). This is a separate problem. One way to have both features in "View source" is with a dpi that gets the source from dillo and sends back an html page. The simple way is to prefix line numbers and wrap with PRE. It can be sent with a no-cache directive, or removed from cache upon window close. The problem of sending back and forth a huge page may be not as bad as it looks because huge pages are seldom inspected for source from a browser, and it can be handled anyway. -- Cheers Jorge.-

May 26, 2008

[patch] dw2 memory reduction

by joerg.sonnenberger＠web.de

On Mon, May 26, 2008 at 05:01:34PM +0200, Johannes Hofmann wrote: > > On the very long mysql page, addWord is called 1192256 times. But > > due to the allocation in 2^n steps in SimpleVector memory for > > some more of them could be allocated > > structs on 32bit systems are 8 byte aligned. struct Word with > > Argh, structs are 4byte aligned of course! On most sane architectures a structshave the same alignment as the strictest type in it. There's one important exception -- ARM, where the minimal alignment is 16 Byte (IIRC). Joerg

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

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

May 26, 2008

[patch] dw2 memory reduction

by Johannes.Hofmann＠gmx.de

On Sun, May 25, 2008 at 06:47:11PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 09:12:11AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 10:08:12AM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Sat, May 24, 2008 at 04:39:42PM -0400, Jorge Arellano Cid wrote: > > > > On Sat, May 24, 2008 at 02:58:08PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached is patch to reduce the memory usage of dw2: > > > > > > > > Excellent! > > > > (AFAIU this is near 30% memory usage reduction in dw2) > > > > > > > > Committed. > > > > > > > > > > > > > > * 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. > > > > > > > > It looks OK at first sight, but to be sure it'd be good to know > > > > what happens when the limit is surpassed. > > > > > > Just tried it on a page with 40000 char long word. With short for > > > hlStart/hlEnd, selection is - obviously - no longer possible. > > > That's clearly a regression. > > > Please revert with attached patch. > > > > A max of 32K for a single word, looks quite reasonable to me. > > I meant, if the browser doesn't crash, and fails gracefully, why > > not. > > > > BTW, it can be extended to 64K with unsigned, by using 65535 as > > sentinel value (instead of -1), but again, is it worth? > > > > It'd be good to know how much "struct Word" is reduced in size > > (after compiler alignment), and how much it impacts overall > > memory usage. I mean if struct word is reduced 20% and that > > yields a 4% overall memory reduction, it may be not worth > > complicating the data type. > > > > OTOH, ... > > On the very long mysql page, addWord is called 1192256 times. But > due to the allocation in 2^n steps in SimpleVector memory for > some more of them could be allocated > structs on 32bit systems are 8 byte aligned. struct Word with Argh, structs are 4byte aligned of course! Cheers, Johannes

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > 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. hurray! > 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. For one thing, I was thinking of a site I knew of where they had a Russian forum and the message board was too limited to deal with it, so they told people to change each page in that part to windows-1251 or something like that. But okay. That's obviously not any sort of fundamental requirement. (And because I liked changing to text/plain to have source in a proper bw.) > 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 :). Here's one that's apparently about 0.7.0: http://gazette.linux.ru.net/lg79/arndt.html > 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. Oh, it was just...let's see... "> BTW, please explain what is/are the main point(s) of it. After > reading the comment it was a bit scary to apply. :-o It's not for applying. It's "here's what I was able to come up with to get encoding translation for page source and plain text, but there are obviously issues, so I need suggestions for... how to do what needs to be done in the most dillolike manner possible" or... or something like that..." > > 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. Quite true. > 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. Do you think badly-formed html with, e.g., <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> is worth worrying about? > > (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. I was saying that I was pushing around content-type instead of charset because I liked changing it to text/plain in the dialog. If there's no dialog, maybe I'll go back to charset. > > - 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. :-)

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

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.-

May 26, 2008

Fuzzing dillo

by onepoint＠starurchin.org

On Mon, May 26, 2008 at 08:49:09AM -0400, Jorge Arellano Cid wrote: > Corvid has been working around forms lately so please try to > coordinate ideas with him OK. > > There's a lot of cut-and-paste code like "foo->get (foo->size () - > > 1)". Adding getLast() methods to some lout classes and using them > > wherever possible would remove a lot of clutter. > > OK. OK, that's next on the TODO. > Just beware of not converting the "horrible case code" into > "horrible virtual method subclassing". :-) To be honest I don't think I can promise that it will be worth doing until I have a go, I am just optimistic enough to want to have a go. > FLTK2 does this quite nicely with the virtual handle() method. Yes, that's a good model. I guess the analogy would be for the Input classes to have virtual update_form_from_html() and form_values() methods. There problem with creating Input objects as there is no such thing as a virtual constructor or virtual class method. So some case code might remain, but it would be hidden in the class API and the switch would simply select which derived class constructor to call. That's not so bad. Regards, Jeremy Henty

May 26, 2008

patch: http_proxyuser preference

by jcid＠dillo.org

On Sun, May 25, 2008 at 06:44:22PM +0000, corvid wrote: > 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. Committed. (better to have it there than to leave it out waiting for testing). -- Cheers Jorge.-

May 26, 2008

Fuzzing dillo

by jcid＠dillo.org

On Sun, May 25, 2008 at 05:13:13PM +0100, Jeremy Henty wrote: > On Sun, May 25, 2008 at 10:31:23AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 01:12:38PM +0200, Justus Winter wrote: > > > > Furthermore I'd suggest to break down html.cc into several files. > > > > The hard part is a good choice on what to separate. ;) > > I suggest splitting out everything that handles forms and form > elements. That's a fair amount of code that represents a reasonably > self-contained chunk. > > The forms code can also be be cleaned up in a few ways. It looks like you have a good set of ideas to start. Corvid has been working around forms lately so please try to coordinate ideas with him > There's a lot of cut-and-paste code like "foo->get (foo->size () - > 1)". Adding getLast() methods to some lout classes and using them > wherever possible would remove a lot of clutter. OK. > html.cc looks like a C file that was subsequently converted to C++ > because it makes little use of C++. html.cc is a C file that was subsequently converted to C++! :-) > If DilloHtmlForm and > DilloHtmlInput were given constructors > and destructors and managed > with new and delete then lots of allocation/deallocation code would be > neatly factored out instead of sitting inline with all the other > logic. OK 2. > The type element of DilloHtmlInput leads to much horrible case code. > If DilloHtmlInput were an abstract class and the different Input types > were subclasses then all the type-dependent code could go into virtual > methods. This would break up the huge case statements that make much > of this code hard to follow. > > I'll propose patches if people are positive about these suggestions. BTW: > [corvid wrote:] > It's at least definitely worth trying, I think. Just beware of not converting the "horrible case code" into "horrible virtual method subclassing". :-) FLTK2 does this quite nicely with the virtual handle() method. This is IMHO remarkable because the underlying event handling model is certainly complex, but the abstraction for it attains simplicity at the widget level. -- Cheers Jorge.-

May 26, 2008

Fuzzing dillo

by corvid＠lavabit.com

Jeremy wrote: > html.cc looks like a C file that was subsequently converted to C++ > because it makes little use of C++. If DilloHtmlForm and > DilloHtmlInput were given constructors and destructors and managed > with new and delete then lots of allocation/deallocation code would be > neatly factored out instead of sitting inline with all the other > logic. > > The type element of DilloHtmlInput leads to much horrible case code. > If DilloHtmlInput were an abstract class and the different Input types > were subclasses then all the type-dependent code could go into virtual > methods. This would break up the huge case statements that make much > of this code hard to follow. It's at least definitely worth trying, I think.

May 26, 2008

patch: goodbye to use_oblique and transient_dialogs

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:19:05PM +0000, corvid wrote: > It's nice to get to delete things, and especially preferences, > since they have a natural tendency to grow and grow and grow. Committed. -- Cheers Jorge.-

May 26, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:32:02PM +0000, corvid wrote: > Jorge wrote: > > On Sat, May 24, 2008 at 07:28:47PM +0000, corvid wrote: > > > # 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. > > > > For instance: Some times HTML pages for mailing lists render > > one looong line for a message. The MUA packs the message as a > > single line and the mail2html filter wraps it with PRE. AFAIR the > > SPEC said original formatting was to be honoured in PRE, but > > browsers, in practice, tend to wrap it. Sometimes you need one > > behaviour and then another. > > Are you saying that it does this, or that the intention is for it to do this? The intention is for it to do this. -- Cheers Jorge.-

May 26, 2008

remaining preferences

by corvid＠lavabit.com

Jorge wrote: > On Sat, May 24, 2008 at 07:28:47PM +0000, corvid wrote: > > # 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. > > For instance: Some times HTML pages for mailing lists render > one looong line for a message. The MUA packs the message as a > single line and the mail2html filter wraps it with PRE. AFAIR the > SPEC said original formatting was to be honoured in PRE, but > browsers, in practice, tend to wrap it. Sometimes you need one > behaviour and then another. Are you saying that it does this, or that the intention is for it to do this?

May 25, 2008

patch: goodbye to use_oblique and transient_dialogs

by corvid＠lavabit.com

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

May 25, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:24:58PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 10:51:47AM -0400, Jorge Arellano Cid wrote: > > <snip> > > > > > Somebody using ION may check this. > > > > Works ok as it is. The dialog windows are placed over the bottom of > the main window. A bit like the new search bar. A quite nice concept > actually. > So I think the preference option can safely be removed. Great. Patch is welcomed! :-) -- Cheers Jorge.-

May 25, 2008

Fuzzing dillo

by jcid＠dillo.org

On Sun, May 25, 2008 at 08:14:29PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 01:12:38PM +0200, Justus Winter wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi :) > >> > >> I was playing around with Michal Zalewskis html fuzzer 'mangle' trying > >> to crash dillo and succeeded :). > > > > Good. > > > > It's no surprise because dillo2 needs a careful review of > > behaviour when facing strange/malicious values. Obviously this > > phase was procrastinated until basic functionality was completed. > > > > For instance, most probably you'll get to crash dillo2 by > > passing it some negative values in attributes. The problem of > > being robust when parsing garbage or malicious code needs a > > general strategy. > > Are you saying that it is too early to locate problems this way? No! It was too early, now dillo2 has almost all dillo1 had and more. Now it's a good time. What I meant is that a general strategy for these cases is better than a case by case approach. > The > process of finding problems using a fuzzer and generating minimal > testcases that trigger the problem is mostly automatic and I could > script the last bits that do require manual intervention with ease. > > In case these bug reports are useful at this point, here is another one: > > In file html.cc, function Html_tag_close_select: > > int size = input->select->options->size (); > > fails since input->select is NULL. The html fragment that triggers this > fault is attached. > <HEAD><FORM><SELECT><TEXTAREA> This is the same non-authorized element inside SELECT. It can be catched with the solution described in my last post. It'd be good to have the test cases. Go ahead. -- Cheers Jorge.-

May 25, 2008

[BUG]: Redirect to previous page + Reload crashes

by jcid＠dillo.org

On Sat, May 24, 2008 at 03:22:10AM +0000, corvid wrote: > Jeremy wrote: > > 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? > > The problem went away when I tried the attached change, > but I may be treating the symptom rather than the disease. > > It must not be the result of a very recent change, because I > have a dillo from April 8 that crashes doing this. > > diff -pur dillo2/src/nav.c dillo2-cur/src/nav.c > --- dillo2/src/nav.c 2008-05-10 20:02:22.000000000 +0000 > +++ dillo2-cur/src/nav.c 2008-05-24 03:03:50.000000000 +0000 > @@ -185,6 +185,8 @@ static void Nav_stack_clean(BrowserWindo > void *data = dList_nth_data (bw->nav_stack, i - 1); > dList_remove_fast (bw->nav_stack, data); > dFree(data); > + if (bw->nav_stack_ptr >= a_Nav_stack_size(bw)) > + bw->nav_stack_ptr = a_Nav_stack_size(bw) - 1; > } > } > Committed. -- Cheers Jorge.-

May 25, 2008

patch: Re: [Dillo-dev] Fuzzing dillo

by jcid＠dillo.org

On Sun, May 25, 2008 at 02:41:32PM +0000, corvid wrote: > Justus wrote: > > 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. > > I doubt I realized you can try to put things like tables inside selects > back when I wrote that. > > Maybe Jorge will know something easy and general that can be done based > on parse modes to keep dillo from wasting its time calling things like > Html_tag_open_table that aren't going to be displayed anyway, but the > attached patch at least fixes the crash. SELECT can be closed in Html_stack_cleanup_at_open(). SELECT can contain OPTGROUP and OPTION. It would be good to consider the other cases before making a patch. -- Cheers Jorge.-

May 25, 2008

remaining preferences

by jcid＠dillo.org

On Sun, May 25, 2008 at 07:02:53PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 10:51:47AM -0400, Jorge Arellano Cid wrote: > > <snip> > > > > > > # 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(). > > > > Somebody using ION may check this. > > Just searched my email. I had requested that feature some time ago - > well, it was Nov 2001 ;-) > I no longer use ion, but I will check how it works with current > dillo. The file dialogs are the only that will stay, right? We have choice5, message and maybe another. If ION works OK with FLTK2, it's OK to remove the preference. If not, I wouldn't assign high priority on it. -- Cheers Jorge.-

May 25, 2008

[patch] dw2 memory reduction

by jcid＠dillo.org

On Sun, May 25, 2008 at 06:47:11PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 09:12:11AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 10:08:12AM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Sat, May 24, 2008 at 04:39:42PM -0400, Jorge Arellano Cid wrote: > > > > On Sat, May 24, 2008 at 02:58:08PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached is patch to reduce the memory usage of dw2: > > > > > > > > Excellent! > > > > (AFAIU this is near 30% memory usage reduction in dw2) > > > > > > > > Committed. > > > > > > > > > > > > > > * 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. > > > > > > > > It looks OK at first sight, but to be sure it'd be good to know > > > > what happens when the limit is surpassed. > > > > > > Just tried it on a page with 40000 char long word. With short for > > > hlStart/hlEnd, selection is - obviously - no longer possible. > > > That's clearly a regression. > > > Please revert with attached patch. > > > > A max of 32K for a single word, looks quite reasonable to me. > > I meant, if the browser doesn't crash, and fails gracefully, why > > not. > > > > BTW, it can be extended to 64K with unsigned, by using 65535 as > > sentinel value (instead of -1), but again, is it worth? > > > > It'd be good to know how much "struct Word" is reduced in size > > (after compiler alignment), and how much it impacts overall > > memory usage. I mean if struct word is reduced 20% and that > > yields a 4% overall memory reduction, it may be not worth > > complicating the data type. > > > > OTOH, ... > > On the very long mysql page, addWord is called 1192256 times. But > due to the allocation in 2^n steps in SimpleVector memory for > some more of them could be allocated > structs on 32bit systems are 8 byte aligned. struct Word with > highlight stuff as int is 48 byte. With short it's 40 byte. > On the mysql page I observe a total memory reduction of about 9M by > using short's for the highlight stuff. > > Apart from the highlight stuff dillo can handle those long words > just fine. So we would add this restriction just to save 9M of > memory on this rather extreme page. > > I would keep int's for now and try to get hlStart and hlEnd out of > struct Word and in Textblock which would bring down struct Word to > 32 bytes - hopefully without any restrictions. OK, patch reverted. Sorry for asking for this important but boring-to-collect data. :) Let's see, if it was 250MB with the old scheme, down to 225M with the style reuse, these shorts are roughly a 4% memory reduction. -- Cheers Jorge.-

May 25, 2008

Fuzzing dillo

by corvid＠lavabit.com

Justus wrote: > Jorge Arellano Cid wrote: > > The problem of > > being robust when parsing garbage or malicious code needs a > > general strategy. Certainly testing flags all the time is very inadequate when the spec has it as, for example, <!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> (i.e., don't put anything in a select except optgroup or option)... > In case these bug reports are useful at this point, here is another one: > > In file html.cc, function Html_tag_close_select: > > int size = input->select->options->size (); > > fails since input->select is NULL. The html fragment that triggers this > fault is attached. ..but since flags are what there is at the moment, here's a patch.

May 25, 2008

Q: why does Nav_stack_clean() free the data and Nav_stack_truncate() not?

by jcid＠dillo.org

On Sun, May 25, 2008 at 04:39:46PM +0100, Jeremy Henty wrote: > On Sun, May 25, 2008 at 09:31:30AM -0400, Jorge Arellano Cid wrote: > > > Hi Jeremy, > > > > Nav_stack_truncate() and Nav_stack_insert() are ad-hoc > > bindings. They're called just in one place of the code. They're > > not clean well-defined functions of an ADT. > > > > This is "your" mistake. :-) > > I'll cheerfully abandon my expectations of consistency. :-) But what > about memory[1]? Doesn't it leak when Nav_stack_truncate() shrinks > bw->nav_stack ? It seems to me that Nav_stack_truncate() should free > all those pointers (and therefore Nav_stack_insert() shouldn't free > anything). I'll supply a patch if you agree. Yes it leaks. (a_Nav_free is incomplete BTW). Patch committed, plus the 's/insert/append/' patch. > > The nav.c module is asking for a clean ADT, and if you can work on > > it, it's certainly welcomed. > > Then I hope people will review the patch I sent to the discussion with > corvid about the Redirect/Reload crash bug, which is all about the > handling of the navigation stack. > > > BTW, if it's to be rewritten it'd be good to have the TABs > > interface in mind. > > Oh noes, you have spotted my hidden agenda! :-) I was indeed thinking > that if I got my head around this it would prepare me for looking at > tabs. > > > This is, if we end with a clean ADT or object, we could have an > > array of them, one for each tab, and switch freely among navigation > > stacks. > > As a first step, maybe we could modify uicmd.cc to indirect though a > new BrowserWindowSet object. The callbacks would be changed to look > up the current BrowserWindow of the BrowserWindowSet . Initially the > BrowserWindowSet could be a stub that managed a single BrowserWindow , > later it could wrap an array of BrowserWindows . It can be done in several ways. The design needs to consider at least front/background TAB loading and async events. e.g. idle functions, cache updates, messages. -- Cheers Jorge.-

May 25, 2008

patch: http_proxyuser preference

by corvid＠lavabit.com

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.

May 25, 2008

remaining preferences

by Johannes.Hofmann＠gmx.de

On Sun, May 25, 2008 at 10:51:47AM -0400, Jorge Arellano Cid wrote: <snip> > > Somebody using ION may check this. > Works ok as it is. The dialog windows are placed over the bottom of the main window. A bit like the new search bar. A quite nice concept actually. So I think the preference option can safely be removed. Cheers, Johannes

May 25, 2008