- Dillo-dev - lists.mailman3.com

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

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

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

Feb. 1, 2009

What's left to do for dillo-2.1?

by corvid＠lavabit.com

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.

Feb. 1, 2009

Close-tab Button

by jcid＠dillo.org

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. -- 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: 30x response without Location == segfault

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 05:45:43AM +0000, corvid wrote: > (new bug #886) > The submitter got a 300 Multiple Choices > without a Location header. > > from the RFC, > If the server has a preferred choice of representation, it SHOULD > include the specific URI for that representation in the Location > field; user agents MAY use the Location field value for automatic > redirection. > and > Unless it was a HEAD request, the response SHOULD include an entity > containing a list of resource characteristics and location(s) from > which the user or user agent can choose the one most appropriate. > > In this case, http://www.weather.gov/data/current_obs/PAFC.xml > had no Location, and does have a body consisting of an > HTML page giving alternatives. > > PS I think it might become more common for users to encounter > Multiple Choices now that there's a pref for Accept-Language. Committed. Please update 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

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

by jcid＠dillo.org

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