- Dillo-dev - lists.mailman3.com

name/id bug

by corvid＠lavabit.com

<a name="a"></a> <p id="p"></p> <p> <a name="same" id="same"></a> gives HTML warning: line 2, 'id' and 'name' attribute of <a> tag differ HTML warning: line 4, Anchor names must be unique within the document Dillo would seem to be unhappy now that the id attr is checked before open_a checks the name attr -- but then it looks like the move was made in October (a88b4a31cb7a) and I have a dillo around from roughly Dec. 22 that does not have a problem with this. In any case, I don't know whether there are styleEngine issues with just sticking the id check back after the open.

Feb. 6, 2009

RE: Free HG performance

by dillo-dev＠toykeeper.net

* Halbersma, Christopher <CHalbersma.12(a)westminster-mo.edu> wrote: > Souceforge always seemed pretty good at hosting open souce > projects. Of course I could be wrong there. It used to be The Place for hosting open projects, years ago... but its service and policies have been slowly declining while better alternatives popped up. The other services I've seen mentioned so far are FreeHG, BitBucket, Savannah, and Launchpad. FreeHG hosts Mercurial branches. It sounds like it's not reliable though, and doesn't really do anything else. BitBucket provides Mercurial hosting, bug tracking, and a wiki. I haven't found more than a summary about it. Savannah was born from an old open-source version of SourceForge. It is similar but has better code hosting options (including hg and git). It currently hosts 3022 projects, 60739 users, and 25504 bugs. Launchpad is an original project management service from Canonical, and offers relatively unique options (see the tour for details). It currently hosts 10141 projects, 2560014 users, 4310 teams, 323833 bugs, 24561 branches, 1117574 translations, 59871 answers, and 14499 blueprints. This is an exciting time for community software development... the past couple years have been a very creative time full of new ideas about how to collaborate, and it looks like things are only accelerating from here. Although it can be hard to decide which emerging systems to use, I'm happy to have no lack of options. :) -- Scott

Feb. 6, 2009

RE: Free HG performance

by CHalbersma.12＠westminster-mo.edu

Souceforge always seemed pretty good at hosting open souce projects. Of course I could be wrong there. Christopher "Chewy" R. Halbersma

Feb. 6, 2009

[patch]: fix leak in a_Cookies_get_query()

by onepoint＠starurchin.org

On Thu, Feb 05, 2009 at 08:12:25PM +0000, corvid wrote: > Jeremy wrote: > > Why does a_Cookies_get_query() return a "Cookies2" header even if > > the cookies DPI returns nothing? [...] > > We return it if we are willing to accept cookies from the server. It > indicates that dillo accepts the newer-style cookies. If we don't > really want any cookies from them anyway, we return an empty string. OK, thanks for the explanation. Jeremy Henty

Feb. 6, 2009

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > Looks good, but I think Dillo would have to migrate > away from Mercurial to use it. After using hg for the past couple years and bzr for about a year, I've found bzr to be an upgrade. I still use both on a regular basis, but no longer choose hg for any new projects. The main differences to be aware of are: - Branches are directories instead of labels. Each directory has only one "head", and you switch between branches with "cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix". - There are a lot of plugins available to extend functionality in various ways. A couple I recommend are bzr-gtk ("bzr vis" is a nice way to browse history) and bzr-bisect (helps isolate where bugs were introduced). - It has a concept of a main line of development, and meaningful version numbers. Merges are always explicit, even when hg would merge in-line. This makes feature branches more useful. That last one probably requires a little more explanation. Say you branch from trunk at r100 to add a feature. It requires some major changes, so you break everything while refactoring and spend a few revisions getting it all working again. It takes 10 revisions total. So, you send the changes upstream. They like it. They merge it... And nobody else checked anything in while you were working. Now (in hg) trunk is at r110, with your new feature. And the revision graph ends up being a straight line, so there's no evidence a merge occurred. If anyone tries to use r101 through r109, they'll find that it's all broken. The way bzr handles it is you submit 10 revisions, and when merged, trunk bumps up to r101. The revision graph shows a branch off to the side with 10 changes (r100.1.1 through r100.1.10) and a merge at the end (r101), and the trunk contains only non-broken versions. It makes more sense to me. > They use bzr, and although they integrate with some other > VCSs, mercurial isn't one of them. It's a one-time conversion, instead of the two-way conduit they support for subversion. I tried it just now (using bzr-fastimport) and it worked. The new branch is in my "junk" folder (launchpad equivalent of /tmp/) if anyone wants to try it: bzr branch lp:~toykeeper/+junk/dillo Personally, the main thing I find annoying about bzr is that it's not the easiest thing to type. I use "alias b=bzr" in my shell to fix that. -- Scott

Feb. 5, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Qui, 2009-02-05 ?s 20:56 +0000, Jo?o Ricardo Louren?o escreveu: > Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > > Hello, > > > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > Greetings. > > > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > > it. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > > I see some issues in your implementation. E.g. try to search for > > > > > 'ab' in a string 'abababa'. > > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > > matches, but once it no longer does you would need to backtrack. > > > > > The easiest but inefficient way to implement searching > > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > > algorithm avoids that. > > > > > I think it would be best to adapt search0 somehow to allow backward > > > > > searching - it's more or less the same thing as forward searching > > > > > anyway. Some ugly edge cases when switching between forward and > > > > > backward maybe :-) > > > > > > > > > > Thanks for working on that, > > > > > Johannes > > > > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > > forwards? > > > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > > compilable, but I might add some tests soon. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jo?o > > > > > > > > Thanks for your answer. > > > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > > got (provisory) working search0Backwards() replacement. How efficient do > > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > > you think there is a 'really' better way of searching backwards, than > > > > reversing the word and searching backwards? As far as code-changes it > > > > takes very few lines and I have a working example of it. However, the > > > > extra reversing work might hit us hard. > > > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > > to be rather small and we only need to reverse it once. > > > The point is to avoid the backtracking. So that every letter in the > > > text (haystack) is only visited once. > > > > If reversing the needle is all it takes, go ahead. > > If the code is simple and it takes twice the time a forward > > search, go ahead too. Backward search is much less used than > > forward search and it's better to have it than not, and unless > > the delay is annoying there's no compelling need to optimize. > > > > > > Thanks for the answer. > > OK, I think I worked it out, but the string is being reversed everytime > we search backwards, to maintain compatibility with forward searching. > Of course an alternative is to store it as private member, what do you > think? > > I couldn't find any function for reversing a C-String in dillo's code, > so I put my own as a static member in FindtextState, should I move it > elsewhere? > > I tested multiple cases and it seems (to me) that this one is bugless, > maybe you'll find a nasty/dirty bug I caused, but time will tell :) > > Also, the reverse string function was the only one added, all the rest > was only altered. > > Thanks for the support, > > Jo?o (Apart from the fact I didn't attach any patch...) Scratch that, my bad, that patch contained various bugs. The first kind of bug related to a typo which I now fixed. The second kind because of me interpreting code the wrong way and the third one because of the particular case of searching for things either at the beggining or at the end of the page. I think I fixed all of them and have an updated patch, excuse me for my previous mistakes... Jo?o

Feb. 5, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > Hello, > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Greetings. > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > it. > > > > > > > > Great. > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > I see some issues in your implementation. E.g. try to search for > > > > 'ab' in a string 'abababa'. > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > matches, but once it no longer does you would need to backtrack. > > > > The easiest but inefficient way to implement searching > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > algorithm avoids that. > > > > I think it would be best to adapt search0 somehow to allow backward > > > > searching - it's more or less the same thing as forward searching > > > > anyway. Some ugly edge cases when switching between forward and > > > > backward maybe :-) > > > > > > > > Thanks for working on that, > > > > Johannes > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > forwards? > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > compilable, but I might add some tests soon. > > > > > > > > > > Thanks, > > > > > > > > > > Jo?o > > > > > > Thanks for your answer. > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > got (provisory) working search0Backwards() replacement. How efficient do > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > you think there is a 'really' better way of searching backwards, than > > > reversing the word and searching backwards? As far as code-changes it > > > takes very few lines and I have a working example of it. However, the > > > extra reversing work might hit us hard. > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > to be rather small and we only need to reverse it once. > > The point is to avoid the backtracking. So that every letter in the > > text (haystack) is only visited once. > > If reversing the needle is all it takes, go ahead. > If the code is simple and it takes twice the time a forward > search, go ahead too. Backward search is much less used than > forward search and it's better to have it than not, and unless > the delay is annoying there's no compelling need to optimize. > > Thanks for the answer. OK, I think I worked it out, but the string is being reversed everytime we search backwards, to maintain compatibility with forward searching. Of course an alternative is to store it as private member, what do you think? I couldn't find any function for reversing a C-String in dillo's code, so I put my own as a static member in FindtextState, should I move it elsewhere? I tested multiple cases and it seems (to me) that this one is bugless, maybe you'll find a nasty/dirty bug I caused, but time will tell :) Also, the reverse string function was the only one added, all the rest was only altered. Thanks for the support, Jo?o

Feb. 5, 2009

[patch]: fix leak in a_Cookies_get_query()

by corvid＠lavabit.com

Jeremy wrote: > This patch stops a_Cookies_get_query() leaking. However, I'm a little > puzzled by the logic here. Why does a_Cookies_get_query() return a > "Cookies2" header even if the cookies DPI returns nothing? Can't it > just return NULL or an empty string? Wouldn't that be cleaner? We return it if we are willing to accept cookies from the server. It indicates that dillo accepts the newer-style cookies. If we don't really want any cookies from them anyway, we return an empty string.

Feb. 5, 2009

[patch]: fix leak in a_Cookies_get_query()

by onepoint＠starurchin.org

This patch stops a_Cookies_get_query() leaking. However, I'm a little puzzled by the logic here. Why does a_Cookies_get_query() return a "Cookies2" header even if the cookies DPI returns nothing? Can't it just return NULL or an empty string? Wouldn't that be cleaner? Regards, Jeremy Henty

Feb. 5, 2009

Re: view stylesheets from page menu

by corvid＠lavabit.com

Johannes wrote: > On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > > To me: It looks more like a developers feature than one for user level. > > Well, not more than "View page source". Yes, the same charge could be levelled against the bug meter. > I think it's important and in the spirit of dillo to make the web as > transparent for the user as possible. Well said. And part of my motivation was that I was thinking of extending what I have now so that I could examine the URLs before loading them.

Feb. 5, 2009

FreeHG performance

by onepoint＠starurchin.org

On Thu, Feb 05, 2009 at 05:52:40AM -0700, Scott Scriven wrote: > Did anyone ever look at launchpad? > > https://launchpad.net/+tour > > It's a "batteries included" type of project infrastructure host, > feature-rich, easy, reliable, and free. It could provide hosting > for almost everything the project needs and provide plenty of > room to grow. Looks good, but I think Dillo would have to migrate away from Mercurial to use it. They use bzr, and although they integrate with some other VCSs, mercurial isn't one of them. Regards, Jeremy Henty

Feb. 5, 2009

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > > I doubt that setting up a savannah project would take very long. > Really? I just had a look and there's a long checklist. ... Did anyone ever look at launchpad? https://launchpad.net/+tour It's a "batteries included" type of project infrastructure host, feature-rich, easy, reliable, and free. It could provide hosting for almost everything the project needs and provide plenty of room to grow. The tour gives a pretty good overview... it may be a lot to absorb all at once, but it's worth a look. -- Scott

Feb. 5, 2009

Re: view stylesheets from page menu

by Johannes.Hofmann＠gmx.de

On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 03, 2009 at 08:00:12PM +0100, Hofmann Johannes wrote: > > Hi corvid, > > > > On Tue, Feb 03, 2009 at 05:13:27PM +0000, corvid wrote: > > > > > > (a rough quick patch just to get feedback) > > > I saw that Jorge added cssUrls, which provided an opportunity... > > > > Very nice! Just one small thing. The stylesheets entry does not get > > disabled on non-CSS pages here. Extending the check like this: > > > > + if (cssUrls && cssUrls->size () > 0) { > > > > helps. > > To me: It looks more like a developers feature than one for user level. Well, not more than "View page source". I think it's important and in the spirit of dillo to make the web as transparent for the user as possible. > > > > BTW: Viewing stylesheets in a normal browser window is really fast > > compared to the fltk text viewer we use for "View page source"! > > Yes, since a long time I've wanted to find some time to turn > "View page source" into a dpi. > > Maybe after the close-tab button I can give it a hand. > Yes, that would be great. Cheers, Johannes > -- > Cheers > Jorge.-

Feb. 5, 2009

FreeHG performance

by jcid＠dillo.org

On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 30 Jan 2009 17:24:56 +0100 > Andreas Kemnade <akemnade(a)tzi.de> wrote: > > > Hi Jorge, > > > > On Fri, 30 Jan 2009 12:22:46 -0300 > > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > > confirms that Mercurial itself is really fast and I've seen other > > > > reports criticising FreeHG's performance. Perhaps we should think > > > > about moving host? It's not always easy to find time to devote to > > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > > for a connection to the server. I'm committed enough to grit my teeth > > > > and wait but I can see it putting off would-be contributors. > > > > > > > > Just a thought, > > > > > > Yes, I've also had trouble with it, and when normal it's slower > > > than our Wearlab's CVS. > > > > > > A couple of days ago (while developoing/reviewing patches) I > > > digged a bit on it and it seems that bitbucket is much faster. We > > > can try bitbucket while we find a long term solution (e.g. FSF's > > > savannah is offering Mercurial and Git repos, but the applying > > > process may take some time). > > > > > > At some point in time we should move out from the Wearlab, as > > > it may be closed soon. Currently we need webserver/CGI/python > > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > > we may use another bugtracker too. > > > > > The server which actually hosts the dillo debian and openmoko > > packages should be an alternative. > > At least performance and bandwidth should be no problem. Maybe moving > > hg there is a starting point. > > > ok, try > hg clone http://hg.dillo.org/dillo > > just add entries for hg.dillo.org in your /etc/hosts to point to that server. > 85.214.105.140 hg.dillo.org It works very well! > push access (with ssl) is not set up yet. > When it is done, of course the dns can be changed so that > hg.dillo.org points to the right server. Good. Just let me know when it's done. -- Cheers Jorge.-

Feb. 5, 2009

FreeHG performance

by onepoint＠starurchin.org

On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > ok, try hg clone http://hg.dillo.org/dillo Now *that* was nice and fast! Thanks! Jeremy Henty

Feb. 4, 2009

FreeHG performance

by akemnade＠tzi.de

Hi, On Fri, 30 Jan 2009 17:24:56 +0100 Andreas Kemnade <akemnade(a)tzi.de> wrote: > Hi Jorge, > > On Fri, 30 Jan 2009 12:22:46 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > confirms that Mercurial itself is really fast and I've seen other > > > reports criticising FreeHG's performance. Perhaps we should think > > > about moving host? It's not always easy to find time to devote to > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > for a connection to the server. I'm committed enough to grit my teeth > > > and wait but I can see it putting off would-be contributors. > > > > > > Just a thought, > > > > Yes, I've also had trouble with it, and when normal it's slower > > than our Wearlab's CVS. > > > > A couple of days ago (while developoing/reviewing patches) I > > digged a bit on it and it seems that bitbucket is much faster. We > > can try bitbucket while we find a long term solution (e.g. FSF's > > savannah is offering Mercurial and Git repos, but the applying > > process may take some time). > > > > At some point in time we should move out from the Wearlab, as > > it may be closed soon. Currently we need webserver/CGI/python > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > we may use another bugtracker too. > > > The server which actually hosts the dillo debian and openmoko > packages should be an alternative. > At least performance and bandwidth should be no problem. Maybe moving > hg there is a starting point. > ok, try hg clone http://hg.dillo.org/dillo just add entries for hg.dillo.org in your /etc/hosts to point to that server. 85.214.105.140 hg.dillo.org or 2001:6f8:900:71b::2 hg.dillo.org push access (with ssl) is not set up yet. When it is done, of course the dns can be changed so that hg.dillo.org points to the right server. Greetings Andreas Kemnade

Feb. 4, 2009

Leaking image structures

by onepoint＠starurchin.org

One of the biggest leaks that valgrind reports is image structures. I'm attaching logs that show memory being allocated by a_Png_new() and cousins and not being freed. There are also frequent leaks of memory allocated by the image libraries from within the various image callbacks, but I suspect these are just another effect of the Dillo image structures not being freed. Unfortunately I'm having a hard time tracking these leaks down. They regularly appear after long browsing sessions, but I haven't found any single page that reproduces them. I suspect they are caused by some race condition inside the CCC rather than the HTML parser. I am browsing with image loading enabled, and if I understand the code correctly that means that the Web structures in the CCC own all the references to image structures. The fact that image structures are reference counted makes it hard to know when the structures should be freed anyway. Indeed, does Dillo even ensure that image structures are freed? Maybe this is just a symptom of incomplete cleanup at exit rather than a true leak? I've looked over the code and can't see any obvious leaks so I'm rather stuck. Any tips for tracking this down? Even if it's not a true leak it would be good to have a fix that cleaned up the valgrind logs. Regards, Jeremy Henty

Feb. 4, 2009

[patch] Search Previous

by jcid＠dillo.org

On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > Hello, > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Greetings. > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > it. > > > > > > Great. > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > I must say I have difficulties understanding the code behind > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > haven't found any bugs, if you find any, please do say. > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > for efficient searching. It is pretty clever but a bit tricky. > > > I see some issues in your implementation. E.g. try to search for > > > 'ab' in a string 'abababa'. > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > matches, but once it no longer does you would need to backtrack. > > > The easiest but inefficient way to implement searching > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > algorithm avoids that. > > > I think it would be best to adapt search0 somehow to allow backward > > > searching - it's more or less the same thing as forward searching > > > anyway. Some ugly edge cases when switching between forward and > > > backward maybe :-) > > > > > > Thanks for working on that, > > > Johannes > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > forwards? > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > compilable, but I might add some tests soon. > > > > > > > > Thanks, > > > > > > > > Jo?o > > > > Thanks for your answer. > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > got (provisory) working search0Backwards() replacement. How efficient do > > you think it is to handle the word by reversing it? Rephrasing that, do > > you think there is a 'really' better way of searching backwards, than > > reversing the word and searching backwards? As far as code-changes it > > takes very few lines and I have a working example of it. However, the > > extra reversing work might hit us hard. > > Reversing the word (needle) we are searching for is no problem. It's supposed > to be rather small and we only need to reverse it once. > The point is to avoid the backtracking. So that every letter in the > text (haystack) is only visited once. If reversing the needle is all it takes, go ahead. If the code is simple and it takes twice the time a forward search, go ahead too. Backward search is much less used than forward search and it's better to have it than not, and unless the delay is annoying there's no compelling need to optimize. -- Cheers Jorge.-

Feb. 4, 2009

[patch] Search Previous

by Johannes.Hofmann＠gmx.de

On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > Hello, > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > Greetings. > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > it. > > > > Great. > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > I must say I have difficulties understanding the code behind > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > it could possibly be optimized, but it seems to do the job for now, I > > > haven't found any bugs, if you find any, please do say. > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > for efficient searching. It is pretty clever but a bit tricky. > > I see some issues in your implementation. E.g. try to search for > > 'ab' in a string 'abababa'. > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > matches, but once it no longer does you would need to backtrack. > > The easiest but inefficient way to implement searching > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > algorithm avoids that. > > I think it would be best to adapt search0 somehow to allow backward > > searching - it's more or less the same thing as forward searching > > anyway. Some ugly edge cases when switching between forward and > > backward maybe :-) > > > > Thanks for working on that, > > Johannes > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > forwards? > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > compilable, but I might add some tests soon. > > > > > > Thanks, > > > > > > Jo?o > > Thanks for your answer. > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > got (provisory) working search0Backwards() replacement. How efficient do > you think it is to handle the word by reversing it? Rephrasing that, do > you think there is a 'really' better way of searching backwards, than > reversing the word and searching backwards? As far as code-changes it > takes very few lines and I have a working example of it. However, the > extra reversing work might hit us hard. Reversing the word (needle) we are searching for is no problem. It's supposed to be rather small and we only need to reverse it once. The point is to avoid the backtracking. So that every letter in the text (haystack) is only visited once. Regards, Johannes > > Thanks, > > Jo?o > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 4, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > Hello, > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > Greetings. > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > it. > > Great. > > > > > Basically, I implemented the Search Previous feature. > > > > I must say I have difficulties understanding the code behind > > FindtextState::search0(), so I did not base my code on it at all. Sure > > it could possibly be optimized, but it seems to do the job for now, I > > haven't found any bugs, if you find any, please do say. > > FindtextState implements the Knuth-Morris-Pratt algorithm > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > for efficient searching. It is pretty clever but a bit tricky. > I see some issues in your implementation. E.g. try to search for > 'ab' in a string 'abababa'. > Even more tricky is searching for ababb in abababb, i.e. the prefix > matches, but once it no longer does you would need to backtrack. > The easiest but inefficient way to implement searching > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > algorithm avoids that. > I think it would be best to adapt search0 somehow to allow backward > searching - it's more or less the same thing as forward searching > anyway. Some ugly edge cases when switching between forward and > backward maybe :-) > > Thanks for working on that, > Johannes > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > maybe something like SHIFT+RETURN, since RETURN handles searching > > forwards? > > > > Also, I did not add any tests, and I only altered a line to make them > > compilable, but I might add some tests soon. > > > > Thanks, > > > > Jo?o Thanks for your answer. OK, I am still trying to 'go deep' with the KMP algorithm, but I have got (provisory) working search0Backwards() replacement. How efficient do you think it is to handle the word by reversing it? Rephrasing that, do you think there is a 'really' better way of searching backwards, than reversing the word and searching backwards? As far as code-changes it takes very few lines and I have a working example of it. However, the extra reversing work might hit us hard. Thanks, Jo?o

Feb. 4, 2009

[patch] Search Previous

by Johannes.Hofmann＠gmx.de

Hello, On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > Greetings. > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > it. Great. > > Basically, I implemented the Search Previous feature. > > I must say I have difficulties understanding the code behind > FindtextState::search0(), so I did not base my code on it at all. Sure > it could possibly be optimized, but it seems to do the job for now, I > haven't found any bugs, if you find any, please do say. FindtextState implements the Knuth-Morris-Pratt algorithm http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm for efficient searching. It is pretty clever but a bit tricky. I see some issues in your implementation. E.g. try to search for 'ab' in a string 'abababa'. Even more tricky is searching for ababb in abababb, i.e. the prefix matches, but once it no longer does you would need to backtrack. The easiest but inefficient way to implement searching is doing a strcmp() at every text position. The Knuth-Morris-Pratt algorithm avoids that. I think it would be best to adapt search0 somehow to allow backward searching - it's more or less the same thing as forward searching anyway. Some ugly edge cases when switching between forward and backward maybe :-) Thanks for working on that, Johannes > > Additionally, I did not set any hotkeys for the search-previous action, > maybe something like SHIFT+RETURN, since RETURN handles searching > forwards? > > Also, I did not add any tests, and I only altered a line to make them > compilable, but I might add some tests soon. > > Thanks, > > Jo?o > diff -r ccdc02768890 dw/findtext.cc > --- a/dw/findtext.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/findtext.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -66,8 +66,9 @@ > hlIterator = NULL; > } > > -FindtextState::Result FindtextState::search (const char *key, bool caseSens) > +FindtextState::Result FindtextState::search (const char *key, bool caseSens, bool backwards) > { > + > if (!widget || *key == 0) // empty keys are not found > return NOT_FOUND; > > @@ -91,13 +92,19 @@ > if (iterator) > delete iterator; > iterator = new CharIterator (widget); > - iterator->next (); > + > + if(backwards) { > + /* Go to end */ > + while(iterator->next () ) ; > + iterator->prev(); //We don't want to be at CharIterator::END. > + } else > + iterator->next (); > } else > newKey = false; > > bool firstTrial = !wasHighlighted || newKey; > > - if (search0 ()) { > + if (backwards ? search0Backwards () : search0 ()) { > // Highlighlighting is done with a clone. > hlIterator = iterator->cloneCharIterator (); > for (int i = 0; key[i]; i++) > @@ -116,10 +123,15 @@ > // Nothing found anymore, reset the state for the next trial. > delete iterator; > iterator = new CharIterator (widget); > - iterator->next (); > + if(backwards) { > + /* Go to end */ > + while(iterator->next () ) ; > + iterator->prev(); //We don't want to be at CharIterator::END. > + } else > + iterator->next (); > > // We expect a success. > - Result result2 = search (key, caseSens); > + Result result2 = search (key, caseSens, backwards); > assert (result2 == SUCCESS); > return RESTART; > } > @@ -179,6 +191,46 @@ > return false; > } > > +/* > + * Search backwards. > + */ > +bool FindtextState::search0Backwards () > +{ > + if (iterator->getChar () == CharIterator::END) > + return false; > + > + bool equal=false; > + int l = strlen (key); > + int j = l; > + > + /* get before the word */ > + for (int i = 0; i < l+1; i++) > + iterator->prev (); > + > + do { > + > + if (charsEqual (iterator->getChar (), key[l==1 ? 0 : j], caseSens)) { > + > + if((j==0 && equal) || l==1) { return true; } > + equal=true; > + > + } else if(j!=l) { > + > + /* Restart the search */ > + equal=false; > + j=l; > + continue; /* Do not iterate back when restarting the search. */ > + > + } > + > + if(!iterator->prev()) return false; /* No more text where to search */ > + > + j--; > + > + } while(true); > + > +} > + > bool FindtextState::search0 () > { > if (iterator->getChar () == CharIterator::END) > diff -r ccdc02768890 dw/findtext.hh > --- a/dw/findtext.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/findtext.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -62,6 +62,7 @@ > static int *createNexttab (const char *key, bool caseSens); > bool unhighlight (); > bool search0 (); > + bool search0Backwards (); > > inline static bool charsEqual (char c1, char c2, bool caseSens) > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > @@ -72,7 +73,7 @@ > ~FindtextState (); > > void setWidget (Widget *widget); > - Result search (const char *key, bool caseSens); > + Result search (const char *key, bool caseSens, bool backwards); > void resetSearch (); > }; > > diff -r ccdc02768890 dw/layout.hh > --- a/dw/layout.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/dw/layout.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -255,8 +255,8 @@ > emitter.connectLayout (receiver); } > > /** \brief See dw::core::FindtextState::search. */ > - inline FindtextState::Result search (const char *str, bool caseSens) > - { return findtextState.search (str, caseSens); } > + inline FindtextState::Result search (const char *str, bool caseSens, int backwards) > + { return findtextState.search (str, caseSens, backwards); } > > /** \brief See dw::core::FindtextState::resetSearch. */ > inline void resetSearch () { findtextState.resetSearch (); } > diff -r ccdc02768890 src/findbar.cc > --- a/src/findbar.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/findbar.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -63,7 +63,21 @@ > > if (key[0] != '\0') > a_UIcmd_findtext_search(a_UIcmd_get_bw_by_widget(fb), > - key, case_sens); > + key, case_sens, false); > +} > + > +/* > + * Find previous occurrence of input key > + */ > +void Findbar::searchBackwards_cb(Widget *, void *vfb) > +{ > + Findbar *fb = (Findbar *)vfb; > + const char *key = fb->i->text(); > + bool case_sens = fb->check_btn->value(); > + > + if (key[0] != '\0') > + a_UIcmd_findtext_search(a_UIcmd_get_bw_by_widget(fb), > + key, case_sens, true); > } > > /* > @@ -96,7 +110,7 @@ > int button_width = 70; > int gap = 2; > int border = 2; > - int input_width = width - (2 * border + 3 * (button_width + gap)); > + int input_width = width - (2 * border + 4 * (button_width + gap)); > int x = border; > height -= 2 * border; > > @@ -121,7 +135,6 @@ > i->clear_tab_to_focus(); > i->set_click_to_focus(); > > - // TODO: search previous would be nice > next_btn = new HighlightButton(x, border, button_width, height, "Next"); > x += button_width + gap; > next_btn->tooltip("Find next occurrence of the search phrase"); > @@ -129,6 +142,12 @@ > next_btn->add_shortcut(KeypadEnter); > next_btn->callback(search_cb, this); > next_btn->clear_tab_to_focus(); > + > + prev_btn= new HighlightButton(x, border, button_width, height, "Previous"); > + prev_btn->tooltip("Find previous occurrence of the search phrase"); > + prev_btn->callback(searchBackwards_cb, this); > + prev_btn->clear_tab_to_focus(); > + x += button_width + gap; > > check_btn = new CheckButton(x, border, 2*button_width, height, > "Case-sensitive"); > diff -r ccdc02768890 src/findbar.hh > --- a/src/findbar.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/findbar.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -16,12 +16,13 @@ > */ > class Findbar : public Group { > Button *clrb; > - HighlightButton *hide_btn, *next_btn; > + HighlightButton *hide_btn, *next_btn, *prev_btn; > CheckButton *check_btn; > xpmImage *hideImg; > Input *i; > > static void search_cb (Widget *, void *); > + static void searchBackwards_cb (Widget *, void *); //add > static void search_cb2 (Widget *, void *); > static void hide_cb (Widget *, void *); > > diff -r ccdc02768890 src/uicmd.cc > --- a/src/uicmd.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/uicmd.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -17,6 +17,8 @@ > #include <math.h> /* for rint */ > #include <fltk/Widget.h> > #include <fltk/TabGroup.h> > +#include <fltk/Button.h> > +#include <fltk/InvisibleBox.h> > > #include "dir.h" > #include "ui.hh" > @@ -964,13 +1032,13 @@ > } > > /* > - * Search for next occurrence of key. > + * Search for next/previous occurrence of key. > */ > -void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens) > +void a_UIcmd_findtext_search(BrowserWindow *bw, const char *key, int case_sens, int backwards) > { > Layout *l = (Layout *)bw->render_layout; > > - switch (l->search(key, case_sens)) { > + switch (l->search(key, case_sens, backwards)) { > case FindtextState::RESTART: > a_UIcmd_set_msg(bw, "No further occurrences of \"%s\". " > "Restarting from the top.", key); > diff -r ccdc02768890 src/uicmd.hh > --- a/src/uicmd.hh Sun Feb 01 17:21:41 2009 -0300 > +++ b/src/uicmd.hh Tue Feb 03 19:24:11 2009 +0000 > @@ -34,7 +34,7 @@ > void a_UIcmd_add_bookmark(BrowserWindow *bw, const DilloUrl *url); > void a_UIcmd_fullscreen_toggle(BrowserWindow *bw); > void a_UIcmd_findtext_dialog(BrowserWindow *bw); > -void a_UIcmd_findtext_search(BrowserWindow *bw,const char *key,int case_sens); > +void a_UIcmd_findtext_search(BrowserWindow *bw,const char *key,int case_sens, int backwards); > void a_UIcmd_findtext_reset(BrowserWindow *bw); > void a_UIcmd_focus_main_area(BrowserWindow *bw); > void a_UIcmd_focus_location(void *vbw); > diff -r ccdc02768890 test/dw_find_test.cc > --- a/test/dw_find_test.cc Sun Feb 01 17:21:41 2009 -0300 > +++ b/test/dw_find_test.cc Tue Feb 03 19:24:11 2009 +0000 > @@ -44,7 +44,7 @@ > static void findCallback (::fltk::Widget *widget, void *data) > { > //switch(layout->search ("worm", true)) { > - switch(layout->search ("WORM", false)) { > + switch(layout->search ("WORM", false, false)) { > case FindtextState::SUCCESS: > resultLabel->label("SUCCESS"); > break; > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 3, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Greetings. I 'spotted' a TODO on searching 'backwards' and decided to have a go at it. Basically, I implemented the Search Previous feature. I must say I have difficulties understanding the code behind FindtextState::search0(), so I did not base my code on it at all. Sure it could possibly be optimized, but it seems to do the job for now, I haven't found any bugs, if you find any, please do say. Additionally, I did not set any hotkeys for the search-previous action, maybe something like SHIFT+RETURN, since RETURN handles searching forwards? Also, I did not add any tests, and I only altered a line to make them compilable, but I might add some tests soon. Thanks, Jo?o

Feb. 3, 2009

Bad character coding for www.blisty.cz

by newman.x＠gmail.com

On Tue, Feb 03, 2009 at 09:34:17AM -0300, Jorge Arellano Cid wrote: > > OK, the tip has a patch for both problems. > It passes these tests: > > Feb03 load Reload Back > ---------------------------- > H__ OK OK OK H = has charset in HTTP header > HM_ OK OK OK M = has charset in META > H_S OK OK OK S = has remote CSS stylesheet > HMS OK OK OK _ = disabled > ___ OK OK OK > _M_ OK OK OK > __S OK OK OK t = timing issue > _MS OK OK OK x = always fails > ---------------------------- > > and the reported cases too. > > I still don't feel comfortable with this part of the code: it's > complex and has the Cache_ref() trick. Anyway, as far as tests > are concerned it behaves well. > > Please test and report. > Thanks, Jorge, I can confirm it's fixed now. -- Regards, Michal Nowak

Feb. 3, 2009

Bad character coding for www.blisty.cz

by corvid＠lavabit.com

Jorge wrote: > I still don't feel comfortable with this part of the code: it's > complex and has the Cache_ref() trick. Anyway, as far as tests > are concerned it behaves well. I find myself thinking again how dicache for image/* with RGB internally is a lot like ??? for text/* with UTF-8 internally but they are handled completely differently. Of course I don't know dicache well enough to be too sure quite how far that analogy holds...

Feb. 3, 2009

FreeHG performance

by onepoint＠starurchin.org

On Tue, Feb 03, 2009 at 03:10:11PM +0100, Hofmann Johannes wrote: > I guess we really want an independent server/virtual machine > somewhere just as we have at wearlab until now. I already own a virtual machine at bytemark.co.uk. I can look into setting up mercurial there. The Bytemark hosting crew are pretty geek-savvy. Regards, Jeremy Henty

Feb. 3, 2009

FreeHG performance

by Johannes.Hofmann＠gmx.de

On Tue, Feb 03, 2009 at 01:45:36PM +0000, Jeremy Henty wrote: > On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > > > I doubt that setting up a savannah project would take very long. > > Really? I just had a look and there's a long checklist. You have to > supply a fairly detailed project description, so the core devs would > have to agree to one before signing up. You have to list all your > dependencies and assert that they are free too. You also have to > check that all your files have a valid copyright notice, which is > currently not true of most of our *.{h,hh} files. (Mind you, I got a > laugh from their "I read carefully and won't check this" item.) Oh sorry, should have checked more carefully... > > I asked the local Linux Users Group for recommendations and bitbucket > was mentioned. What do people think? > > Terms of service: http://bitbucket.org/site/terms/ > > Note the clauses: > > By submitting Content to Avantlumiere for inclusion on your > Website, you grant Avantlumiere a world-wide, royalty-free, and > non-exclusive license to reproduce, modify, adapt and publish the > Content solely for the purpose of displaying, distributing and > promoting your account or repository. > > I guess the "solely for the purpose of displaying ..." clause makes > that OK. They presumably want to be able to advertise the fact that > they host Dillo without us claiming copyright infringement, which is > fair enough. > > Also: > > Avantlumiere reserves the right, at its sole discretion, to modify > or replace any part of this Agreement. It is your responsibility > to check this Agreement periodically for changes. Your continued > use of or access to the Website following the posting of any > changes to this Agreement constitutes acceptance of those changes. > > That makes me nervous, but bitbucket is popular so I guess people > trust them not to mess their customers around. Argh, I really hate this stuff. I guess we really want an independent server/virtual machine somewhere just as we have at wearlab until now. > > I'll set up a BitBucket repo if people agree. Maybe creating just frequently updated copy there would help already? Regards, Johannes

Feb. 3, 2009

FreeHG performance

by onepoint＠starurchin.org

On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > I doubt that setting up a savannah project would take very long. Really? I just had a look and there's a long checklist. You have to supply a fairly detailed project description, so the core devs would have to agree to one before signing up. You have to list all your dependencies and assert that they are free too. You also have to check that all your files have a valid copyright notice, which is currently not true of most of our *.{h,hh} files. (Mind you, I got a laugh from their "I read carefully and won't check this" item.) I asked the local Linux Users Group for recommendations and bitbucket was mentioned. What do people think? Terms of service: http://bitbucket.org/site/terms/ Note the clauses: By submitting Content to Avantlumiere for inclusion on your Website, you grant Avantlumiere a world-wide, royalty-free, and non-exclusive license to reproduce, modify, adapt and publish the Content solely for the purpose of displaying, distributing and promoting your account or repository. I guess the "solely for the purpose of displaying ..." clause makes that OK. They presumably want to be able to advertise the fact that they host Dillo without us claiming copyright infringement, which is fair enough. Also: Avantlumiere reserves the right, at its sole discretion, to modify or replace any part of this Agreement. It is your responsibility to check this Agreement periodically for changes. Your continued use of or access to the Website following the posting of any changes to this Agreement constitutes acceptance of those changes. That makes me nervous, but bitbucket is popular so I guess people trust them not to mess their customers around. I'll set up a BitBucket repo if people agree. Regards, Jeremy Henty

Feb. 3, 2009

FreeHG performance

by Johannes.Hofmann＠gmx.de

yOn Fri, Jan 30, 2009 at 12:22:46PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > often I get a 404 Not Found and right now it's hanging. Everyone > > confirms that Mercurial itself is really fast and I've seen other > > reports criticising FreeHG's performance. Perhaps we should think > > about moving host? It's not always easy to find time to devote to > > Dillo so it's rather aggravating when that time is wasted just waiting > > for a connection to the server. I'm committed enough to grit my teeth > > and wait but I can see it putting off would-be contributors. > > > > Just a thought, > > Yes, I've also had trouble with it, and when normal it's slower > than our Wearlab's CVS. > > A couple of days ago (while developoing/reviewing patches) I > digged a bit on it and it seems that bitbucket is much faster. We > can try bitbucket while we find a long term solution (e.g. FSF's > savannah is offering Mercurial and Git repos, but the applying > process may take some time). > > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. > > Suggestions? I agree. freehg.org is just very simple to setup so I chose that for the CSS prototype. I doubt that setting up a savannah project would take very long. Anyone volunteering? Cheers, Johannes

Feb. 3, 2009

Bad character coding for www.blisty.cz

by jcid＠dillo.org

On Mon, Feb 02, 2009 at 09:42:20AM -0300, Jorge Arellano Cid wrote: > On Mon, Feb 02, 2009 at 01:45:43AM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > > > Michal wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > > > following sence (it's in Czech) > > > > > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > > > was changed. > > > > > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > > > 2) dillo www.blisty.cz > > > > > > > > 3) --> PASS > > > > > > > > 4) quit dillo > > > > > > > > 5) dillo www.blisty.cz > > > > > > > > 6) --> FAIL > > > > > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > > > > > Breaks for me, too. > > > > > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > > > appears is no fun. > > > > > > > > > > > > It works for me! :-) > > > > > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > > > when charset appears after the stylesheet in HEAD. This page also > > > > > > has timing issues: http://www.daemonnews.org > > > > > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > > > after charset or at head close may fix it. > > > > > > > > > > Does anyone else experience pages not rendering until > > > > > download is complete? I see this with the dillo.org > > > > > pages, for instance, since the meta charset is iso-8859-1. > > > > > > > > Yes, I'm also seeing it. Not sure when this started. > > > > > > According to hg bisect it starts with d29cdb5b842e, > > > but I don't see any obvious issues there. > > > Jorge, can you have a look please? > > > > With > > html->stop_parser = true; /* Avoid a race condition */ > > in Html_tag_open_meta(), we don't get to Html_tag_close_head > > in the usual way. We have to wait until the cache client callback > > is called with CA_Close, triggering DilloHtml::finishParsing, > > which closes all of the open tags. Html_tag_close_head() > > is called and we finally get our repush(). > > Good analysis. > > I'm looking into both issues... OK, the tip has a patch for both problems. It passes these tests: Feb03 load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_S OK OK OK S = has remote CSS stylesheet HMS OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __S OK OK OK t = timing issue _MS OK OK OK x = always fails ---------------------------- and the reported cases too. I still don't feel comfortable with this part of the code: it's complex and has the Cache_ref() trick. Anyway, as far as tests are concerned it behaves well. Please test and report. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 3, 2009

Bad character coding for www.blisty.cz

by jcid＠dillo.org

On Mon, Feb 02, 2009 at 01:45:43AM +0000, corvid wrote: > Johannes wrote: > > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > > Michal wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > > following sence (it's in Czech) > > > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > > was changed. > > > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > > 2) dillo www.blisty.cz > > > > > > > 3) --> PASS > > > > > > > 4) quit dillo > > > > > > > 5) dillo www.blisty.cz > > > > > > > 6) --> FAIL > > > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > > > Breaks for me, too. > > > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > > appears is no fun. > > > > > > > > > > It works for me! :-) > > > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > > when charset appears after the stylesheet in HEAD. This page also > > > > > has timing issues: http://www.daemonnews.org > > > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > > after charset or at head close may fix it. > > > > > > > > Does anyone else experience pages not rendering until > > > > download is complete? I see this with the dillo.org > > > > pages, for instance, since the meta charset is iso-8859-1. > > > > > > Yes, I'm also seeing it. Not sure when this started. > > > > According to hg bisect it starts with d29cdb5b842e, > > but I don't see any obvious issues there. > > Jorge, can you have a look please? > > With > html->stop_parser = true; /* Avoid a race condition */ > in Html_tag_open_meta(), we don't get to Html_tag_close_head > in the usual way. We have to wait until the cache client callback > is called with CA_Close, triggering DilloHtml::finishParsing, > which closes all of the open tags. Html_tag_close_head() > is called and we finally get our repush(). Good analysis. I'm looking into both issues... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 2, 2009

[patch]: fix signature of Html_add_new_linkimage()

by onepoint＠starurchin.org

On Sun, Feb 01, 2009 at 08:56:41PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 01, 2009 at 08:45:06PM +0000, Jeremy Henty wrote: > > > * There's no need to pass the url to Html_add_new_linkimage() as > > a (DilloUrl **), so just copy the (DilloUrl *) pointer. > > It's used to emphasize the url parameter changes owner. Fair enough, but it didn't convey that to me at all. It just looked obviously wrong. I wonder if a comment would make the point better. Just a thought. Regards, Jeremy Henty

Feb. 2, 2009

Rendering XHTML 1.1

by Hole.destructor＠gmx.de

Hello Dillo developers, since you are planing to release Dillo-2.1 in about a month, I am wondering whether there are plans to support XHTML 1.1, HTML 5 and XHTML 2 web pages in the near future? Thanks, Alexander.

Feb. 2, 2009

Address Bar Text Clears

by Johannes.Hofmann＠gmx.de

On Mon, Feb 02, 2009 at 03:46:34AM +0000, calvin morrison wrote: > Ubuntu 8.10 right off the website, all the latest stable releases. > It's got to be before the page actually loads. What does "dillo -v" report as version? Cheers, Johannes

Feb. 2, 2009

Address Bar Text Clears

by crazycal00＠gmail.com

Ubuntu 8.10 right off the website, all the latest stable releases. It's got to be before the page actually loads. I'll try to recreate it on my laptop. I've been able to duplicate the problem on, but only when accessing a wikispaces page? if you tab away and tab back the url disappers from the address bar. On Sun, Feb 1, 2009 at 11:58 PM, corvid <corvid(a)lavabit.com> wrote: > Calvin wrote: >> open up a website, make sure to pick one that loads slowly and to type >> it in the address bar. as it's loading open up a new tab, now click >> back. the URL in the address bar field is empty. > > Hmm...I can't seem to get this to break. > Is this the 2.0 release or the current tree? > Suitably recent FLTK2 snapshot? > Are you running on OSX by any chance? > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 2, 2009

Bad character coding for www.blisty.cz

by corvid＠lavabit.com

Johannes wrote: > On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > > Michal wrote: > > > > > > Hi, > > > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > > following sence (it's in Czech) > > > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > > was changed. > > > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > > 2) dillo www.blisty.cz > > > > > > 3) --> PASS > > > > > > 4) quit dillo > > > > > > 5) dillo www.blisty.cz > > > > > > 6) --> FAIL > > > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > > > Breaks for me, too. > > > > > > > > > > Plus having to wait through 116K of download before anything > > > > > appears is no fun. > > > > > > > > It works for me! :-) > > > > > > > > Seriously, I still have a pending item to review here, and it's > > > > when charset appears after the stylesheet in HEAD. This page also > > > > has timing issues: http://www.daemonnews.org > > > > > > > > It looks like queueing the stylesheets and asking for them > > > > after charset or at head close may fix it. > > > > > > Does anyone else experience pages not rendering until > > > download is complete? I see this with the dillo.org > > > pages, for instance, since the meta charset is iso-8859-1. > > > > Yes, I'm also seeing it. Not sure when this started. > > According to hg bisect it starts with d29cdb5b842e, > but I don't see any obvious issues there. > Jorge, can you have a look please? With html->stop_parser = true; /* Avoid a race condition */ in Html_tag_open_meta(), we don't get to Html_tag_close_head in the usual way. We have to wait until the cache client callback is called with CA_Close, triggering DilloHtml::finishParsing, which closes all of the open tags. Html_tag_close_head() is called and we finally get our repush().

Feb. 2, 2009

Close-tab Button

by jorl17.8＠gmail.com

Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu: > On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > > Greetings to all. > > > > As a simple introduction may I say I thank you all for your work on > > Dillo. > > > > Currently, I am trying to implement the Close-Tab button. I've been > > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > > dillo-dev. > > > > FLTK Tabs don't support a close-tab button, as many of you have seen, > > and the idea was to have a button at the end of the tabs list. > > > > For that, I created an fltk::Button widget in CustTabGroup. I position > > this widget at the end of the tabs list and, then, I add() it to the > > CustTabGroup's parent() (UI). > > > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > > such a way that it doesn't resize the button itself, but only moves it. > > > > Refreshing the button (when changing/adding/closing tabs) is done in the > > handle() method of the CustTabGroup. > > > > Just a second ago I solved one of the problems, which was the fact that > > tab_height() returned 0 in the constructor and resize() didn't work. I > > worked around that by constructing the button only in event() if > > tab_height()>0 and it hasn't been constructed yet. This way we can use > > the correct height for the button. > > > > It may not seem reliable to do so many things in handle(). Any > > suggestions? > > We need to get something working, review it, and then we may > ask in fltk.general whether it could have side effects. > > > It is functional, only you can say if it fully suits Dillo's needs > > though. > > Please post the patch here so we can look at it. > > > Unfortunately, there are some problems: > > > > The first one is the most-relevant one. When the list of tabs grows it > > can go over the button. I have been trying to fix this, but I can't seem > > to do it. > > A possible way could (maybe) be to 'trick' the pager into thinking it > > has less space left to draw the tabs, and that could possibly be > > achieved using update_positions(), although I am having some problems > > with that. > > Or maybe just tweaking the value. After all it's a workaround. > > > The second problem is a minor one, but annoying. I believe when CSS > > rendering is triggered, the render area flickers and that is normal. > > However, the way I implemented this (probably because of it being in > > handle()) makes the Button also flash. > > A side affect of being a child of UI. > So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically. Jo?o

Feb. 2, 2009

Address Bar Text Clears

by corvid＠lavabit.com

Calvin wrote: > open up a website, make sure to pick one that loads slowly and to type > it in the address bar. as it's loading open up a new tab, now click > back. the URL in the address bar field is empty. Hmm...I can't seem to get this to break. Is this the 2.0 release or the current tree? Suitably recent FLTK2 snapshot? Are you running on OSX by any chance?

Feb. 2, 2009

[patch]: fix signature of Html_add_new_linkimage()

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 08:45:06PM +0000, Jeremy Henty wrote: > > A small cleanup patch. > > * The return value of Html_add_new_linkimage() is never used, so it > should return void. Committed this part. > > * There's no need to pass the url to Html_add_new_linkimage() as a > (DilloUrl **), so just copy the (DilloUrl *) pointer. It's used to emphasize the url parameter changes owner. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 2, 2009

Address Bar Text Clears

by crazycal00＠gmail.com

Hi, Found kind of a bug but dunno if it really counts as one so i figured i'd run it past the mailing list first. open up a website, make sure to pick one that loads slowly and to type it in the address bar. as it's loading open up a new tab, now click back. the URL in the address bar field is empty. just thought i'd share. Calvin

Feb. 1, 2009

FIELDSET element

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 06:05:09PM -0300, Jorge Arellano Cid wrote: > Hi, > > Now that we have align in CSS, it may be easy to add support > for the FIELDSET element: > > http://www.w3.org/TR/html401/interact/forms.html#h-17.10 This is not an urgent matter. I just noticed BUG#720 while updating the bug tracker. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

FIELDSET element

by jcid＠dillo.org

Hi, Now that we have align in CSS, it may be easy to add support for the FIELDSET element: http://www.w3.org/TR/html401/interact/forms.html#h-17.10 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

[patch]: fix signature of Html_add_new_linkimage()

by onepoint＠starurchin.org

A small cleanup patch. * The return value of Html_add_new_linkimage() is never used, so it should return void. * There's no need to pass the url to Html_add_new_linkimage() as a (DilloUrl **), so just copy the (DilloUrl *) pointer. Regards, Jeremy Henty

Feb. 1, 2009

Bad character coding for www.blisty.cz

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 07:45:39PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > > Michal wrote: > > > > > Hi, > > > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > > following sence (it's in Czech) > > > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > > > but in current hg tip it's displayed as > > > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > > was changed. > > > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > > > 1) remove the ~/.dillo directory > > > > > 2) dillo www.blisty.cz > > > > > 3) --> PASS > > > > > 4) quit dillo > > > > > 5) dillo www.blisty.cz > > > > > 6) --> FAIL > > > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > > reproducible and, perhaps, fix it? :) > > > > > > > > Breaks for me, too. > > > > > > > > Plus having to wait through 116K of download before anything > > > > appears is no fun. > > > > > > It works for me! :-) > > > > > > Seriously, I still have a pending item to review here, and it's > > > when charset appears after the stylesheet in HEAD. This page also > > > has timing issues: http://www.daemonnews.org > > > > > > It looks like queueing the stylesheets and asking for them > > > after charset or at head close may fix it. > > > > Does anyone else experience pages not rendering until > > download is complete? I see this with the dillo.org > > pages, for instance, since the meta charset is iso-8859-1. > > Yes, I'm also seeing it. Not sure when this started. According to hg bisect it starts with d29cdb5b842e, but I don't see any obvious issues there. Jorge, can you have a look please? Cheers, Johannes

Feb. 1, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > I was just looking at some of the prefs that I > don't think are doing anything right now, e.g., > link_color, force_my_colors... > I could stuff them into buildUserStyle(), but > I don't know which should prevail in case of > conflicts. > > I can't remember whether I've already mentioned that > I've been wondering whether it might be reasonable to > rip a bunch of color stuff out of dillorc and expect > a dillo user to be able to deal with a well-commented > sample style.css instead. Good point. I always favor simplicity so I think we should have just one way to modify the style. Having two (style.css and preferences) just adds confusion. We need to document this properly as you said. Johannes

Feb. 1, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

I was just looking at some of the prefs that I don't think are doing anything right now, e.g., link_color, force_my_colors... I could stuff them into buildUserStyle(), but I don't know which should prevail in case of conflicts. I can't remember whether I've already mentioned that I've been wondering whether it might be reasonable to rip a bunch of color stuff out of dillorc and expect a dillo user to be able to deal with a well-commented sample style.css instead.

Feb. 1, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 07:20:58PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 05:57:59PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > agree? What's left to be done? > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > but we won't pass any ACID test soon anyway. > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > help on that is very welcome :-). > > > > That reminds me, it would be good to add some checking for > > malicious values before release. > > Yes, I think stylengine.cc would be the right place. > Maybe we can add some generic checks and remove the ones in html.cc > - this needs to be checked. > We also need to give cssparser.cc a thorough look regarding potential > buffer overflows... At some point in time the whole browser will need a check against malicious/random data. The dillo-2.x process has been focused on features. I agree that the CSS part needs a review before release. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

[Patch]: [v2]: fix URL leak in Html_tag_open_link()

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 07:15:43PM +0100, Hofmann Johannes wrote: > On Sun, Feb 01, 2009 at 02:18:10PM -0300, Jorge Arellano Cid wrote: > > On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > > > > > OK, I'm fairly sure this version is not as utterly broken as the > > > previous one. :-) > > > > Committed > > (with just a small change) > > > > > > > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > > > preference twice? > > > > The repush scheme include parsing the HTML header twice. > > (not a big deal). > > I think Jeremy is referring to > > if (!prefs.load_stylesheets) > return; > > in Html_tag_open_link() which seems redundant, as there is > > /* Remote stylesheets enabled? */ > dReturn_if_fail (prefs.load_stylesheets); > > some lines above. Oh, Yes! Committed. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

Bad character coding for www.blisty.cz

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 03:53:32PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > > Michal wrote: > > > > Hi, > > > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > > following sence (it's in Czech) > > > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > > > but in current hg tip it's displayed as > > > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > > was changed. > > > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > > > 1) remove the ~/.dillo directory > > > > 2) dillo www.blisty.cz > > > > 3) --> PASS > > > > 4) quit dillo > > > > 5) dillo www.blisty.cz > > > > 6) --> FAIL > > > > > > > > Can anyone, please, have a look at this and say whether is it > > > > reproducible and, perhaps, fix it? :) > > > > > > Breaks for me, too. > > > > > > Plus having to wait through 116K of download before anything > > > appears is no fun. > > > > It works for me! :-) > > > > Seriously, I still have a pending item to review here, and it's > > when charset appears after the stylesheet in HEAD. This page also > > has timing issues: http://www.daemonnews.org > > > > It looks like queueing the stylesheets and asking for them > > after charset or at head close may fix it. > > Does anyone else experience pages not rendering until > download is complete? I see this with the dillo.org > pages, for instance, since the meta charset is iso-8859-1. Yes, I'm also seeing it. Not sure when this started.

Feb. 1, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 05:57:59PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > agree? What's left to be done? > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > but we won't pass any ACID test soon anyway. > > I'd like to get the font-size issue on wikipedia.org fixed however - > > help on that is very welcome :-). > > That reminds me, it would be good to add some checking for > malicious values before release. Yes, I think stylengine.cc would be the right place. Maybe we can add some generic checks and remove the ones in html.cc - this needs to be checked. We also need to give cssparser.cc a thorough look regarding potential buffer overflows... Cheers, Johannes

Feb. 1, 2009

Refactored prefs.c to a much smaller size!

by Johannes.Hofmann＠gmx.de

Excellent!

Feb. 1, 2009