- Dillo-dev - lists.mailman3.com

patch: 30x response without Location == segfault

by corvid＠lavabit.com

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

Feb. 1, 2009

Bad character coding for www.blisty.cz

by corvid＠lavabit.com

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.

Feb. 1, 2009

[Patch]: fix URL leak in Html_tag_open_link()

by onepoint＠starurchin.org

If Html_tag_open_link() gets a link that it decides not to use because of the media attribute, it returns without freeing the URL object it just created. The fix is to postpone creating the URL until after all the checks that might cause the function to return. Patch and test case attached. Regards, Jeremy Henty

Feb. 1, 2009

Close-tab Button

by jorl17.8＠gmail.com

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? It is functional, only you can say if it fully suits Dillo's needs though. 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. 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. Thanks, Jo?o

Feb. 1, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 06:15:50PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > > On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > > > Johannes wrote: > > > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > > > * {font-family: sans !important} > > > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > > > So this should work. > > > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > > > > > Does it work for you? > > > > > > > > > > > > > > Yes, I tried: > > > > > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > > > * {color: red !important} > > > > > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > > > > > All red for me. > > > > > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > > > much except forms code in my tree right now. > > > > > > Still all red. > > > > > > > > > > > > How strange that we would see different behaviour here... > > > > > > I guess I'll have to dive into the code myself... > > > > > > > > > > Please check again with attached patch. > > > > > > > > It's working! > > > > Thanks! Excellent customer service :) > > > > > > It's not the proper solution though. > > > Here's the plan to apply rules according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > > > > > * For each CssRule compute the specificity according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > * Store the rules in RuleList sorted by this specificity. > > > > > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > > > potentially matching rules and apply them in the order given by > > > their specificity. > > > > > > If anyone feels like implementing it - go ahead :) > > > > Just implemented that. Please test. > > I don't know what to test but there're > rendering differences with this page: > > http://www.thefreedictionary.com/unneeded > > (comparing with 83d840739a0e as tip) > > HTH. Well, rendering differences are the point here :) For example on cnn.com you can now read the "Home" white on red background, which was red on red before. Thanks for testing, Johannes

Jan. 31, 2009

Bad character coding for www.blisty.cz

by newman.x＠gmail.com

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? :) Thanks, -- Regards, Michal Nowak

Jan. 31, 2009

Window icon

by jcid＠dillo.org

Hi, Does anyone feel like hooking the small dillo icon to its window? http://fltk.org/newsgroups.php?s18335+gfltk.general+v18348+T1 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

CSS branch merged!

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > > * {font-family: sans !important} > > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > > So this should work. > > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > > > Does it work for you? > > > > > > > > > > > > Yes, I tried: > > > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > > * {color: red !important} > > > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > > > All red for me. > > > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > > much except forms code in my tree right now. > > > > > Still all red. > > > > > > > > > > How strange that we would see different behaviour here... > > > > > I guess I'll have to dive into the code myself... > > > > > > > > Please check again with attached patch. > > > > > > It's working! > > > Thanks! Excellent customer service :) > > > > It's not the proper solution though. > > Here's the plan to apply rules according to > > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > > > * For each CssRule compute the specificity according to > > http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > * Store the rules in RuleList sorted by this specificity. > > > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > > potentially matching rules and apply them in the order given by > > their specificity. > > > > If anyone feels like implementing it - go ahead :) > > Just implemented that. Please test. I don't know what to test but there're rendering differences with this page: http://www.thefreedictionary.com/unneeded (comparing with 83d840739a0e as tip) HTH. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 06:53:47PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 02:38:47PM -0300, Jorge Arellano Cid wrote: > > On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann 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 :-). > > > > > > > > Ah!, and there's the very important issue of the visited link color. > > > > When coming back to a page, most of the time visited links aren't shown > > > > as such (i.e. drawn in visited color). > > > > > > Do you have an example? CSS allows to specify the visited link > > > color, so it may just have been set by the author to something > > > unexpected. > > > > http://www.linux.org.uk/Portaloo.cs > > > > (but as you said, this one sets to the same color). > > > > http://www.lacuarta.cl > > > > If you click on a red headline and come back, the color is the same. > > I don't know what color is visited set to. > > Yes, that's expected. They set the color for visited links. > firefox also shows them in red. > > > > > > Does > > > > > > :visited {color: #800080 !important} > > > > > > in .dillo/style.css fix the problem? > > > > Yes. > > > > It always shows the same visited-color, but is much better than > > without. Personally, I like best something like the old "contrast > > visited color" ;) > > That's problematic. I don't know how to express this in CSS and > hacking this around CSS seems ugly. > Maybe adding some special dillo specific CSS extension would be > possible. > But before doing that we should make sure that it really can't be > done with standard CSS. Also we should check what other browsers do. Yes. In its current state: :visited {color: #800080 !important} is enough for a release. Maybe in the future we can modify the custom dillo stylesheet with a computed visited color, on-the-fly for each page. Is that possible? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 02:38:47PM -0300, Jorge Arellano Cid wrote: > On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann 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 :-). > > > > > > Ah!, and there's the very important issue of the visited link color. > > > When coming back to a page, most of the time visited links aren't shown > > > as such (i.e. drawn in visited color). > > > > Do you have an example? CSS allows to specify the visited link > > color, so it may just have been set by the author to something > > unexpected. > > http://www.linux.org.uk/Portaloo.cs > > (but as you said, this one sets to the same color). > > http://www.lacuarta.cl > > If you click on a red headline and come back, the color is the same. > I don't know what color is visited set to. Yes, that's expected. They set the color for visited links. firefox also shows them in red. > > > Does > > > > :visited {color: #800080 !important} > > > > in .dillo/style.css fix the problem? > > Yes. > > It always shows the same visited-color, but is much better than > without. Personally, I like best something like the old "contrast > visited color" ;) That's problematic. I don't know how to express this in CSS and hacking this around CSS seems ugly. Maybe adding some special dillo specific CSS extension would be possible. But before doing that we should make sure that it really can't be done with standard CSS. Also we should check what other browsers do. Cheers, Johannes

Jan. 31, 2009