- Dillo-dev - lists.mailman3.com

dillo CSS and charset

by furaisanjin＠gmail.com

Hi. 2009/1/23 Jorge Arellano Cid <jcid(a)dillo.org>: >> Have you added charset to the content-type given by the bookmarks dpi? >> or have you added a META or both? I did hg revert cache.c to cancel my local modification and then built dillo again. However I can't reproduce the problem anymore. I don't add content-type on dpi nor meta on bookmark because if encoding type is UTF-8, no conversion is required. I assume dillo native encoding is UTF-8 now. Sorry for confusion. Please ignore bookmark problem. Regards, furaisanjin

Jan. 22, 2009

Valgrind errors

by onepoint＠starurchin.org

I've been valgrinding Dillo to see what I find and this one keeps turning up. Some memory is accessed that was freed by a_Cache_set_content_type(). Regards, Jeremy Henty

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

On Thu, Jan 22, 2009 at 06:53:46PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote: > > > Johannes wrote: > > > > BTW. now you can set vw_fontname in dillorc again. This font will > > > > then be used when CSS specifies "sans" as font, e.g: > > > > vw_fontname="VL Gothic" > > > > > > If I put a serif font in vw_fontname and then use > > > sans in style.css for some things, it'll use > > > the serif font. > > > > True. We need to make new config options > > > > sans-serif_fontname > > serif_fontname > > cursive_fontname > > fantasy_fontname > > monospace_fontname > > > > maybe even dropping the "_fontname" suffix. > > > > But of course that would no longer be compatible with older > > versions of dillorc. > > I would add the new options and remove the old options. > CSS is big and certainly worth some incompatibility. Ok, attached is a patch for discussion. Cheers, Johannes > > Related to this, I've been wondering whether we should have > a policy about the dillorc on the website -- whether it should > follow tip, or follow the most recent release, or always add > new options but never delete old options... > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 22, 2009

[patch]: fix DBG build of table.cc

by jcid＠dillo.org

On Sat, Jan 17, 2009 at 06:53:13PM +0000, Jeremy Henty wrote: > > If you uncomment the #define of DBG in table.cc it won't compile. It > looks as though most of the DBG code was fixed not to use the > non-existent "result" variable, but one instance was left unchanged. > Patch attached. Committed. -- Cheers Jorge.-

Jan. 22, 2009

Crashes in dw::core::Layout::createImgbuf()

by onepoint＠starurchin.org

On Tue, Jan 20, 2009 at 07:33:41PM +0100, Hofmann Johannes wrote: > Can you try to use "hg bisect" to find the changeset where the error > was introduced? I know it's difficult with sporadic errors... I was hoping to avoid that, as it would probably be awfully tedious. I'll give it a go if nothing else works. > Or maybe try valgrind? I've given it a few quick runs under valgrind but seen nothing helpful. Maybe I should just run it under valgrind continually. It's lucky Dillo is fast! Imagine trying to do that with Firefox. Regards, Jeremy Henty

Jan. 22, 2009

dillo CSS and charset

by jcid＠dillo.org

On Thu, Jan 22, 2009 at 12:24:41PM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 22, 2009 at 11:06:01PM +0900, furaisanjin wrote: > > 2009/1/22 furaisanjin <furaisanjin(a)gmail.com>: > > > By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has > > > this problem? > > > > bookmark problem is solved by this patch. > > > > --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 > > +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 > > @@ -512,8 +512,10 @@ > > if (entry->CharsetDecoder) > > a_Decode_free(entry->CharsetDecoder); > > a_Misc_parse_content_type(ctype, NULL, NULL, &charset); > > - entry->CharsetDecoder = a_Decode_charset_init(charset); > > - dFree(charset); > > + if (charset) { > > + entry->CharsetDecoder = a_Decode_charset_init(charset); > > + dFree(charset); > > + } > > curr = Cache_current_content_type(entry); > > > > /* Invalidate UTF8Data */ > > Have you added charset to the content-type given by the bookmarks dpi? > or have you added a META or both? > > I would like to know the problem in detail, because it looks like > adding an extra parameter to a_Cache_set_content_type() would make > its API, and code cleaner. e.g. ({CA_Header|CA_Meta} as last parameter). > > If the problem can be solved with that API change, great, hence > the above question. Does something like the attached patch solve the problem? -- Cheers Jorge.-

Jan. 22, 2009

dillo CSS and charset

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote: > > Johannes wrote: > > > BTW. now you can set vw_fontname in dillorc again. This font will > > > then be used when CSS specifies "sans" as font, e.g: > > > vw_fontname="VL Gothic" > > > > If I put a serif font in vw_fontname and then use > > sans in style.css for some things, it'll use > > the serif font. > > True. We need to make new config options > > sans-serif_fontname > serif_fontname > cursive_fontname > fantasy_fontname > monospace_fontname > > maybe even dropping the "_fontname" suffix. > > But of course that would no longer be compatible with older > versions of dillorc. I would add the new options and remove the old options. CSS is big and certainly worth some incompatibility. Related to this, I've been wondering whether we should have a policy about the dillorc on the website -- whether it should follow tip, or follow the most recent release, or always add new options but never delete old options...

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

On Thu, Jan 22, 2009 at 05:57:42PM +0000, corvid wrote: > Johannes wrote: > > BTW. now you can set vw_fontname in dillorc again. This font will > > then be used when CSS specifies "sans" as font, e.g: > > vw_fontname="VL Gothic" > > If I put a serif font in vw_fontname and then use > sans in style.css for some things, it'll use > the serif font. True. We need to make new config options sans-serif_fontname serif_fontname cursive_fontname fantasy_fontname monospace_fontname maybe even dropping the "_fontname" suffix. But of course that would no longer be compatible with older versions of dillorc. Opinions? Cheers, Johannes

Jan. 22, 2009

dillo CSS and charset

by corvid＠lavabit.com

Johannes wrote: > BTW. now you can set vw_fontname in dillorc again. This font will > then be used when CSS specifies "sans" as font, e.g: > vw_fontname="VL Gothic" If I put a serif font in vw_fontname and then use sans in style.css for some things, it'll use the serif font.

Jan. 22, 2009

dillo CSS and charset

by jcid＠dillo.org

On Thu, Jan 22, 2009 at 11:06:01PM +0900, furaisanjin wrote: > 2009/1/22 furaisanjin <furaisanjin(a)gmail.com>: > > By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has > > this problem? > > bookmark problem is solved by this patch. > > --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 > +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 > @@ -512,8 +512,10 @@ > if (entry->CharsetDecoder) > a_Decode_free(entry->CharsetDecoder); > a_Misc_parse_content_type(ctype, NULL, NULL, &charset); > - entry->CharsetDecoder = a_Decode_charset_init(charset); > - dFree(charset); > + if (charset) { > + entry->CharsetDecoder = a_Decode_charset_init(charset); > + dFree(charset); > + } > curr = Cache_current_content_type(entry); > > /* Invalidate UTF8Data */ Have you added charset to the content-type given by the bookmarks dpi? or have you added a META or both? I would like to know the problem in detail, because it looks like adding an extra parameter to a_Cache_set_content_type() would make its API, and code cleaner. e.g. ({CA_Header|CA_Meta} as last parameter). If the problem can be solved with that API change, great, hence the above question. BTW AFAIS, with the above patch if CharsetDecoder was already set, and a_Misc_parse_content_type() fails, CharsetDecoder is left in an unknown state. -- Cheers Jorge.-

Jan. 22, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

2009/1/22 furaisanjin <furaisanjin(a)gmail.com>: > By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has > this problem? bookmark problem is solved by this patch. --- a/src/cache.c Thu Jan 22 08:31:44 2009 -0300 +++ b/src/cache.c Thu Jan 22 23:03:33 2009 +0900 @@ -512,8 +512,10 @@ if (entry->CharsetDecoder) a_Decode_free(entry->CharsetDecoder); a_Misc_parse_content_type(ctype, NULL, NULL, &charset); - entry->CharsetDecoder = a_Decode_charset_init(charset); - dFree(charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + dFree(charset); + } curr = Cache_current_content_type(entry); /* Invalidate UTF8Data */ Regards, furaisanjin

Jan. 22, 2009

switch to DILLO_HTML_PARSE_MODE_PRE depending on style

by Johannes.Hofmann＠gmx.de

Hi, I'm experimenting with attached patch to make switching to DILLO_HTML_PARSE_MODE_PRE from CSS possible. Some online source browsers like cgit (http://hjemli.net/git/cgit/) use this to display sources or diffs. Please comment. Cheers, Johannes

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

On Thu, Jan 22, 2009 at 08:34:32AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote: > > Hi, > > > > On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote: > > > > Hi. > > > > > > > > This is work around. > > > > > > This so called "work around" works very well. > > > > > > While working on this, I used the testcases in the following table: > > > > > > > > > load Reload Back > > > ---------------------------- > > > H__ OK OK OK H = has charset in HTTP header > > > HM_ OK OK OK M = has charset in META > > > H_C OK OK OK C = has remote CSS stylesheet > > > HMC OK OK OK _ = disabled > > > ___ OK OK OK > > > _M_ OK OK OK > > > __C OK OK OK > > > _MC OK OK OK > > > ---------------------------- > > > > > > Both patches pass all of them! > > > > > > I committed a similar approach that has a single code path for > > > calling a_Decode_charset_init(). > > > > > > Please test and comment. > > > > Starting with revision d29cdb5b842e I get repeatable crashes when > > clicking on the "Home" link in about:splash. > > Please try the current tip. I noticed one more issue, still present in tip. On http://amazon.de dillo crashes with: Program terminated with signal 11, Segmentation fault. b#0 0x08069f2e in Html_write_raw (html=0x2866f500, buf=0x2874303d <Address 0x2874303d out of bounds>, bufsize=33743, Eof=0) at html.cc:3398 3398 if (*start == '/' || /* </x> */ (gdb) bt #0 0x08069f2e in Html_write_raw (html=0x2866f500, buf=0x2874303d <Address 0x2874303d out of bounds>, bufsize=33743, Eof=0) at html.cc:3398 #1 0x0806a53a in DilloHtml::write (this=0x2866f500, Buf=0x28743000 <Address 0x28743000 out of bounds>, BufSize=675537188, Eof=0) at html.cc:577 #2 0x0806a58e in Html_callback (Op=0, Client=0x2862ea40) at html.cc:3564 #3 0x0805a706 in Cache_process_queue (entry=0x28653700) at cache.c:1143 #4 0x08058288 in a_Chain_fcb (Op=675537188, Info=0x1, Data1=0x286b8210, Data2=0x80f573c) at chain.c:112 #5 0x0807899c in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x2862e400, Data1=0x286b8c20, Data2=0x0) at dpi.c:219 #6 0x08058288 in a_Chain_fcb (Op=675537188, Info=0x1, Data1=0x286b8c20, Data2=0x0) at chain.c:112 #7 0x08079311 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x2862ee20, Data1=0x2862e4a0, Data2=0x0) at IO.c:414 #8 0x0807949e in IO_callback (io=0x2862e4a0) at IO.c:201 #9 0x0807956f in IO_fd_read_cb (fd=4, data=0x4) at IO.c:287 #10 0x080c9fd5 in fltk::wait () #11 0x080ca185 in fltk::run () #12 0x0804f03a in main (argc=2, argv=0xbfbff850) at dillo.cc:334 Cheers, Johannes

Jan. 22, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi, 2009/1/22 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > On Thu, Jan 22, 2009 at 09:18:00PM +0900, furaisanjin wrote: > However looking at japanese pages, it seems that word wrapping is > still an issue, see: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005427.html > > Do you have an idea about a possible solution? No, I don't think there is good solution but I added these code in html.cc. --- a/src/html.cc Thu Jan 22 08:31:44 2009 -0300 +++ b/src/html.cc Thu Jan 22 21:33:56 2009 +0900 @@ -58,6 +58,8 @@ #define TAB_SIZE 8 +#define UTF8_NONE_1WORD(x) ((x)&0x80) + /*----------------------------------------------------------------------------- * Name spaces *---------------------------------------------------------------------------*/ @@ -111,6 +113,7 @@ DilloImage *image); static void Html_callback(int Op, CacheClient_t *Client); static void Html_tag_cleanup_at_close(DilloHtml *html, int TagIdx); +static int Html_utf8_size (char c); /*----------------------------------------------------------------------------- * Local Data @@ -1117,6 +1120,7 @@ { int i, j, start; char *Pword, ch; + int utf8size; DilloHtmlParseMode parse_mode = S_TOP(html)->parse_mode; if (parse_mode == DILLO_HTML_PARSE_MODE_STASH || @@ -1159,7 +1163,20 @@ } else { if (!memchr(word,'&', size)) { /* No entities */ - DW2TB(html->dw)->addText(word, html->styleEngine->wordStyle ()); + for (start = 0; start < (int) strlen (word); ) { + if (UTF8_NONE_1WORD(word[start])) { + utf8size = Html_utf8_size (word[start]); + DW2TB(html->dw)->addText(dStrndup(&word[start],utf8size), html->styleEngine->wordStyle()); + start += utf8size; + } else { + for (i=0; i < (int) strlen (word)-start; i++) { + if (UTF8_NONE_1WORD(word[start+i])) + break; + } + DW2TB(html->dw)->addText(dStrndup(&word[start],i), html->styleEngine->wordStyle()); + start += i; + } + } } else { /* Collapse white-space entities inside the word (except  ) */ Pword = a_Html_parse_entities(html, word, size); @@ -1167,7 +1184,20 @@ if (strchr("\t\f\n\r", Pword[i])) for (j = i; (Pword[j] = Pword[j+1]); ++j) ; - DW2TB(html->dw)->addText(Pword, html->styleEngine->wordStyle ()); + for (start = 0; start < (int) strlen (Pword); ) { + if (UTF8_NONE_1WORD(Pword[start])) { + utf8size = Html_utf8_size (Pword[start]); + DW2TB(html->dw)->addText(dStrndup(&Pword[start],utf8size), html->styleEngine->wordStyle()); + start += utf8size; + } else { + for (i=0; i < (int) strlen (Pword)-start; i++) { + if (UTF8_NONE_1WORD(Pword[start+i])) + break; + } + DW2TB(html->dw)->addText(dStrndup(&Pword[start],i), html->styleEngine->wordStyle()); + start += i; + } + } dFree(Pword); } } @@ -3700,4 +3730,20 @@ return token_start; } +static int Html_utf8_size (char c) +{ + if ((c&0xfc) == 0xfc) + return 6; + if ((c&0xf8) == 0xf8) + return 5; + if ((c&0xf0) == 0xf0) + return 4; + if ((c&0xe0) == 0xe0) + return 3; + if ((c&0xc0) == 0xc0) + return 2; + return 1; +} + Then dillo appearance is something I mentioned here. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005430.html By the way I notice bookmark (ctrl-b) doesn't work. Does anybody has this problem? Regards, furaisanjin

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

On Thu, Jan 22, 2009 at 09:18:00PM +0900, furaisanjin wrote: > Hi. > > And charset conversion works fine. BTW. now you can set vw_fontname in dillorc again. This font will then be used when CSS specifies "sans" as font, e.g: vw_fontname="VL Gothic" However looking at japanese pages, it seems that word wrapping is still an issue, see: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-November/005427.html Do you have an idea about a possible solution? Cheers, Johannes

Jan. 22, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi. And charset conversion works fine. Regards, furaisanjin

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

On Thu, Jan 22, 2009 at 08:34:32AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote: > > Hi, > > > > On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote: > > > > Hi. > > > > > > > > This is work around. > > > > > > This so called "work around" works very well. > > > > > > While working on this, I used the testcases in the following table: > > > > > > > > > load Reload Back > > > ---------------------------- > > > H__ OK OK OK H = has charset in HTTP header > > > HM_ OK OK OK M = has charset in META > > > H_C OK OK OK C = has remote CSS stylesheet > > > HMC OK OK OK _ = disabled > > > ___ OK OK OK > > > _M_ OK OK OK > > > __C OK OK OK > > > _MC OK OK OK > > > ---------------------------- > > > > > > Both patches pass all of them! > > > > > > I committed a similar approach that has a single code path for > > > calling a_Decode_charset_init(). > > > > > > Please test and comment. > > > > Starting with revision d29cdb5b842e I get repeatable crashes when > > clicking on the "Home" link in about:splash. > > Please try the current tip. Yes, it's fixed! Cheers, Johannes

Jan. 22, 2009

dillo CSS and charset

by jcid＠dillo.org

On Thu, Jan 22, 2009 at 10:22:39AM +0100, Hofmann Johannes wrote: > Hi, > > On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote: > > > Hi. > > > > > > This is work around. > > > > This so called "work around" works very well. > > > > While working on this, I used the testcases in the following table: > > > > > > load Reload Back > > ---------------------------- > > H__ OK OK OK H = has charset in HTTP header > > HM_ OK OK OK M = has charset in META > > H_C OK OK OK C = has remote CSS stylesheet > > HMC OK OK OK _ = disabled > > ___ OK OK OK > > _M_ OK OK OK > > __C OK OK OK > > _MC OK OK OK > > ---------------------------- > > > > Both patches pass all of them! > > > > I committed a similar approach that has a single code path for > > calling a_Decode_charset_init(). > > > > Please test and comment. > > Starting with revision d29cdb5b842e I get repeatable crashes when > clicking on the "Home" link in about:splash. Please try the current tip. -- Cheers Jorge.-

Jan. 22, 2009

dillo CSS and charset

by Johannes.Hofmann＠gmx.de

Hi, On Wed, Jan 21, 2009 at 07:06:06PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote: > > Hi. > > > > This is work around. > > This so called "work around" works very well. > > While working on this, I used the testcases in the following table: > > > load Reload Back > ---------------------------- > H__ OK OK OK H = has charset in HTTP header > HM_ OK OK OK M = has charset in META > H_C OK OK OK C = has remote CSS stylesheet > HMC OK OK OK _ = disabled > ___ OK OK OK > _M_ OK OK OK > __C OK OK OK > _MC OK OK OK > ---------------------------- > > Both patches pass all of them! > > I committed a similar approach that has a single code path for > calling a_Decode_charset_init(). > > Please test and comment. Starting with revision d29cdb5b842e I get repeatable crashes when clicking on the "Home" link in about:splash. Cheers, Johannes Program received signal SIGBUS, Bus error. DilloHtml::getCurTagLineNumber (this=0x28778500) at html.cc:596 596 if (p[i] == '\n') (gdb) bt #0 DilloHtml::getCurTagLineNumber (this=0x28778500) at html.cc:596 #1 0x08063e38 in DilloHtml::bugMessage (this=0x28778500, format=0x80f8198 "HEAD section lacks the TITLE element\n") at html.cc:149 #2 0x08063f2a in Html_tag_close_head (html=0x28778500, TagIdx=32) at html.cc:1569 #3 0x080684de in Html_tag_cleanup_at_close (html=0x28778500, TagIdx=32) at html.cc:1306 #4 0x08068957 in DilloHtml::finishParsing (this=0x28778500, ClientKey=2) at html.cc:627 #5 0x0805a566 in Cache_process_queue (entry=0x287418c0) at cache.c:1153 #6 0x0805b378 in a_Cache_process_dbuf (Op=2, buf=0x0, buf_size=0, Url=0x28741c80) at cache.c:886 #7 0x0805c871 in a_Capi_ccc (Op=4, Branch=2, Dir=1, Info=0x2874fd60, Data1=0x0, Data2=0x0) at capi.c:618 #8 0x08058288 in a_Chain_fcb (Op=0, Info=0x287a3000, Data1=0x0, Data2=0x0) at chain.c:112 #9 0x08078cee in a_Dpi_ccc (Op=4, Branch=2, Dir=1, Info=0x2874f140, Data1=0x0, Data2=0x0) at dpi.c:671 #10 0x08058288 in a_Chain_fcb (Op=0, Info=0x287a3000, Data1=0x0, Data2=0x0) at chain.c:112 #11 0x0807969e in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x2874f6c0, Data1=0x2874f8c0, Data2=0x0) ---Type <return> to continue, or q <return> to quit--- ---Type <return> to continue, or q <return> to quit--- at IO.c:418 #12 0x08079980 in IO_callback (io=0x2874f8c0) at IO.c:211 #13 0x080799ff in IO_fd_read_cb (fd=7, data=0x2) at IO.c:287 #14 0x080ca465 in fltk::wait () #15 0x080ca615 in fltk::run () #16 0x0804f03a in main (argc=1, argv=0xbfbff864) at dillo.cc:334 (gdb)

Jan. 22, 2009

[bug]: hang in Css_parse_delaration()

by onepoint＠starurchin.org

On Wed, Jan 21, 2009 at 09:41:45PM +0100, Hofmann Johannes wrote: > On Wed, Jan 21, 2009 at 04:49:27PM +0000, Jeremy Henty wrote: > > > > A simple example that hangs the CSS parser. > Please check current tip. It's fixed! > The page is still not looking pretty, That's OK. Dillo is not responsible for the ugliness of the world! ;-) Regards, Jeremy Henty

Jan. 22, 2009

dillo CSS and charset

by jcid＠dillo.org

On Wed, Jan 21, 2009 at 08:29:34PM +0900, furaisanjin wrote: > Hi. > > This is work around. This so called "work around" works very well. While working on this, I used the testcases in the following table: load Reload Back ---------------------------- H__ OK OK OK H = has charset in HTTP header HM_ OK OK OK M = has charset in META H_C OK OK OK C = has remote CSS stylesheet HMC OK OK OK _ = disabled ___ OK OK OK _M_ OK OK OK __C OK OK OK _MC OK OK OK ---------------------------- Both patches pass all of them! I committed a similar approach that has a single code path for calling a_Decode_charset_init(). Please test and comment. -- Cheers Jorge.-

Jan. 21, 2009

[bug]: hang in Css_parse_delaration()

by Johannes.Hofmann＠gmx.de

On Wed, Jan 21, 2009 at 04:49:27PM +0000, Jeremy Henty wrote: > > A simple example that hangs the CSS parser. The contents of the css > block are the critical thing: it doesn't seem to matter what the > selector is but changing either the parameter or the value inside the > block stops the hang. After aborting the stack trace varies, but > always seems to be inside Css_parse_declaration(). (I've attached > some example stacks.) > > The real-world page that triggered the bug: > > http://dialinf.wordpress.com/2009/01/21/ultraproducts-the-category-theoreti… Please check current tip. The page is still not looking pretty, but it no longer hangs. Cheers, Johannes

Jan. 21, 2009

[bug]: hang in Css_parse_delaration()

by onepoint＠starurchin.org

A simple example that hangs the CSS parser. The contents of the css block are the critical thing: it doesn't seem to matter what the selector is but changing either the parameter or the value inside the block stops the hang. After aborting the stack trace varies, but always seems to be inside Css_parse_declaration(). (I've attached some example stacks.) The real-world page that triggered the bug: http://dialinf.wordpress.com/2009/01/21/ultraproducts-the-category-theoreti… Regards, Jeremy Henty

Jan. 21, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi. This is work around. 1) HTTP server and meta have charset. One example is http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-O… diff -r a0230b2a4a32 src/cache.c --- a/src/cache.c Fri Jan 16 14:45:17 2009 -0300 +++ b/src/cache.c Wed Jan 21 20:21:49 2009 +0900 @@ -628,6 +628,7 @@ { char *header = entry->Header->str; char *Length, *Type, *location_str, *encoding; + char *charset; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -753,6 +754,13 @@ entry->TypeHdr = Type; _MSG("TypeHdr {%s} {%s}\n", Type, URL_STR(entry->Url)); _MSG("TypeMeta {%s}\n", entry->TypeMeta); + a_Misc_parse_content_type(Type, NULL, NULL, &charset); + if (charset) { + entry->CharsetDecoder = a_Decode_charset_init(charset); + if (entry->CharsetDecoder) + entry->UTF8Data = dStr_new(""); + dFree(charset); + } } } 2) Only meta has charset. One example is http://www.picfun.com/app00.html diff -r a0230b2a4a32 src/html.cc --- a/src/html.cc Fri Jan 16 14:45:17 2009 -0300 +++ b/src/html.cc Wed Jan 21 20:22:00 2009 +0900 @@ -2789,6 +2789,7 @@ * this code in another bw might have already changed it for us. */ if (a_Misc_content_type_cmp(html->content_type, new_content)) { + html->stop_parser = true; html->repush_after_head = true; } } Regards, furaisanjin

Jan. 21, 2009

Crashes in dw::core::Layout::createImgbuf()

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Tue, Jan 20, 2009 at 06:20:32PM +0000, Jeremy Henty wrote: > > For the last few days I have been getting occasional crashes inside > dw::core::Layout::createImgbuf() when opening a new tab. It does not > seem to be predictable: if I restart Dillo and reopen all the URLs I > was just looking at it is fine. > > The gdb backtrace often shows ridiculous values for this: eg. the > attached example has this=0x6. I've seen other impossibly small > values for this, but sometimes the value seems more sensible. > > Any ideas? I'd like to investigate further but I don't know what to > look for. Pointers are welcome! I've never seen these errors yet. Can you try to use "hg bisect" to find the changeset where the error was introduced? I know it's difficult with sporadic errors... Or maybe try valgrind? Regards, Johannes

Jan. 20, 2009

Crashes in dw::core::Layout::createImgbuf()

by onepoint＠starurchin.org

For the last few days I have been getting occasional crashes inside dw::core::Layout::createImgbuf() when opening a new tab. It does not seem to be predictable: if I restart Dillo and reopen all the URLs I was just looking at it is fine. The gdb backtrace often shows ridiculous values for this: eg. the attached example has this=0x6. I've seen other impossibly small values for this, but sometimes the value seems more sensible. Any ideas? I'd like to investigate further but I don't know what to look for. Pointers are welcome! Regards, Jeremy Henty

Jan. 20, 2009

dillo CSS and charset

by jcid＠dillo.org

On Tue, Jan 20, 2009 at 07:29:46AM +0900, furaisanjin wrote: > 2009/1/20 Jorge Arellano Cid <jcid(a)dillo.org>: > > Yes, there're bugs and a timing issue. > > I'm looking at them... > > Ok, thanks. This is timing issue example page. > > http://www.picfun.com/app00.html > > HTTP server response is > > HTTP/1.1 200 OK > Date: Mon, 19 Jan 2009 22:21:11 GMT > Server: Apache > Last-Modified: Sun, 11 Jan 2009 01:58:25 GMT > ETag: "15e47-43cb-53585240" > Accept-Ranges: bytes > Content-Length: 17355 > Content-Type: text/html > > the page contains > > <META http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> > > At first time charset conversion is something wrong but if I go > somewhere and come back, charset conversion looks OK. I think this > type of page doesn't contain CSS or contains embedded style. So I'm > guessing repush timing is different. Yes, I have a combinatorial case table of things to manage, some work some doesn't. The idea is to get to a design that handles them cleanly. BTW (@all), the "tools" button is 60% done, but stopped. As it also uses repush to enable/disable CSS parsing, is better to fix the above issues before testing it. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 20, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

2009/1/20 Jorge Arellano Cid <jcid(a)dillo.org>: > Yes, there're bugs and a timing issue. > I'm looking at them... Ok, thanks. This is timing issue example page. http://www.picfun.com/app00.html HTTP server response is HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 22:21:11 GMT Server: Apache Last-Modified: Sun, 11 Jan 2009 01:58:25 GMT ETag: "15e47-43cb-53585240" Accept-Ranges: bytes Content-Length: 17355 Content-Type: text/html the page contains <META http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> At first time charset conversion is something wrong but if I go somewhere and come back, charset conversion looks OK. I think this type of page doesn't contain CSS or contains embedded style. So I'm guessing repush timing is different. Regards, furaisanjin

Jan. 19, 2009

dillo CSS and charset

by jcid＠dillo.org

On Mon, Jan 19, 2009 at 11:29:27PM +0900, furaisanjin wrote: > Hi, > > 2009/1/19 Jorge Arellano Cid <jcid(a)dillo.org>: > > Please clarify me whether 2.1 behaviour is right or wrong! :-) > > I think the behavior is wrong. > > > And if you can send an example, better. > > This is one example (this page is news archive so the page may be > removed some day). > > http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-O… > > This is HTTP server response. > > HTTP/1.1 200 OK > Date: Mon, 19 Jan 2009 14:23:11 GMT > Server: Apache > Cache-control: private, max-age=300 > Content-Type: text/html; charset=SHIFT-JIS > Transfer-Encoding: chunked > > And the page contains > > <meta http-equiv="Content-Type" content="text/html; charset=shift-jis" /> Got it! Yes, there're bugs and a timing issue. I'm looking at them... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 19, 2009

[bug]: hang in Css_parse_declaration()

by onepoint＠starurchin.org

On Mon, Jan 19, 2009 at 05:06:39PM +0100, Hofmann Johannes wrote: > On Sun, Jan 18, 2009 at 09:57:58AM +0000, Jeremy Henty wrote: > > The following HTML makes dillo hang and burn 100% CPU. > > > > <html> > > <body> > > a > > </body> > > </html> > > Should be fixed in tip. It is! And the new default font size is nice too! Jeremy Henty

Jan. 19, 2009

[bug]: hang in Css_parse_declaration()

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sun, Jan 18, 2009 at 09:57:58AM +0000, Jeremy Henty wrote: > The following HTML makes dillo hang and burn 100% CPU. > > <html> > <body> > a > </body> > </html> > > The bug does not appear if the span contains no text, or only > whitespace. > > The stack trace always ends inside Css_parse_declaration(). The line > number varies, but seems to be always one of 809, 823 or 963. > > You can see the same bug online at > > http://www.nation.co.ke/News/-/1056/515354/-/u1acuw/-/index.html Should be fixed in tip. Thanks for the report, Johannes

Jan. 19, 2009

Re: A couple of patches

by Johannes.Hofmann＠gmx.de

On Sun, Jan 18, 2009 at 01:23:00AM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: > > > > * snip* > > > > > > BTW, I have a question. How can a minimal font size be specified? > > > Currently I have: > > > > > > body {font-size: 18px !important} > > > > > > in style.css, but often pages come with smaller fonts. e.g. > > > http://www.linux.org.uk/Portaloo.cs > > > > > > For me is important because I have a problems reading tiny fonts, > > > and my working laptop has a high screen resolution. > > > > I've just made a change that uses the existing prefs.font_factor > > value to scale the base font. > > If I use 14 instead of 12, it's a lot more readable. > (Or is the 12 important for some CSS reason involving picas?) No, we can easily change the default fontsize to 14. If nobody objects, I will make that change later today. Cheers, Johannes

Jan. 19, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi, 2009/1/19 Jorge Arellano Cid <jcid(a)dillo.org>: > Please clarify me whether 2.1 behaviour is right or wrong! :-) I think the behavior is wrong. > And if you can send an example, better. This is one example (this page is news archive so the page may be removed some day). http://www.so-net.ne.jp/news/cgi-bin/article.cgi?gid=mai&aid=20090119-570-O… This is HTTP server response. HTTP/1.1 200 OK Date: Mon, 19 Jan 2009 14:23:11 GMT Server: Apache Cache-control: private, max-age=300 Content-Type: text/html; charset=SHIFT-JIS Transfer-Encoding: chunked And the page contains <meta http-equiv="Content-Type" content="text/html; charset=shift-jis" /> Regards, furaisanjin

Jan. 19, 2009

dillo CSS and charset

by jcid＠dillo.org

On Sun, Jan 18, 2009 at 10:33:39PM +0900, furaisanjin wrote: > Hi all. > > I created new subject thread since the original one becomes quite long and. > > I found one difference between dillo-2.0 and dillo-css. there was > a_Decode_charset_init calling at Cache_parse_header in cache.c when > HTTP server Content-Type was detected but there isn't this in > dillo-css. Because if HTTP server Content-Type is same as META > content-type, there isn't any chance to call a_Decode_charset_init. > This is one reason why the page is drawn properly. Yes, there were cleanups on charset decoding. Please clarify me whether 2.1 behaviour is right or wrong! :-) And if you can send an example, better. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 19, 2009

CSS branch merged!

by akemnade＠tzi.de

Hi, On Sun, 18 Jan 2009 17:10:54 +0100 Hofmann Johannes <Johannes.Hofmann(a)gmx.de> wrote: > Hi Andreas, > > On Sat, Jan 17, 2009 at 08:52:00PM +0100, Andreas Kemnade wrote: > > Hi, > > > > On Fri, 16 Jan 2009 14:50:43 -0300 > > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > Hi there, > > > > > > The CSS branch was merged back into main! > > > > > > It has been stabilized and we can continue working from this > > > basis towards our next release. I want to thank all of you > > > involved in helping this happen. Having basic CSS support merged > > > in, is quite an achievement! > > > > > nice. But.. > > the second page I opened causes dillo to crash. > > That was http://www.wetteronline.de/ > > turned out that at least the crash I could reproduce on > http://www.wetteronline.de/ was due to the fact that form.cc was not > yet converted to the new style handling. > Can you please retry with current tip? > Yes, it works now. Before that fix, starting dillo with valgrind "solved" the problem and shows some invalid reads and writes. Now these invalid reads and writes are gone. Greetings Andreas Kemnade

Jan. 18, 2009

CSS branch merged!

by corvid＠lavabit.com

Johannes wrote: > turned out that at least the crash I could reproduce on > http://www.wetteronline.de/ was due to the fact that form.cc was not > yet converted to the new style handling. > Can you please retry with current tip? > > @all: please check whether forms look different now. There may > still be things to be added to the user-agent style. <button>s give me ** WARNING **: No background color found! now.

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

Hi Andreas, On Sat, Jan 17, 2009 at 08:52:00PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 16 Jan 2009 14:50:43 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > Hi there, > > > > The CSS branch was merged back into main! > > > > It has been stabilized and we can continue working from this > > basis towards our next release. I want to thank all of you > > involved in helping this happen. Having basic CSS support merged > > in, is quite an achievement! > > > nice. But.. > the second page I opened causes dillo to crash. > That was http://www.wetteronline.de/ turned out that at least the crash I could reproduce on http://www.wetteronline.de/ was due to the fact that form.cc was not yet converted to the new style handling. Can you please retry with current tip? @all: please check whether forms look different now. There may still be things to be added to the user-agent style. Cheers, Johannes

Jan. 18, 2009

dillo CSS and charset

by furaisanjin＠gmail.com

Hi all. I created new subject thread since the original one becomes quite long and. I found one difference between dillo-2.0 and dillo-css. there was a_Decode_charset_init calling at Cache_parse_header in cache.c when HTTP server Content-Type was detected but there isn't this in dillo-css. Because if HTTP server Content-Type is same as META content-type, there isn't any chance to call a_Decode_charset_init. This is one reason why the page is drawn properly. I still don't figure out another timing issue yet. Regards, furaisanjin

Jan. 18, 2009

[bug]: hang in Css_parse_declaration()

by onepoint＠starurchin.org

The following HTML makes dillo hang and burn 100% CPU. <html> <body> a </body> </html> The bug does not appear if the span contains no text, or only whitespace. The stack trace always ends inside Css_parse_declaration(). The line number varies, but seems to be always one of 809, 823 or 963. You can see the same bug online at http://www.nation.co.ke/News/-/1056/515354/-/u1acuw/-/index.html Regards, Jeremy Henty

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

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 :) Cheers, Johannes

Jan. 18, 2009

CSS branch merged!

by furaisanjin＠gmail.com

Sorry, I didn't sent e-mail to mailing list. 2009/1/18 furaisanjin <furaisanjin(a)gmail.com>: > Hi all. > > 2009/1/18 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: >> On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: >>> Sorry, I mixed up 2 things. I guess default font is something I >>> specified in ~/.dillo/style.css if dillo can't find any fonts >>> specified in style. It seems that there is some timing issue when the >>> page is loaded. The first time somehow the page is unreadable but if I >>> goto to bookmark page and come back to the page, the page is readable. >> >> Argh, timing issues are bad. Can you please point me to a page where >> this happens? > > It seems that there are lots. I notice that Html_tag_open_meta doesn't > repush when charset is detected anymore. So I modified codes like > this. > > /* Cannot ask cache whether the content type was changed, as > * this code in another bw might have already changed it for us. > */ > if (a_Misc_content_type_cmp(html->content_type, new_content)) { > + a_Nav_repush(html->bw); > + html->stop_parser = true; > html->repush_after_head = true; > } > > This helps. I may not need to keep html->repush_after_head = true but > I'm not sure. I was wrong. This doesn't help all cases. The problem seems that when the page is repushed, somehow decoder_charset isn't called so that charset conversion doesn't happens. >>> Another issue is that if style sheet specified none Japanese font and >>> the font exists on my machine, then of course the page isn't readable >>> at all. This isn't dillo problem but style sheet problem. >> >> Do you have an example? How does firefox handle these pages? > > This (http://furaisanjin.blog.so-net.ne.jp) is one example. Firefox > shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/firefox.…) > and this is readable. However dillo shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/dillo.png) > and I can see only dotted squares. > > Style sheet page contains > > #banner h1{ > margin:0; > padding:80px 0 0 14px; > font-size:36px; > font-family: Helvetica; > } > > and Helvetica isn't suitable for Japanese. Regards, furaisanjin

Jan. 18, 2009

Re: A couple of patches

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jan 15, 2009 at 10:41:59AM -0300, Jorge Arellano Cid wrote: > > * snip* > > > > BTW, I have a question. How can a minimal font size be specified? > > Currently I have: > > > > body {font-size: 18px !important} > > > > in style.css, but often pages come with smaller fonts. e.g. > > http://www.linux.org.uk/Portaloo.cs > > > > For me is important because I have a problems reading tiny fonts, > > and my working laptop has a high screen resolution. > > I've just made a change that uses the existing prefs.font_factor > value to scale the base font. If I use 14 instead of 12, it's a lot more readable. (Or is the 12 important for some CSS reason involving picas?)

Jan. 18, 2009

CSS branch merged!

by corvid＠lavabit.com

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

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

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

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 17, 2009 at 11:54:08PM +0100, Hofmann 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... > > Weird... > > > I guess I'll have to dive into the code myself... > > Check CssStyleSheet::apply(). The color:red directive should be in > the anyTable and the color:green thing in > elementTable[docTree->top ()->element], if element is code, tt ... > > Due to the ordering in the inner for-loop, the color:red should be > overridden by color:green for these elements. Wait. Now, that I wrote it, there may be an issue here... Will check that.

Jan. 18, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

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... Weird... > I guess I'll have to dive into the code myself... Check CssStyleSheet::apply(). The color:red directive should be in the anyTable and the color:green thing in elementTable[docTree->top ()->element], if element is code, tt ... Due to the ordering in the inner for-loop, the color:red should be overridden by color:green for these elements. Cheers, Johannes

Jan. 18, 2009

CSS branch merged!

by corvid＠lavabit.com

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

Jan. 17, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 17, 2009 at 11:31:32PM +0200, Rogut?s wrote: > Andreas Kemnade (2009-01-17 20:52): > > Hi, > > > > On Fri, 16 Jan 2009 14:50:43 -0300 > > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > Hi there, > > > > > > The CSS branch was merged back into main! > > > > > > It has been stabilized and we can continue working from this > > > basis towards our next release. I want to thank all of you > > > involved in helping this happen. Having basic CSS support merged > > > in, is quite an achievement! > > > > > nice. But.. > > the second page I opened causes dillo to crash. > > That was http://www.wetteronline.de/ > > CSS support is really nice and it doesn't crash on www.wetteronline.de > here. Neither with fltk2 r6403, nor with r6525, nor with default > dillorc, nor with mine. I haven't got custom stylesheets... > > Don't know why it crashes for you, though. I can reproduce a crash on http://www.wetteronline.de/ when I set special malloc debugging options. It's funny because I check http://www.wetteronline.de/ quite often, but I never saw that crash until now... Cheers, Johannes

Jan. 17, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

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. > > Also, is <element style="[whatever]"> supposed to work? > Yes, since today :-)

Jan. 17, 2009

CSS branch merged!

by rogutes＠googlemail.com

Andreas Kemnade (2009-01-17 20:52): > Hi, > > On Fri, 16 Jan 2009 14:50:43 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > Hi there, > > > > The CSS branch was merged back into main! > > > > It has been stabilized and we can continue working from this > > basis towards our next release. I want to thank all of you > > involved in helping this happen. Having basic CSS support merged > > in, is quite an achievement! > > > nice. But.. > the second page I opened causes dillo to crash. > That was http://www.wetteronline.de/ CSS support is really nice and it doesn't crash on www.wetteronline.de here. Neither with fltk2 r6403, nor with r6525, nor with default dillorc, nor with mine. I haven't got custom stylesheets... Don't know why it crashes for you, though. -- -- Rogut?s Sparnuotos

Jan. 17, 2009