From Johannes.Hofmann at gmx.de Tue Dec 1 22:12:30 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Dec 1 22:15:45 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> References: <144aa14b0911210033g1ef3ea0ar7ece869a3fe5912f@mail.gmail.com> <20091124220323.GA48620@blob.baaderstrasse.com> <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> Message-ID: <20091201211230.GA1802@blob.baaderstrasse.com> On Sat, Nov 28, 2009 at 01:06:21PM +0900, furaisanjin wrote: > 2009/11/28 Johannes Hofmann : > > I committed a slightly different patch to also cover the case when > > middle_click_opens_new_tab=NO > > > > Please test, > > I tested but I found still there were cases where cursor stayed on > address bar. Could you consider this patch? Can you please describe the situation where it happens? I'm a bit reluctant to sprinkle focus handling code all over the place. Regards, Johannes From furaisanjin at gmail.com Wed Dec 2 00:14:16 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Dec 2 00:15:32 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091201211230.GA1802@blob.baaderstrasse.com> References: <144aa14b0911210033g1ef3ea0ar7ece869a3fe5912f@mail.gmail.com> <20091124220323.GA48620@blob.baaderstrasse.com> <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> Message-ID: <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> 2009/12/2 Johannes Hofmann : > Can you please describe the situation where it happens? There are 2 cases. 1. When dillo starts, cursor stays on address bar and this is the side effect of the updated codes. 2. When URL is given on address bar, cursor stays on address bar after the page rendering finishes. This isn't side effect. This may be matter of taste but I don't like this behavior. Regards, furaisanjin From corvid at lavabit.com Wed Dec 2 01:28:12 2009 From: corvid at lavabit.com (corvid) Date: Wed Dec 2 01:32:43 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> References: <144aa14b0911210033g1ef3ea0ar7ece869a3fe5912f@mail.gmail.com> <20091124220323.GA48620@blob.baaderstrasse.com> <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> Message-ID: <20091202002811.GA2816@local.gobigwest.com> furaisanjin wrote: > 2. When URL is given on address bar, cursor stays on address bar after > the page rendering finishes. This isn't side effect. This may be > matter of taste but I don't like this behavior. We'll need to be careful if changing focus in this case, since the user may be in the middle of typing something somewhere. (My local public library's site, if used in firefox, likes to reset form fields with javascript when a page finishes loading, and it's irritating.) From furaisanjin at gmail.com Wed Dec 2 13:33:45 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Dec 2 13:34:40 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091202002811.GA2816@local.gobigwest.com> References: <144aa14b0911210033g1ef3ea0ar7ece869a3fe5912f@mail.gmail.com> <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> Message-ID: <144aa14b0912020433u7a53569au17488659f821bff1@mail.gmail.com> 2009/12/2 corvid : > furaisanjin wrote: >> 2. When URL is given on address bar, cursor stays on address bar after >> the page rendering finishes. This isn't side effect. This may be >> matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. I agree but current dillo behavior isn't good either. If I type something on address bar before a page rendering finishes, typed characters are appended after URL when URL is pushed on address bar. I think only typed characters should remain there when the page rendering finishes. Regards, furaisanjin From Johannes.Hofmann at gmx.de Wed Dec 2 18:40:19 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 2 18:42:50 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <144aa14b0912020433u7a53569au17488659f821bff1@mail.gmail.com> References: <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <144aa14b0912020433u7a53569au17488659f821bff1@mail.gmail.com> Message-ID: <20091202174019.GA1976@blob.baaderstrasse.com> On Wed, Dec 02, 2009 at 09:33:45PM +0900, furaisanjin wrote: > 2009/12/2 corvid : > > furaisanjin wrote: > >> 2. When URL is given on address bar, cursor stays on address bar after > >> the page rendering finishes. This isn't side effect. This may be > >> matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > I agree but current dillo behavior isn't good either. If I type > something on address bar before a page rendering finishes, typed > characters are appended after URL when URL is pushed on address bar. I > think only typed characters should remain there when the page > rendering finishes. Yes, that's annoying, but I think it's a separate issue. Regards, Johannes From Johannes.Hofmann at gmx.de Wed Dec 2 18:42:27 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 2 18:44:56 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091202002811.GA2816@local.gobigwest.com> References: <20091124220323.GA48620@blob.baaderstrasse.com> <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> Message-ID: <20091202174227.GB1976@blob.baaderstrasse.com> On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > furaisanjin wrote: > > 2. When URL is given on address bar, cursor stays on address bar after > > the page rendering finishes. This isn't side effect. This may be > > matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. > > (My local public library's site, if used in firefox, likes to reset > form fields with javascript when a page finishes loading, and it's > irritating.) What do all think about attached patch. It switches the focus when the user hits return. So the focus switch does not happen at some random time when the page has loaded which might be irritating. Cheers, Johannes -------------- next part -------------- diff -r a41372a38f02 src/ui.cc --- a/src/ui.cc Wed Dec 02 17:40:33 2009 +0100 +++ b/src/ui.cc Wed Dec 02 18:42:15 2009 +0100 @@ -267,6 +267,7 @@ * page. BUG: this must be investigated and reported to FLTK2 team */ if (event_key() == ReturnKey) { a_UIcmd_open_urlstr(a_UIcmd_get_bw_by_widget(i), i->value()); + ui->focus_main(); } if (ui->get_panelmode() == UI_TEMPORARILY_SHOW_PANELS) { ui->set_panelmode(UI_HIDDEN); From tim.nieradzik at gmx.de Sat Dec 5 19:51:35 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sat Dec 5 19:52:05 2009 Subject: [Dillo-dev] Misbehaving dw-demos Message-ID: <20091205185135.GA13740@tim-laptop.tux> The dw-demos stopped working for me with revision 2b0ed71ccec6. The changeset results in only printing the first character of each word followed by a line break. --Tim From Johannes.Hofmann at gmx.de Sat Dec 5 19:58:38 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Dec 5 20:01:11 2009 Subject: [Dillo-dev] Misbehaving dw-demos In-Reply-To: <20091205185135.GA13740@tim-laptop.tux> References: <20091205185135.GA13740@tim-laptop.tux> Message-ID: <20091205185838.GA15407@blob.baaderstrasse.com> Hi Tim, On Sat, Dec 05, 2009 at 07:51:35PM +0100, Tim Nieradzik wrote: > The dw-demos stopped working for me with revision 2b0ed71ccec6. The > changeset results in only printing the first character of each word > followed by a line break. As discussed off-list already, this happens because the new letter-spacing member of FontAttrs is not initialized properly in the test programs. I will fix that. Normally a constructor exists to avoid exactly this kind of bugs. However we need to be careful to avoid unnecessary initializations when the members get copied over right after initialization - or maybe this wouldn't even matter performance wise... I need to play with this a little. Thanks for the fault report, Johannes From tim.nieradzik at gmx.de Sat Dec 5 20:22:06 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sat Dec 5 20:22:37 2009 Subject: [Dillo-dev] dpid not starting automatically Message-ID: <20091205192206.GB13740@tim-laptop.tux> I am starting Dillo right away from the source code. Thus, it is not installed in any of the directories listed in $PATH. Dillo gives me the following errors as it does not seem to be able to find the dpid binary: Dpi_check_dpid_ids: Connection refused Dpi_start_dpid (child): No such file or directory Dpi_start_dpid: can't start dpid What do you think of adding some code that tries to execute the local dpid binary first (dpid/dpid) before looking into the system paths? --Tim From tim.nieradzik at gmx.de Sat Dec 5 20:44:47 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sat Dec 5 20:45:17 2009 Subject: [Dillo-dev] HTML parser bug Message-ID: <20091205194446.GC13740@tim-laptop.tux> There is a bug in the HTML parser: Tags within quotes are interpreted: I think it is line 3754f (src/html.cc) which evokes the unwanted behaviour. I'd fix this bug by introducing two variables: The first one states whether we're currently inside of a quote and the second one stores its type (single or double quote). As long as the current character does not equal the type, all characters in between the starting and ending quote will be ignored. Of course we should be also able to deal with escaped quotes allowing constructs similar to the following one: " /> --Tim From corvid at lavabit.com Sat Dec 5 20:52:33 2009 From: corvid at lavabit.com (corvid) Date: Sat Dec 5 20:57:00 2009 Subject: [Dillo-dev] dpid not starting automatically In-Reply-To: <20091205192206.GB13740@tim-laptop.tux> References: <20091205192206.GB13740@tim-laptop.tux> Message-ID: <20091205195233.GA2914@local.gobigwest.com> Tim wrote: > I am starting Dillo right away from the source code. Thus, it is not > installed in any of the directories listed in $PATH. Dillo gives me the > following errors as it does not seem to be able to find the dpid binary: > > Dpi_check_dpid_ids: Connection refused > Dpi_start_dpid (child): No such file or directory > Dpi_start_dpid: can't start dpid > > What do you think of adding some code that tries to execute the local > dpid binary first (dpid/dpid) before looking into the system paths? I would prefer to limit how clever dillo tries to be. I wouldn't want to get mixed up where it happens to run the local one which I didn't install yet. (Actually, in my case, I don't install them, either, and I symlink into the tree.) From tim.nieradzik at gmx.de Sat Dec 5 21:10:45 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sat Dec 5 21:11:16 2009 Subject: [Dillo-dev] display: inline Message-ID: <20091205201045.GD13740@tim-laptop.tux> I am currently working on adding CSS support for "display: inline" tags. They are commonly used for navigation menus. As these menus are nothing more than simple unordered lists (
    ), the items are printed one below the other which wastes lots of space. The patch I came up with does only partially implement support for these tags: The items are correctly displayed within one line but I cannot figure out why there is so much empty space after each item. Perhaps somebody with a better understanding of the dw-code than me might have a look into the issue. If I am correct, the dw/textblock.cc is responsible for calculating the widths. Textblock::wordWrap() looks pretty promising as there is a variable (hasListitemValue) determining whether it is a list item and calculates values for lastLine->leftOffset and words->getRef(0)->effSpace depending on this state. --Tim From tim.nieradzik at gmx.de Sat Dec 5 21:13:31 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sat Dec 5 21:14:00 2009 Subject: [Dillo-dev] display: inline Message-ID: <20091205201331.GE13740@tim-laptop.tux> Sorry, I forgot to attach the patch. :) --Tim -------------- next part -------------- diff -r ef9bb7457ebb src/html.cc --- a/src/html.cc Fri Dec 04 19:39:31 2009 +0100 +++ b/src/html.cc Sat Dec 05 17:56:38 2009 +0100 @@ -2527,8 +2527,12 @@ html->styleEngine->setNonCssHints (&props); } - Html_add_textblock(html, 9); - + Textblock *textblock = new Textblock (prefs.limit_text_width); + + HT2TB(html)->addWidget (textblock, html->styleEngine->style ()); + + S_TOP(html)->textblock = html->dw = textblock; + S_TOP(html)->hand_over_break = true; S_TOP(html)->list_type = HTML_LIST_UNORDERED; S_TOP(html)->list_number = 0; S_TOP(html)->ref_list_item = NULL; @@ -2620,11 +2624,18 @@ list_number = &html->stack->getRef(html->stack->size()-2)->list_number; ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; - HT2TB(html)->addParbreak (0, wordStyle); + if (style->display != core::style::DISPLAY_INLINE) { + HT2TB(html)->addParbreak (0, wordStyle); + } list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); + HT2TB(html)->addWidget (list_item, style); - HT2TB(html)->addParbreak (0, wordStyle); + + if (style->display != core::style::DISPLAY_INLINE) { + HT2TB(html)->addParbreak (0, wordStyle); + } + *ref_list_item = list_item; S_TOP(html)->textblock = html->dw = list_item; From corvid at lavabit.com Sat Dec 5 21:47:56 2009 From: corvid at lavabit.com (corvid) Date: Sat Dec 5 21:52:22 2009 Subject: [Dillo-dev] HTML parser bug In-Reply-To: <20091205194446.GC13740@tim-laptop.tux> References: <20091205194446.GC13740@tim-laptop.tux> Message-ID: <20091205204756.GB2914@local.gobigwest.com> Tim wrote: > There is a bug in the HTML parser: Tags within quotes are interpreted: > > > > I think it is line 3754f (src/html.cc) which evokes the unwanted > behaviour. I'd fix this bug by introducing two variables: The first one > states whether we're currently inside of a quote and the second one > stores its type (single or double quote). As long as the current > character does not equal the type, all characters in between the > starting and ending quote will be ignored. Of course we should be also > able to deal with escaped quotes allowing constructs similar to the > following one: > > " /> Strictly speaking, for attributes that are CDATA, at least, my impression is that the element is closed if the parser encounters an (SGML jargon!) end-tag open (ETAGO, i.e., " References: <20091205194446.GC13740@tim-laptop.tux> <20091205204756.GB2914@local.gobigwest.com> Message-ID: <20091205221327.GD15448@dillo.org> On Sat, Dec 05, 2009 at 08:47:56PM +0000, corvid wrote: > Tim wrote: > > There is a bug in the HTML parser: Tags within quotes are interpreted: > > > > > > > > I think it is line 3754f (src/html.cc) which evokes the unwanted > > behaviour. I'd fix this bug by introducing two variables: The first one > > states whether we're currently inside of a quote and the second one > > stores its type (single or double quote). As long as the current > > character does not equal the type, all characters in between the > > starting and ending quote will be ignored. Of course we should be also > > able to deal with escaped quotes allowing constructs similar to the > > following one: > > > > " /> > > Strictly speaking, for attributes that are CDATA, at least, > my impression is that the element is closed if the parser encounters an > (SGML jargon!) end-tag open (ETAGO, i.e., " (meaning, I think, that it is followed by certain characters such as > ASCII letters). > > Of course, sgml is a horrible, loony monstrosity, and we don't follow > it to the letter to begin with, so I'm not sure that I'd necessarily be > opposed to making the parser behave as you say. > (Remembers http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-January/003668.html) Good advice! ;) Although a better heuristic is welcomed, it's not easy. Beware of the sleeping dragon. You have to consider (at least): * RFC (HTML, SGML, XML) * What do other browsers do. * Heuristic worst case and average. * Unexpected input (broken HTML or XML, attacks...). * Complexity and overhead (it affects the tokenizer). * Error reporting. The above idea has been tried, but it fails when the attribute lacks its closing quote, sometimes eating lots of content when plain text follows. You can find more details in doc/HtmlParser.txt. I wish we could find a better heuristic. For instance to clean the IFRAME rendering of http://www.linuxfordevices.com/. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Sun Dec 6 00:15:13 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Dec 6 00:18:00 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091205201045.GD13740@tim-laptop.tux> References: <20091205201045.GD13740@tim-laptop.tux> Message-ID: <20091205231513.GA19345@blob.baaderstrasse.com> Hi Tim, On Sat, Dec 05, 2009 at 09:10:45PM +0100, Tim Nieradzik wrote: > I am currently working on adding CSS support for "display: inline" tags. > They are commonly used for navigation menus. As these menus are nothing > more than simple unordered lists (
      ), the items are printed one below > the other which wastes lots of space. > > The patch I came up with does only partially implement support for these > tags: The items are correctly displayed within one line but I cannot > figure out why there is so much empty space after each item. > > Perhaps somebody with a better understanding of the dw-code than me > might have a look into the issue. If I am correct, the dw/textblock.cc > is responsible for calculating the widths. Textblock::wordWrap() looks > pretty promising as there is a variable (hasListitemValue) determining > whether it is a list item and calculates values for lastLine->leftOffset > and words->getRef(0)->effSpace depending on this state. I think we need to be a bit more radical. Consider this slightly modified patch (attached). If I read the CSS 2.1 Spec correctly then the idea is that every element can be a list-item if it has display: list-item set. So
    • elements would have to be handled as any other element but get display: list-item from our user-agent style. So for the real implementation we would need to change html.cc in a way that not the current element name, but the value of the display property determines whether to show a list item, or to show nothing at all (display: none) and so on. That said, I think the modified version of your patch is a good start until we fully support the display property, as lists with display: inline seem to be pretty common. So please test this with your favorite web sites. Cheers, Johannes -------------- next part -------------- diff -r 8de487d495f7 dw/textblock.cc --- a/dw/textblock.cc Sat Dec 05 21:58:31 2009 +0100 +++ b/dw/textblock.cc Sun Dec 06 00:03:49 2009 +0100 @@ -134,7 +134,7 @@ Line *lastLine = lines->getRef (lines->size () - 1); requisition->width = misc::max (lastLine->maxLineWidth, lastLineWidth); - /* Note: the break_space of the last line is ignored, so breaks + /* Note: the breakSpace of the last line is ignored, so breaks at the end of a textblock are not visible. */ requisition->ascent = lines->getRef(0)->ascent; requisition->descent = lastLine->top @@ -1447,9 +1447,9 @@ /* * This new routine returns the line number between (top) and - * (top + size.ascent + size.descent + break_space): the space + * (top + size.ascent + size.descent + breakSpace): the space * _below_ the line is considered part of the line. Old routine - * returned line number between (top - previous_line->break_space) + * returned line number between (top - previous_line->breakSpace) * and (top + size.ascent + size.descent): the space _above_ the * line was considered part of the line. This is important for * Dw_page_find_link() --EG @@ -1741,7 +1741,7 @@ way that the space is in any case visible. */ Widget *widget; - /* Find the widget where to adjust the break_space. */ + /* Find the widget where to adjust the breakSpace. */ for (widget = this; widget->getParent() && widget->getParent()->instanceOf (Textblock::CLASS_ID); diff -r 8de487d495f7 src/css.cc --- a/src/css.cc Sat Dec 05 21:58:31 2009 +0100 +++ b/src/css.cc Sun Dec 06 00:03:49 2009 +0100 @@ -568,7 +568,7 @@ "h5 {font-size: 0.83em; margin-top: 1.5em; margin-bottom: 0}" "h6 {font-size: 0.75em; margin-top: 1.67em; margin-bottom: 0}" "hr {width: 100%; border: 1px inset}" - "li {margin-top: 0.1em}" + "li {margin-top: 0.1em; display: list-item}" "pre {white-space: pre}" "ol {list-style-type: decimal}" "ul {list-style-type: disc}" diff -r 8de487d495f7 src/html.cc --- a/src/html.cc Sat Dec 05 21:58:31 2009 +0100 +++ b/src/html.cc Sun Dec 06 00:03:49 2009 +0100 @@ -2527,8 +2527,12 @@ html->styleEngine->setNonCssHints (&props); } - Html_add_textblock(html, 9); + Textblock *textblock = new Textblock (prefs.limit_text_width); + HT2TB(html)->addWidget (textblock, html->styleEngine->style ()); + + S_TOP(html)->textblock = html->dw = textblock; + S_TOP(html)->hand_over_break = true; S_TOP(html)->list_type = HTML_LIST_UNORDERED; S_TOP(html)->list_number = 0; S_TOP(html)->ref_list_item = NULL; @@ -2616,32 +2620,37 @@ html->InFlags |= IN_LI; - /* Get our parent tag's variables (used as state storage) */ - list_number = &html->stack->getRef(html->stack->size()-2)->list_number; - ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; + if (style->display == core::style::DISPLAY_LIST_ITEM) { + /* Get our parent tag's variables (used as state storage) */ + list_number = &html->stack->getRef(html->stack->size()-2)->list_number; + ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; - HT2TB(html)->addParbreak (0, wordStyle); + HT2TB(html)->addParbreak (0, wordStyle); - list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); - HT2TB(html)->addWidget (list_item, style); - HT2TB(html)->addParbreak (0, wordStyle); - *ref_list_item = list_item; - S_TOP(html)->textblock = html->dw = list_item; + list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); - if (style->listStyleType == LIST_STYLE_TYPE_NONE) { - // none - } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { - // ordered - if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "value")) && - (*list_number = strtol(attrbuf, NULL, 10)) < 0) { + HT2TB(html)->addWidget (list_item, style); + + HT2TB(html)->addParbreak (0, wordStyle); + + *ref_list_item = list_item; + S_TOP(html)->textblock = html->dw = list_item; + + if (style->listStyleType == LIST_STYLE_TYPE_NONE) { + // none + } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { + // ordered + if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "value")) && + (*list_number = strtol(attrbuf, NULL, 10)) < 0) { BUG_MSG("illegal negative LIST VALUE attribute; Starting from 0\n"); *list_number = 0; + } + numtostr((*list_number)++, buf, 16, style->listStyleType); + list_item->initWithText (buf, wordStyle); + } else { + // unordered + list_item->initWithWidget (new Bullet(), wordStyle); } - numtostr((*list_number)++, buf, 16, style->listStyleType); - list_item->initWithText (buf, wordStyle); - } else { - // unordered - list_item->initWithWidget (new Bullet(), wordStyle); } } From tim.nieradzik at gmx.de Sun Dec 6 03:04:25 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sun Dec 6 03:04:56 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091205231513.GA19345@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> Message-ID: <20091206020425.GB26156@tim-laptop.tux> Hi Johannes, thank you very much. The patch works great for
    • elements but for each
        there is still some unused space. See http://www.heise.de/. I added "display: list-item" to the ul-item in Dillo's stylesheet definition and in Html_tag_open_ul() I am comparing the the display-attribute with the "list-item"-value. Strangely enough it worked! I am still wondering why it does. --Tim -------------- next part -------------- diff -r ef9bb7457ebb dw/textblock.cc --- a/dw/textblock.cc Fri Dec 04 19:39:31 2009 +0100 +++ b/dw/textblock.cc Sun Dec 06 02:46:19 2009 +0100 @@ -134,7 +134,7 @@ Line *lastLine = lines->getRef (lines->size () - 1); requisition->width = misc::max (lastLine->maxLineWidth, lastLineWidth); - /* Note: the break_space of the last line is ignored, so breaks + /* Note: the breakSpace of the last line is ignored, so breaks at the end of a textblock are not visible. */ requisition->ascent = lines->getRef(0)->ascent; requisition->descent = lastLine->top @@ -1447,9 +1447,9 @@ /* * This new routine returns the line number between (top) and - * (top + size.ascent + size.descent + break_space): the space + * (top + size.ascent + size.descent + breakSpace): the space * _below_ the line is considered part of the line. Old routine - * returned line number between (top - previous_line->break_space) + * returned line number between (top - previous_line->breakSpace) * and (top + size.ascent + size.descent): the space _above_ the * line was considered part of the line. This is important for * Dw_page_find_link() --EG @@ -1741,7 +1741,7 @@ way that the space is in any case visible. */ Widget *widget; - /* Find the widget where to adjust the break_space. */ + /* Find the widget where to adjust the breakSpace. */ for (widget = this; widget->getParent() && widget->getParent()->instanceOf (Textblock::CLASS_ID); diff -r ef9bb7457ebb src/css.cc --- a/src/css.cc Fri Dec 04 19:39:31 2009 +0100 +++ b/src/css.cc Sun Dec 06 02:46:19 2009 +0100 @@ -568,10 +568,10 @@ "h5 {font-size: 0.83em; margin-top: 1.5em; margin-bottom: 0}" "h6 {font-size: 0.75em; margin-top: 1.67em; margin-bottom: 0}" "hr {width: 100%; border: 1px inset}" - "li {margin-top: 0.1em}" + "li {margin-top: 0.1em; display: list-item}" "pre {white-space: pre}" "ol {list-style-type: decimal}" - "ul {list-style-type: disc}" + "ul {list-style-type: disc; display: list-item}" "ul ul {list-style-type: circle}" "ul ul ul {list-style-type: square}" "ul ul ul ul {list-style-type: disc}" diff -r ef9bb7457ebb src/html.cc --- a/src/html.cc Fri Dec 04 19:39:31 2009 +0100 +++ b/src/html.cc Sun Dec 06 02:46:19 2009 +0100 @@ -2506,32 +2506,39 @@ */ static void Html_tag_open_ul(DilloHtml *html, const char *tag, int tagsize) { + Style *style = html->styleEngine->style (); const char *attrbuf; ListStyleType list_style_type; - if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "type"))) { - CssPropertyList props; - - /* list_style_type explicitly defined */ - if (dStrcasecmp(attrbuf, "disc") == 0) - list_style_type = LIST_STYLE_TYPE_DISC; - else if (dStrcasecmp(attrbuf, "circle") == 0) - list_style_type = LIST_STYLE_TYPE_CIRCLE; - else if (dStrcasecmp(attrbuf, "square") == 0) - list_style_type = LIST_STYLE_TYPE_SQUARE; - else - /* invalid value */ - list_style_type = LIST_STYLE_TYPE_DISC; - - props.set(CSS_PROPERTY_LIST_STYLE_TYPE, CSS_TYPE_ENUM, list_style_type); - html->styleEngine->setNonCssHints (&props); + if (style->display == core::style::DISPLAY_LIST_ITEM) { + if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "type"))) { + CssPropertyList props; + + /* list_style_type explicitly defined */ + if (dStrcasecmp(attrbuf, "disc") == 0) + list_style_type = LIST_STYLE_TYPE_DISC; + else if (dStrcasecmp(attrbuf, "circle") == 0) + list_style_type = LIST_STYLE_TYPE_CIRCLE; + else if (dStrcasecmp(attrbuf, "square") == 0) + list_style_type = LIST_STYLE_TYPE_SQUARE; + else + /* invalid value */ + list_style_type = LIST_STYLE_TYPE_DISC; + + props.set(CSS_PROPERTY_LIST_STYLE_TYPE, CSS_TYPE_ENUM, list_style_type); + html->styleEngine->setNonCssHints (&props); + } + + Textblock *textblock = new Textblock (prefs.limit_text_width); + + HT2TB(html)->addWidget (textblock, html->styleEngine->style ()); + + S_TOP(html)->textblock = html->dw = textblock; + S_TOP(html)->hand_over_break = true; + S_TOP(html)->list_type = HTML_LIST_UNORDERED; + S_TOP(html)->list_number = 0; + S_TOP(html)->ref_list_item = NULL; } - - Html_add_textblock(html, 9); - - S_TOP(html)->list_type = HTML_LIST_UNORDERED; - S_TOP(html)->list_number = 0; - S_TOP(html)->ref_list_item = NULL; } /* @@ -2616,32 +2623,37 @@ html->InFlags |= IN_LI; - /* Get our parent tag's variables (used as state storage) */ - list_number = &html->stack->getRef(html->stack->size()-2)->list_number; - ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; - - HT2TB(html)->addParbreak (0, wordStyle); - - list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); - HT2TB(html)->addWidget (list_item, style); - HT2TB(html)->addParbreak (0, wordStyle); - *ref_list_item = list_item; - S_TOP(html)->textblock = html->dw = list_item; - - if (style->listStyleType == LIST_STYLE_TYPE_NONE) { - // none - } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { - // ordered - if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "value")) && - (*list_number = strtol(attrbuf, NULL, 10)) < 0) { + if (style->display == core::style::DISPLAY_LIST_ITEM) { + /* Get our parent tag's variables (used as state storage) */ + list_number = &html->stack->getRef(html->stack->size()-2)->list_number; + ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; + + HT2TB(html)->addParbreak (0, wordStyle); + + list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); + + HT2TB(html)->addWidget (list_item, style); + + HT2TB(html)->addParbreak (0, wordStyle); + + *ref_list_item = list_item; + S_TOP(html)->textblock = html->dw = list_item; + + if (style->listStyleType == LIST_STYLE_TYPE_NONE) { + // none + } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { + // ordered + if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "value")) && + (*list_number = strtol(attrbuf, NULL, 10)) < 0) { BUG_MSG("illegal negative LIST VALUE attribute; Starting from 0\n"); *list_number = 0; + } + numtostr((*list_number)++, buf, 16, style->listStyleType); + list_item->initWithText (buf, wordStyle); + } else { + // unordered + list_item->initWithWidget (new Bullet(), wordStyle); } - numtostr((*list_number)++, buf, 16, style->listStyleType); - list_item->initWithText (buf, wordStyle); - } else { - // unordered - list_item->initWithWidget (new Bullet(), wordStyle); } } From Johannes.Hofmann at gmx.de Tue Dec 8 18:56:55 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Dec 8 18:59:27 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091206020425.GB26156@tim-laptop.tux> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> Message-ID: <20091208175654.GA4339@blob.baaderstrasse.com> Hi, I started to experiment with the real solution, which means that the display member of Style determines whether a (Text)block is created or a ListItem, or whether just normal text is added. The patch is still small, but as the change is pretty fundamental, so I decided to put it in a separate repo for now. You can find it at: http://www.flpsed.org/hgweb/dillo_display/ Please let me know what you think, and I would especially like to get opinions on how to implement the various display types: inline | block | list-item | run-in | inline-block | none I've intentionally left out the table stuff for now ... Cheers, Johannes From corvid at lavabit.com Tue Dec 8 21:36:35 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 8 21:41:25 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091208175654.GA4339@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> Message-ID: <20091208203634.GA2784@local.gobigwest.com> Johannes wrote: > Please let me know what you think, and I would especially like to > get opinions on how to implement the various display types: > > inline | block | list-item | run-in | inline-block | none I don't know about details, but I suspect the logic will all end up in dw. And that we will end up having to make a lot of boxes eventually. In bug 929, someone wants to know why padding-left doesn't work for P elements, for instance. This might be what Sebastian meant in the top of textblock.hh about collapsing spaces being unnecessary in a CSS-ized dillo. From Johannes.Hofmann at gmx.de Tue Dec 8 22:06:54 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Dec 8 22:09:29 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091208203634.GA2784@local.gobigwest.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208203634.GA2784@local.gobigwest.com> Message-ID: <20091208210653.GA9799@blob.baaderstrasse.com> On Tue, Dec 08, 2009 at 08:36:35PM +0000, corvid wrote: > Johannes wrote: > > Please let me know what you think, and I would especially like to > > get opinions on how to implement the various display types: > > > > inline | block | list-item | run-in | inline-block | none > > I don't know about details, but I suspect the logic will all > end up in dw. I thought that the display handling would be done in html.cc - by choosing the proper dw widget structure. I think this is what Sebastian calls "complex properties" in http://www.dillo.org/CSS.html > > And that we will end up having to make a lot of boxes eventually. Yes definately. Currently we sometimes just add a parbreak, where we would need a new box. That's also the reason for the inheritBackgroundColor hack. On the other hand more Textblock widgets consume more memory on large pages. > In bug 929, someone wants to know why padding-left doesn't work > for P elements, for instance. This might be what Sebastian meant in > the top of textblock.hh about collapsing spaces being unnecessary > in a CSS-ized dillo. I don't know enough about this space collapsing... From tim.nieradzik at gmx.de Wed Dec 9 00:54:54 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Dec 9 00:55:24 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091208175654.GA4339@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> Message-ID: <20091208235454.GB3668@tim-laptop.tux> In my opinion, these changes make sense indeed as they provide a more generic interface. Looking at quirkmode's "display: list-item"-demo, listStylePosition seems to have a wrong value. The bullets are supposed to be drawn outside the box but they appear inside. Did I understand your changes correctly that listStylePosition is either 0 ("outside") or 1 ("inside") because of that enum? See http://www.quirksmode.org/css/display.html I tried to implement "display: none" but the contents are still visible. I also worked on getting rid of tagIsDisplayEnabled but I am yet uncertain whether it is safe how approached it. Any comments? --Tim -------------- next part -------------- diff -r 440fa7e952bd dw/style.hh --- a/dw/style.hh Tue Dec 08 18:46:31 2009 +0100 +++ b/dw/style.hh Wed Dec 09 00:48:03 2009 +0100 @@ -253,7 +253,8 @@ DISPLAY_TABLE_FOOTER_GROUP, DISPLAY_TABLE_ROW, DISPLAY_TABLE_CELL, - DISPLAY_LAST + DISPLAY_LAST, + DISPLAY_NONE }; enum ListStylePosition { diff -r 440fa7e952bd src/cssparser.cc --- a/src/cssparser.cc Tue Dec 08 18:46:31 2009 +0100 +++ b/src/cssparser.cc Wed Dec 09 00:48:03 2009 +0100 @@ -58,10 +58,10 @@ "w-resize", "text", "wait", "help", NULL }; -static const char *const Css_display_enum_vals[DISPLAY_LAST + 1] = { +static const char *const Css_display_enum_vals[] = { "block", "inline", "list-item", "table", "table-row-group", "table-header-group", "table-footer-group", "table-row", - "table-cell", NULL + "table-cell", "last", "none", NULL }; static const char *const Css_font_size_enum_vals[] = { diff -r 440fa7e952bd src/html.cc --- a/src/html.cc Tue Dec 08 18:46:31 2009 +0100 +++ b/src/html.cc Wed Dec 09 00:48:03 2009 +0100 @@ -1282,7 +1282,7 @@ TagInfo toptag = Tags[toptag_idx]; if (s_sz > idx + 1 && toptag.EndTag != 'O') BUG_MSG(" - forcing close of open tag: <%s>\n", toptag.name); - _MSG("Close: %*s%s\n", size," ", toptag.name); + _MSG("Close: %*s%s\n", s_sz, " ", toptag.name); toptag.close(html, toptag_idx); Html_real_pop_tag(html); } @@ -1528,13 +1528,6 @@ } /* - * By setting this to true, a Html_tag_open* function indicates that - * the common display handling code should be used. - * TODO: convert all Html_tag_open* functions and remove this variable. - */ -static bool tagIsDisplayEnabled; - -/* * Handle open HTML element */ static void Html_tag_open_html(DilloHtml *html, const char *tag, int tagsize) @@ -1876,8 +1869,6 @@ a_Html_stash_init(html); S_TOP(html)->parse_mode = DILLO_HTML_PARSE_MODE_STASH_AND_BODY; - - tagIsDisplayEnabled = true; } /* @@ -1916,8 +1907,6 @@ html->styleEngine->setNonCssHints (&props); dFree(fontFamily); - - tagIsDisplayEnabled = true; } /* @@ -1926,7 +1915,7 @@ static void Html_tag_open_abbr(DilloHtml *html, const char *tag, int tagsize) { const char *attrbuf; - + if (prefs.show_tooltip && (attrbuf = a_Html_get_attr(html, tag, tagsize, "title"))) { CssPropertyList props; @@ -1936,8 +1925,6 @@ html->styleEngine->setNonCssHints (&props); dFree(tooltip_str); } - - tagIsDisplayEnabled = true; } /* @@ -2183,8 +2170,6 @@ BUG_MSG("name attribute is required for \n"); } } - - tagIsDisplayEnabled = true; } /* @@ -2453,8 +2438,6 @@ dFree(nameVal); } } - - tagIsDisplayEnabled = true; } /* @@ -2528,8 +2511,6 @@ S_TOP(html)->list_type = HTML_LIST_UNORDERED; S_TOP(html)->list_number = 0; S_TOP(html)->ref_list_item = NULL; - - tagIsDisplayEnabled = true; } /* @@ -2590,10 +2571,9 @@ BUG_MSG( "illegal '-' character in START attribute; Starting from 0\n"); n = 0; } + S_TOP(html)->list_number = n; S_TOP(html)->ref_list_item = NULL; - - tagIsDisplayEnabled = true; } /* @@ -2621,8 +2601,6 @@ *list_number = 0; } } - - tagIsDisplayEnabled = true; } /* @@ -3011,7 +2989,6 @@ static void Html_tag_open_default(DilloHtml *html,const char *tag,int tagsize) { html->styleEngine->inheritBackgroundColor(); - tagIsDisplayEnabled = true; } /* @@ -3023,7 +3000,6 @@ a_Html_tag_set_align_attr (html, &props, tag, tagsize); html->styleEngine->setNonCssHints (&props); - tagIsDisplayEnabled = true; } /* @@ -3418,11 +3394,11 @@ ListItem *list_item; int *list_number; char buf[16]; - + /* Get our parent tag's variables (used as state storage) */ list_number = &html->stack->getRef(html->stack->size()-2)->list_number; ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; - + HT2TB(html)->addParbreak (0, wordStyle); list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); @@ -3430,7 +3406,7 @@ HT2TB(html)->addParbreak (0, wordStyle); *ref_list_item = list_item; S_TOP(html)->textblock = html->dw = list_item; - + if (style->listStyleType == LIST_STYLE_TYPE_NONE) { // none } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { @@ -3496,15 +3472,11 @@ /* Parse attributes that can appear on any tag */ Html_parse_common_attrs(html, tag, tagsize); - /* Html_tag_open* function can set this to true to enable - * generic CSS display handling. - */ - tagIsDisplayEnabled = false; - /* Call the open function for this tag */ - _MSG("Open : %s\n", Tags[ni].name); - Tags[ni].open (html, tag, tagsize); - - if (tagIsDisplayEnabled) { + if (! html->styleEngine->initialized () + || html->styleEngine->style ()->display == DISPLAY_NONE) { + /* Call the open function for this tag */ + Tags[ni].open (html, tag, tagsize); + switch (html->styleEngine->style ()->display) { case DISPLAY_BLOCK: Html_display_block(html); @@ -3549,7 +3521,6 @@ (strchr(" \"'", tag[tagsize-3]) || /* [ "']/> */ (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* */ - _MSG("Close: %s\n", Tags[ni].name); Html_tag_cleanup_at_close(html, ni); /* This was a close tag */ html->ReqTagClose = false; diff -r 440fa7e952bd src/styleengine.cc --- a/src/styleengine.cc Tue Dec 08 18:46:31 2009 +0100 +++ b/src/styleengine.cc Wed Dec 09 00:48:03 2009 +0100 @@ -567,6 +567,10 @@ return Style::create (layout, &attrs); } +bool StyleEngine::initialized () { + return stack->getRef (stack->size () - 1)->style != NULL; +} + /** * \brief Create a new style object based on the previously opened / closed * HTML elements and the nonCssProperties that have been set. @@ -585,7 +589,7 @@ // If this assertion is hit, you need to rearrange the code that is // doing styleEngine calls to call setNonCssHints() before calling // style() or wordStyle() for each new element. - assert (stack->getRef (stack->size () - 1)->style == NULL); + assert (! StyleEngine::initialized()); // reset values that are not inherited according to CSS attrs.resetValues (); diff -r 440fa7e952bd src/styleengine.hh --- a/src/styleengine.hh Tue Dec 08 18:46:31 2009 +0100 +++ b/src/styleengine.hh Wed Dec 09 00:48:03 2009 +0100 @@ -59,6 +59,7 @@ return NULL; }; + bool initialized (); void parse (DilloHtml *html, DilloUrl *url, const char *buf, int buflen, CssOrigin origin); void startElement (int tag); From Johannes.Hofmann at gmx.de Wed Dec 9 18:56:55 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 9 18:59:32 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091208235454.GB3668@tim-laptop.tux> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> Message-ID: <20091209175647.GA899@blob.baaderstrasse.com> Hi Tim, On Wed, Dec 09, 2009 at 12:54:54AM +0100, Tim Nieradzik wrote: > In my opinion, these changes make sense indeed as they provide a more > generic interface. > > Looking at quirkmode's "display: list-item"-demo, listStylePosition > seems to have a wrong value. The bullets are supposed to be drawn > outside the box but they appear inside. Did I understand your changes > correctly that listStylePosition is either 0 ("outside") or 1 ("inside") > because of that enum? > > See http://www.quirksmode.org/css/display.html I guess you're right, that the bullets should be outside the box, but due to the current implementation of ListItem it's inside even if listStylePosition is outside. However as long as you don't look at the border of the box, the behaviour is correct now, see e.g. http://de.selfhtml.org/css/eigenschaften/anzeige/list_style_position.htm > > I tried to implement "display: none" but the contents are still visible. > I also worked on getting rid of tagIsDisplayEnabled but I am yet > uncertain whether it is safe how approached it. Any comments? Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as you did here :-) I'm still uncertain on what to do in case that DISPLAY_NONE is set. As you noticed it's not enough to not call the tag open functions, as text will still be added. Also I don't know, whether e.g. inputs in forms which have DISPLAY_NONE, should send their contents to the server in case of submit, or should they be just non-existent? Regarding tagIsDisplayEnabled, I don't quite follow what you intended? I had added this flag to gradually transform the Html_tag_open_*() functions to the new display handling. It can only be removed once all these functions have been converted. Hm, maybe you are right and as long as the corresponding tags are set to DISPLAY_INLINE, which is the default, it would work even without the tagIsDisplayEnabled flag. Anyway, I think it's still a good marker to see which functions have been converted. Regards, Johannes > > --Tim > diff -r 440fa7e952bd dw/style.hh > --- a/dw/style.hh Tue Dec 08 18:46:31 2009 +0100 > +++ b/dw/style.hh Wed Dec 09 00:48:03 2009 +0100 > @@ -253,7 +253,8 @@ > DISPLAY_TABLE_FOOTER_GROUP, > DISPLAY_TABLE_ROW, > DISPLAY_TABLE_CELL, > - DISPLAY_LAST > + DISPLAY_LAST, > + DISPLAY_NONE > }; > > enum ListStylePosition { > diff -r 440fa7e952bd src/cssparser.cc > --- a/src/cssparser.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/cssparser.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -58,10 +58,10 @@ > "w-resize", "text", "wait", "help", NULL > }; > > -static const char *const Css_display_enum_vals[DISPLAY_LAST + 1] = { > +static const char *const Css_display_enum_vals[] = { > "block", "inline", "list-item", "table", "table-row-group", > "table-header-group", "table-footer-group", "table-row", > - "table-cell", NULL > + "table-cell", "last", "none", NULL > }; > > static const char *const Css_font_size_enum_vals[] = { > diff -r 440fa7e952bd src/html.cc > --- a/src/html.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/html.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -1282,7 +1282,7 @@ > TagInfo toptag = Tags[toptag_idx]; > if (s_sz > idx + 1 && toptag.EndTag != 'O') > BUG_MSG(" - forcing close of open tag: <%s>\n", toptag.name); > - _MSG("Close: %*s%s\n", size," ", toptag.name); > + _MSG("Close: %*s%s\n", s_sz, " ", toptag.name); > toptag.close(html, toptag_idx); > Html_real_pop_tag(html); > } > @@ -1528,13 +1528,6 @@ > } > > /* > - * By setting this to true, a Html_tag_open* function indicates that > - * the common display handling code should be used. > - * TODO: convert all Html_tag_open* functions and remove this variable. > - */ > -static bool tagIsDisplayEnabled; > - > -/* > * Handle open HTML element > */ > static void Html_tag_open_html(DilloHtml *html, const char *tag, int tagsize) > @@ -1876,8 +1869,6 @@ > a_Html_stash_init(html); > S_TOP(html)->parse_mode = > DILLO_HTML_PARSE_MODE_STASH_AND_BODY; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -1916,8 +1907,6 @@ > > html->styleEngine->setNonCssHints (&props); > dFree(fontFamily); > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -1926,7 +1915,7 @@ > static void Html_tag_open_abbr(DilloHtml *html, const char *tag, int tagsize) > { > const char *attrbuf; > - > + > if (prefs.show_tooltip && > (attrbuf = a_Html_get_attr(html, tag, tagsize, "title"))) { > CssPropertyList props; > @@ -1936,8 +1925,6 @@ > html->styleEngine->setNonCssHints (&props); > dFree(tooltip_str); > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2183,8 +2170,6 @@ > BUG_MSG("name attribute is required for \n"); > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2453,8 +2438,6 @@ > dFree(nameVal); > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2528,8 +2511,6 @@ > S_TOP(html)->list_type = HTML_LIST_UNORDERED; > S_TOP(html)->list_number = 0; > S_TOP(html)->ref_list_item = NULL; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2590,10 +2571,9 @@ > BUG_MSG( "illegal '-' character in START attribute; Starting from 0\n"); > n = 0; > } > + > S_TOP(html)->list_number = n; > S_TOP(html)->ref_list_item = NULL; > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -2621,8 +2601,6 @@ > *list_number = 0; > } > } > - > - tagIsDisplayEnabled = true; > } > > /* > @@ -3011,7 +2989,6 @@ > static void Html_tag_open_default(DilloHtml *html,const char *tag,int tagsize) > { > html->styleEngine->inheritBackgroundColor(); > - tagIsDisplayEnabled = true; > } > > /* > @@ -3023,7 +3000,6 @@ > > a_Html_tag_set_align_attr (html, &props, tag, tagsize); > html->styleEngine->setNonCssHints (&props); > - tagIsDisplayEnabled = true; > } > > /* > @@ -3418,11 +3394,11 @@ > ListItem *list_item; > int *list_number; > char buf[16]; > - > + > /* Get our parent tag's variables (used as state storage) */ > list_number = &html->stack->getRef(html->stack->size()-2)->list_number; > ref_list_item = &html->stack->getRef(html->stack->size()-2)->ref_list_item; > - > + > HT2TB(html)->addParbreak (0, wordStyle); > > list_item = new ListItem ((ListItem*)*ref_list_item,prefs.limit_text_width); > @@ -3430,7 +3406,7 @@ > HT2TB(html)->addParbreak (0, wordStyle); > *ref_list_item = list_item; > S_TOP(html)->textblock = html->dw = list_item; > - > + > if (style->listStyleType == LIST_STYLE_TYPE_NONE) { > // none > } else if (style->listStyleType >= LIST_STYLE_TYPE_DECIMAL) { > @@ -3496,15 +3472,11 @@ > /* Parse attributes that can appear on any tag */ > Html_parse_common_attrs(html, tag, tagsize); > > - /* Html_tag_open* function can set this to true to enable > - * generic CSS display handling. > - */ > - tagIsDisplayEnabled = false; > - /* Call the open function for this tag */ > - _MSG("Open : %s\n", Tags[ni].name); > - Tags[ni].open (html, tag, tagsize); > - > - if (tagIsDisplayEnabled) { > + if (! html->styleEngine->initialized () > + || html->styleEngine->style ()->display == DISPLAY_NONE) { > + /* Call the open function for this tag */ > + Tags[ni].open (html, tag, tagsize); > + > switch (html->styleEngine->style ()->display) { > case DISPLAY_BLOCK: > Html_display_block(html); > @@ -3549,7 +3521,6 @@ > (strchr(" \"'", tag[tagsize-3]) || /* [ "']/> */ > (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* */ > > - _MSG("Close: %s\n", Tags[ni].name); > Html_tag_cleanup_at_close(html, ni); > /* This was a close tag */ > html->ReqTagClose = false; > diff -r 440fa7e952bd src/styleengine.cc > --- a/src/styleengine.cc Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/styleengine.cc Wed Dec 09 00:48:03 2009 +0100 > @@ -567,6 +567,10 @@ > return Style::create (layout, &attrs); > } > > +bool StyleEngine::initialized () { > + return stack->getRef (stack->size () - 1)->style != NULL; > +} > + > /** > * \brief Create a new style object based on the previously opened / closed > * HTML elements and the nonCssProperties that have been set. > @@ -585,7 +589,7 @@ > // If this assertion is hit, you need to rearrange the code that is > // doing styleEngine calls to call setNonCssHints() before calling > // style() or wordStyle() for each new element. > - assert (stack->getRef (stack->size () - 1)->style == NULL); > + assert (! StyleEngine::initialized()); > > // reset values that are not inherited according to CSS > attrs.resetValues (); > diff -r 440fa7e952bd src/styleengine.hh > --- a/src/styleengine.hh Tue Dec 08 18:46:31 2009 +0100 > +++ b/src/styleengine.hh Wed Dec 09 00:48:03 2009 +0100 > @@ -59,6 +59,7 @@ > return NULL; > }; > > + bool initialized (); > void parse (DilloHtml *html, DilloUrl *url, const char *buf, int buflen, > CssOrigin origin); > void startElement (int tag); From tim.nieradzik at gmx.de Wed Dec 9 21:07:53 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Dec 9 21:08:27 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209175647.GA899@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> Message-ID: <20091209200753.GE3653@tim-laptop.tux> > Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as > you did here :-) Oh, I just had a look at your private repository and noticed that it wasn't yet implemented. :) > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > As you noticed it's not enough to not call the tag open functions, > as text will still be added. I'd suggest to add the elements to the dw representation regardless of their "display" value. But we should introduce a 'flag' that disables drawing of elements with "display: none". > Also I don't know, whether e.g. inputs in forms which have > DISPLAY_NONE, should send their contents to the server in case of > submit, or should they be just non-existent? Since CSS only "describes the presentation semantics" (Wikipedia), the form elements are still available but 'hidden'. In Gecko, the DOM contains hidden elements as well. "display: none" is commonly used for menus: With the help of JavaScript, you could fiddle inside the DOM and toggle "display"-value to make the submenu visible. > Regarding tagIsDisplayEnabled, I don't quite follow what you > intended? I had added this flag to gradually transform the > Html_tag_open_*() functions to the new display handling. It > can only be removed once all these functions have been converted. I thought the only sense in implementing tagIsDisplayEnabled was to prevent Dillo to crash? While playing around with DISPLAY_NONE detection, the "stack->getRef (stack->size () - 1)->style == NULL" assert failed for Html_tag_open_body(). Checking html->styleEngine->style ()->display for DISPLAY_NONE resulted in initializing the style engine too early. > Hm, maybe you are right and as long as the corresponding tags are > set to DISPLAY_INLINE, which is the default, it would work even > without the tagIsDisplayEnabled flag. Anyway, I think it's still a > good marker to see which functions have been converted. To what extent would they need to be converted? Why do we care at all if a tag supports the "display" attribute? --Tim From corvid at lavabit.com Wed Dec 9 21:07:16 2009 From: corvid at lavabit.com (corvid) Date: Wed Dec 9 21:11:39 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209175647.GA899@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> Message-ID: <20091209200716.GA2749@local.gobigwest.com> Johannes wrote: > Also I don't know, whether e.g. inputs in forms which have > DISPLAY_NONE, should send their contents to the server in case of > submit, or should they be just non-existent? I'm not aware of anything in html4 about that case. I think css2 says somewhere that it doesn't specify what to do with forms. From corvid at lavabit.com Wed Dec 9 21:47:46 2009 From: corvid at lavabit.com (corvid) Date: Wed Dec 9 21:52:08 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209200753.GE3653@tim-laptop.tux> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> Message-ID: <20091209204746.GC2749@local.gobigwest.com> Tim wrote: > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. This sounds right to me, too. I'll take a look at preventing them from being drawn and taking up space. Also, iterators would have to ignore undisplayed words for copying text. Is there any case where iterators would need to be able to notice them? From tim.nieradzik at gmx.de Wed Dec 9 23:02:57 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Dec 9 23:03:23 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209204746.GC2749@local.gobigwest.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209204746.GC2749@local.gobigwest.com> Message-ID: <20091209220257.GF3653@tim-laptop.tux> > Is there any case where iterators would need to be able to notice them? No, I don't think so. As for form submitting (src/form.cc) the EmbedIterator is not used at all. The input fields refer directly to the matching embed object (see Html_add_input()). --Tim From Johannes.Hofmann at gmx.de Wed Dec 9 23:03:42 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 9 23:06:14 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209204746.GC2749@local.gobigwest.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209204746.GC2749@local.gobigwest.com> Message-ID: <20091209220342.GA893@blob.baaderstrasse.com> On Wed, Dec 09, 2009 at 08:47:46PM +0000, corvid wrote: > Tim wrote: > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > > As you noticed it's not enough to not call the tag open functions, > > > as text will still be added. > > > > I'd suggest to add the elements to the dw representation regardless of > > their "display" value. > > This sounds right to me, too. I'll take a look at preventing them from > being drawn and taking up space. Great, it showing and hiding of hidden form entries works nicely already. > > Also, iterators would have to ignore undisplayed words for copying text. > Is there any case where iterators would need to be able to notice them? No, I don't thinks so. For searching and text selection it should not be needed. From Johannes.Hofmann at gmx.de Wed Dec 9 23:17:51 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 9 23:20:22 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091209200753.GE3653@tim-laptop.tux> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> Message-ID: <20091209221751.GC893@blob.baaderstrasse.com> On Wed, Dec 09, 2009 at 09:07:53PM +0100, Tim Nieradzik wrote: > > Just yesterday, I added the DISPLAY_NONE to dillo mainline, just as > > you did here :-) > > Oh, I just had a look at your private repository and noticed that it > wasn't yet implemented. :) > > > I'm still uncertain on what to do in case that DISPLAY_NONE is set. > > As you noticed it's not enough to not call the tag open functions, > > as text will still be added. > > I'd suggest to add the elements to the dw representation regardless of > their "display" value. But we should introduce a 'flag' that disables > drawing of elements with "display: none". > > > Also I don't know, whether e.g. inputs in forms which have > > DISPLAY_NONE, should send their contents to the server in case of > > submit, or should they be just non-existent? > > Since CSS only "describes the presentation semantics" (Wikipedia), the > form elements are still available but 'hidden'. In Gecko, the DOM > contains hidden elements as well. "display: none" is commonly used for > menus: With the help of JavaScript, you could fiddle inside the DOM and > toggle "display"-value to make the submenu visible. Yes, that's a problem. We definately need a way to toggle the hidden state. Otherwise pages get less accessible as we don't support JavaScript. > > > Regarding tagIsDisplayEnabled, I don't quite follow what you > > intended? I had added this flag to gradually transform the > > Html_tag_open_*() functions to the new display handling. It > > can only be removed once all these functions have been converted. > > I thought the only sense in implementing tagIsDisplayEnabled was to > prevent Dillo to crash? While playing around with DISPLAY_NONE > detection, the "stack->getRef (stack->size () - 1)->style == NULL" > assert failed for Html_tag_open_body(). Checking > html->styleEngine->style ()->display for DISPLAY_NONE resulted in > initializing the style engine too early. > > > Hm, maybe you are right and as long as the corresponding tags are > > set to DISPLAY_INLINE, which is the default, it would work even > > without the tagIsDisplayEnabled flag. Anyway, I think it's still a > > good marker to see which functions have been converted. > > To what extent would they need to be converted? Why do we care at all if > a tag supports the "display" attribute? Currently the Html_tag_open_*() functions add textblocks, or parbreaks as it fits. The idea is to convert them so that they only do HTML specific attribute parsing, setNonCssHints()-handling, and HTML error reporting. Building the dw widget tree would be solely determined by the current style (mainly the display part). I want to make this transition gradually, leaving e.g. forms and tables as they are atm. Cheers, Johannes From tim.nieradzik at gmx.de Fri Dec 11 22:53:17 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Fri Dec 11 22:53:43 2009 Subject: [Dillo-dev] Adding CSS properties and values Message-ID: <20091211215317.GC3677@tim-laptop.tux> I've just started work on support for the "float" property but I'm already running into difficulties when trying to add the detection for its values. Every website gets screwed up after applying my patch. Any ideas? --Tim -------------- next part -------------- diff --git a/src/css.hh b/src/css.hh index 79ba302..815c14a 100644 --- a/src/css.hh +++ b/src/css.hh @@ -166,7 +166,9 @@ typedef enum { CSS_PROPERTY_DIRECTION, CSS_PROPERTY_DISPLAY, CSS_PROPERTY_EMPTY_CELLS, - CSS_PROPERTY_FLOAT, + CSS_PROPERTY_FLOAT_LEFT, + CSS_PROPERTY_FLOAT_RIGHT, + CSS_PROPERTY_FLOAT_NONE, CSS_PROPERTY_FONT_FAMILY, CSS_PROPERTY_FONT_SIZE, CSS_PROPERTY_FONT_SIZE_ADJUST, diff --git a/src/cssparser.cc b/src/cssparser.cc index 5f5bde0..4b6c2ad 100644 --- a/src/cssparser.cc +++ b/src/cssparser.cc @@ -101,6 +101,10 @@ static const char *const Css_text_decoration_enum_vals[] = { "underline", "overline", "line-through", "blink", NULL }; +static const char *const Css_float_enum_vals[] = { + "left", "right", "none", NULL +}; + static const char *const Css_vertical_align_vals[] = { "top", "bottom", "middle", "baseline", "sub", "super", NULL }; @@ -145,7 +149,7 @@ const CssPropertyInfo Css_property_info[CSS_PROPERTY_LAST] = { {"direction", {CSS_TYPE_UNUSED}, NULL}, {"display", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_display_enum_vals}, {"empty-cells", {CSS_TYPE_UNUSED}, NULL}, - {"float", {CSS_TYPE_UNUSED}, NULL}, + {"float", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_float_enum_vals}, {"font-family", {CSS_TYPE_SYMBOL, CSS_TYPE_UNUSED}, NULL}, {"font-size", {CSS_TYPE_ENUM, CSS_TYPE_LENGTH_PERCENTAGE, CSS_TYPE_UNUSED}, Css_font_size_enum_vals}, From Johannes.Hofmann at gmx.de Fri Dec 11 23:08:50 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Dec 11 23:11:21 2009 Subject: [Dillo-dev] Adding CSS properties and values In-Reply-To: <20091211215317.GC3677@tim-laptop.tux> References: <20091211215317.GC3677@tim-laptop.tux> Message-ID: <20091211220850.GA3884@blob.baaderstrasse.com> Hi Tim, On Fri, Dec 11, 2009 at 10:53:17PM +0100, Tim Nieradzik wrote: > I've just started work on support for the "float" property but I'm > already running into difficulties when trying to add the detection for > its values. > > Every website gets screwed up after applying my patch. Any ideas? The problem is that you added more CSS_PROPERTY_* values. The CSS_PROPERTY_* values need to correspond with the CssPropertyInfo in cssparser.cc. By inserting CSS_PROPERTY_* values all properties after CSS_PROPERTY_FLOAT_LEFT will no longer match. But you don't need to add CSS_PROPERTY_* values anyway. There is one CSS_PROPERTY_* value for each CSS property (http://www.w3.org/TR/CSS2/). For floats there is only one property "float" for which there is already CSS_PROPERTY_FLOAT in css.hh. It can have the values you correctly defined in Css_float_enum_vals. So your patch looks good, just leave out the change in css.hh. But that was the easy part... The real problem is what to do with those values. We need a way to render floating elements in dw/* Johannes > > --Tim > diff --git a/src/css.hh b/src/css.hh > index 79ba302..815c14a 100644 > --- a/src/css.hh > +++ b/src/css.hh > @@ -166,7 +166,9 @@ typedef enum { > CSS_PROPERTY_DIRECTION, > CSS_PROPERTY_DISPLAY, > CSS_PROPERTY_EMPTY_CELLS, > - CSS_PROPERTY_FLOAT, > + CSS_PROPERTY_FLOAT_LEFT, > + CSS_PROPERTY_FLOAT_RIGHT, > + CSS_PROPERTY_FLOAT_NONE, > CSS_PROPERTY_FONT_FAMILY, > CSS_PROPERTY_FONT_SIZE, > CSS_PROPERTY_FONT_SIZE_ADJUST, > diff --git a/src/cssparser.cc b/src/cssparser.cc > index 5f5bde0..4b6c2ad 100644 > --- a/src/cssparser.cc > +++ b/src/cssparser.cc > @@ -101,6 +101,10 @@ static const char *const Css_text_decoration_enum_vals[] = { > "underline", "overline", "line-through", "blink", NULL > }; > > +static const char *const Css_float_enum_vals[] = { > + "left", "right", "none", NULL > +}; > + > static const char *const Css_vertical_align_vals[] = { > "top", "bottom", "middle", "baseline", "sub", "super", NULL > }; > @@ -145,7 +149,7 @@ const CssPropertyInfo Css_property_info[CSS_PROPERTY_LAST] = { > {"direction", {CSS_TYPE_UNUSED}, NULL}, > {"display", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_display_enum_vals}, > {"empty-cells", {CSS_TYPE_UNUSED}, NULL}, > - {"float", {CSS_TYPE_UNUSED}, NULL}, > + {"float", {CSS_TYPE_ENUM, CSS_TYPE_UNUSED}, Css_float_enum_vals}, > {"font-family", {CSS_TYPE_SYMBOL, CSS_TYPE_UNUSED}, NULL}, > {"font-size", {CSS_TYPE_ENUM, CSS_TYPE_LENGTH_PERCENTAGE, CSS_TYPE_UNUSED}, > Css_font_size_enum_vals}, > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev From Johannes.Hofmann at gmx.de Sat Dec 12 21:37:55 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Dec 12 21:40:29 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091211195318.GA2037@blob.baaderstrasse.com> References: <20091205201045.GD13740@tim-laptop.tux> <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209221751.GC893@blob.baaderstrasse.com> <20091211074633.GB2750@local.gobigwest.com> <20091211195318.GA2037@blob.baaderstrasse.com> Message-ID: <20091212203749.GA3031@blob.baaderstrasse.com> Hi, On Fri, Dec 11, 2009 at 08:53:18PM +0100, Johannes Hofmann wrote: > Hi, > > On Fri, Dec 11, 2009 at 07:46:33AM +0000, corvid wrote: > > Here's the nightmarish hackery that I ended up with > > while getting show/hide to work on display:none. > > There might be issues with the implementation - I need to look at it > in more detail - but the result is pretty amazing! > > Let me check your patch in detail... > > > bleh. > > But I realized it still won't work right for the case like > >
        > > > >
        > > > >
        > >
        > > because I would have to start digging into display:none Textblocks in > > search of not-display:none form things, but then normally you don't want > > to display not-display:none things inside display:none...so...ummm... > > this is all a demonstration of what not to do. > > As for what _would_ be non-horrible, good question. > > > > I suppose a way just to toggle whether display:none is obeyed at all > > might be nicer for us, albeit not for the user. Ok, I understand your concerns now. It might be better to simply not create dw-widgets in the display:none case. At least we should try that option to see if it's simpler. My reasons are: * we would not pollute dw/* which is complex already. dw/* would not look at style.display at all. * as Tim mentioned, you can always switch off remote CSS to see display:none stuff. * it does not mean that elements with display:none would not be part of the DOM tree, as the DOM tree will be separate from the widget tree. I also understand now your's and Tim's concerns about the style pointer in struct Word. As soon as we start to modify styles in an existing widget tree we will get into trouble with all those pointers as we can't modify style objects in place. So I would propose to do display handling in html.cc. Then we can convert Doctree to a real DOM tree. With that in place we can come back to the style in struct Word issue. We might simply have a pointer to the corresponding DoctreeNode, which could hold the style. We might even drop the style sharing code then - but let's see. Here comes a simple example to demonstrate why I think DOM-tree and widget tree should be separate - and I suppose that this is what Sebastian also had in mind with his CSS plan. This piece of HTML:
        • foo
        • bar
        results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ / \ li li AlignedTextblock AlignedTextblock | b whereas:
        • foo
        • bar
        results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ | li li AlignedTextblock | b Cheers, Johannes From corvid at lavabit.com Sat Dec 12 22:38:20 2009 From: corvid at lavabit.com (corvid) Date: Sat Dec 12 22:42:44 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091212203749.GA3031@blob.baaderstrasse.com> References: <20091205231513.GA19345@blob.baaderstrasse.com> <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209221751.GC893@blob.baaderstrasse.com> <20091211074633.GB2750@local.gobigwest.com> <20091211195318.GA2037@blob.baaderstrasse.com> <20091212203749.GA3031@blob.baaderstrasse.com> Message-ID: <20091212213820.GA2782@local.gobigwest.com> Johannes wrote: > Ok, I understand your concerns now. > It might be better to simply not create dw-widgets in the > display:none case. At least we should try that option to see if it's > simpler. My reasons are: > > * we would not pollute dw/* which is complex already. > dw/* would not look at style.display at all. > * as Tim mentioned, you can always switch off remote CSS to see > display:none stuff. > * it does not mean that elements with display:none would not be part > of the DOM tree, as the DOM tree will be separate from the widget tree. > > I also understand now your's and Tim's concerns about the style > pointer in struct Word. As soon as we start to modify styles in an > existing widget tree we will get into trouble with all those > pointers as we can't modify style objects in place. > > So I would propose to do display handling in html.cc. Your suggestion seems quite sensible to me now :) > Then we can convert Doctree to a real DOM tree. With that in place > we can come back to the style in struct Word issue. We might simply > have a pointer to the corresponding DoctreeNode, which could hold > the style. We might even drop the style sharing code then - but > let's see. Would dw/ understand the contents of DocTreeNodes? From Johannes.Hofmann at gmx.de Sat Dec 12 22:58:58 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Dec 12 23:01:30 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091212213820.GA2782@local.gobigwest.com> References: <20091206020425.GB26156@tim-laptop.tux> <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209221751.GC893@blob.baaderstrasse.com> <20091211074633.GB2750@local.gobigwest.com> <20091211195318.GA2037@blob.baaderstrasse.com> <20091212203749.GA3031@blob.baaderstrasse.com> <20091212213820.GA2782@local.gobigwest.com> Message-ID: <20091212215858.GA4304@blob.baaderstrasse.com> On Sat, Dec 12, 2009 at 09:38:20PM +0000, corvid wrote: > Johannes wrote: > > Ok, I understand your concerns now. > > It might be better to simply not create dw-widgets in the > > display:none case. At least we should try that option to see if it's > > simpler. My reasons are: > > > > * we would not pollute dw/* which is complex already. > > dw/* would not look at style.display at all. > > * as Tim mentioned, you can always switch off remote CSS to see > > display:none stuff. > > * it does not mean that elements with display:none would not be part > > of the DOM tree, as the DOM tree will be separate from the widget tree. > > > > I also understand now your's and Tim's concerns about the style > > pointer in struct Word. As soon as we start to modify styles in an > > existing widget tree we will get into trouble with all those > > pointers as we can't modify style objects in place. > > > > So I would propose to do display handling in html.cc. > > Your suggestion seems quite sensible to me now :) Let's see :) > > > Then we can convert Doctree to a real DOM tree. With that in place > > we can come back to the style in struct Word issue. We might simply > > have a pointer to the corresponding DoctreeNode, which could hold > > the style. We might even drop the style sharing code then - but > > let's see. > > Would dw/ understand the contents of DocTreeNodes? Sorry, what I said was misleading. dw/ would not include doctree.hh. However we could have one style object per DocTreeNode and then all objects in the widget tree (widgets or struct Words) that correspond to that DocTreeNode could point to that single style object - which we could then modify in place. The main link between DocTree and widget tree would be the other way round. Each DocTreeNode would have a pointer to the widget that is responsible for displaying it - we might need further information like the word indices if a single widget displays multiple DocTreeNodes. From tim.nieradzik at gmx.de Sun Dec 13 03:21:23 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Sun Dec 13 03:21:48 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091212215858.GA4304@blob.baaderstrasse.com> References: <20091208175654.GA4339@blob.baaderstrasse.com> <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209221751.GC893@blob.baaderstrasse.com> <20091211074633.GB2750@local.gobigwest.com> <20091211195318.GA2037@blob.baaderstrasse.com> <20091212203749.GA3031@blob.baaderstrasse.com> <20091212213820.GA2782@local.gobigwest.com> <20091212215858.GA4304@blob.baaderstrasse.com> Message-ID: <20091213022123.GA15730@tim-laptop.tux> I am still uncertain whether doing the display:none handling in src/Html.cc is really superior. What I liked about corvid's approach is the simplicity of the changes. It did not really involve any fundamental changes. Furthermore, I think handling of hidden elements is generally better suited in dw/ because it's design-related. It would make the whole separation useless, if we mixed parsing code with complex evaluation-logic. Moreover, it should be possible to use the dw-stack completely independent from Dillo's parsing code. Otherwise, this isn't necessarily the case as the developer needs to implement hiding manually. We could also apply display:none to hidden form elements (what I've tried in my patch). This is an advantage because dw's focus is not only HTML and CSS. It should be usable for any other markup as well. Therefore, I'd propose to introduce a general 'hidden' attribute applicable to any element. In the parsing code, hidden HTML form fields are simply converted and internally represented by an ordinary text field which, however, is not displayed. I haven't done any benchmarks but I guess this approach is more efficient in terms of memory usage and rendering speed. It doesn't require to render the whole page repeatedly from scratch when hidden elements are made visible as only a flag needs to be set. It's not required to add new widgets to the dw-layout as with the other approach. As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply that the entire dw-tree in memory is freed and then reallocated afterwards - just because one was made visible! Would the code be really shorter if done in src/Html.cc? I doubt that as we'd still need to check for the "display" value. Actually the patch doesn't do any more than that. So the benefits wouldn't be that striking. While I really like the idea of a DOM, I am somewhat concerned about the performance. A DOM is great when it comes to manipulating the design at runtime. It can be also useful for debugging purposes. However, as Dillo does not aim to support JavaScript there is virtually no need for a DOM. dw seems pretty flexible already and I guess it wouldn't be very difficult to do minor contents manipulation stuff. If understood your DocTree concept correctly, we won't end up with duplication as the DocTree represents both the contents and the style whereas dw only takes care about rendering, right? This sounds interesting but wouldn't it also mean that partial changes to the layout (or contents) would result in re-rendering the whole page? Therefore, I'd endorse the DocTree concept if there were some kind of 'change stack'. Changes can be 'reverted' and 'committed'. A commit then leads to only render the changes. (This idea might also come in handy with slow connections because we can make the 'commit'-rate dependent on the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require only one 'commit' whereas with slower connections there might be more. How is this currently realized in Dillo, by the way?) --Tim From Johannes.Hofmann at gmx.de Sun Dec 13 12:16:54 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Dec 13 12:19:27 2009 Subject: [Dillo-dev] display: inline In-Reply-To: <20091213022123.GA15730@tim-laptop.tux> References: <20091208235454.GB3668@tim-laptop.tux> <20091209175647.GA899@blob.baaderstrasse.com> <20091209200753.GE3653@tim-laptop.tux> <20091209221751.GC893@blob.baaderstrasse.com> <20091211074633.GB2750@local.gobigwest.com> <20091211195318.GA2037@blob.baaderstrasse.com> <20091212203749.GA3031@blob.baaderstrasse.com> <20091212213820.GA2782@local.gobigwest.com> <20091212215858.GA4304@blob.baaderstrasse.com> <20091213022123.GA15730@tim-laptop.tux> Message-ID: <20091213111647.GA1033@blob.baaderstrasse.com> Hi Tim, On Sun, Dec 13, 2009 at 03:21:23AM +0100, Tim Nieradzik wrote: > I am still uncertain whether doing the display:none handling in > src/Html.cc is really superior. What I liked about corvid's approach is > the simplicity of the changes. It did not really involve any fundamental > changes. I'm not 100% sure yet either. > > Furthermore, I think handling of hidden elements is generally better > suited in dw/ because it's design-related. It would make the whole > separation useless, if we mixed parsing code with complex > evaluation-logic. Moreover, it should be possible to use the dw-stack > completely independent from Dillo's parsing code. Otherwise, this isn't > necessarily the case as the developer needs to implement hiding > manually. Well, I'm not sure if a independent widget library absolutely needs hiding / unhiding to be useful. > > We could also apply display:none to hidden form elements (what I've > tried in my patch). This is an advantage because dw's focus is not only > HTML and CSS. It should be usable for any other markup as well. > Therefore, I'd propose to introduce a general 'hidden' attribute > applicable to any element. In the parsing code, hidden HTML form fields > are simply converted and internally represented by an ordinary text > field which, however, is not displayed. I would agree if we would just have display:none and display:true or so. But to implement e.g. display:block, we need to add a new textblock or for tables we have to add a table widget. And this has to be done in html.cc as the complete structure of the widget tree is affected. But if we handle all values of display: other than "none" in html.cc, then why not handle "none" there as well? Also using display:none to hide form elements is a bit problematic, because then we loose the original value of display. When the user clicks "show hiddens", should we switch to display:block, or display:inline? > > I haven't done any benchmarks but I guess this approach is more > efficient in terms of memory usage and rendering speed. It doesn't > require to render the whole page repeatedly from scratch when hidden > elements are made visible as only a flag needs to be set. It's not > required to add new widgets to the dw-layout as with the other approach. > As for big pages (HTML manuals with 2-5 MiB), otherwise it would imply > that the entire dw-tree in memory is freed and then reallocated > afterwards - just because one was made visible! For now we might simply not imlement a show display:none option. And for form elements we have it in place already. If we would implement changing the value of display: in place, then we would also have to support a change from e.g. inline to block. Additionally, I don't see a reason why we would have to through away the entire dw-tree in that case. We could just modify it in place and request a redraw. > > Would the code be really shorter if done in src/Html.cc? I doubt that as > we'd still need to check for the "display" value. Actually the patch > doesn't do any more than that. So the benefits wouldn't be that > striking. > > While I really like the idea of a DOM, I am somewhat concerned about the > performance. A DOM is great when it comes to manipulating the design at > runtime. It can be also useful for debugging purposes. However, as Dillo > does not aim to support JavaScript there is virtually no need for a DOM. > dw seems pretty flexible already and I guess it wouldn't be very > difficult to do minor contents manipulation stuff. We already have a DOM tree - though a degenerated one. It is needed for CSS (see styleengine.cc and doctree.hh). It would be pretty simple to expand it to a real tree (it's a stack atm). As you said, this would be needed for manipulating the layout at runtime (e.g. for :hover), for CSS adjacent sibling matching, and for JavaScript. > > If understood your DocTree concept correctly, we won't end up with > duplication as the DocTree represents both the contents and the style > whereas dw only takes care about rendering, right? This sounds > interesting but wouldn't it also mean that partial changes to the layout > (or contents) would result in re-rendering the whole page? > > Therefore, I'd endorse the DocTree concept if there were some kind of > 'change stack'. Changes can be 'reverted' and 'committed'. A commit then > leads to only render the changes. (This idea might also come in handy > with slow connections because we can make the 'commit'-rate dependent on > the transfer speed. Thus, a 500 KiB website with 1 MiB/s will require > only one 'commit' whereas with slower connections there might be more. > How is this currently realized in Dillo, by the way?) You can already modify the widget tree and only the modified stuff will be redrawn. It's implemented in dw/*. Cheers, Johannes From Johannes.Hofmann at gmx.de Mon Dec 14 20:01:21 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Dec 14 20:06:33 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091202174227.GB1976@blob.baaderstrasse.com> References: <20091126082225.GD7584@omphalos.singularity> <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> Message-ID: <20091214190058.GA2962@blob.baaderstrasse.com> On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > furaisanjin wrote: > > > 2. When URL is given on address bar, cursor stays on address bar after > > > the page rendering finishes. This isn't side effect. This may be > > > matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > > > (My local public library's site, if used in firefox, likes to reset > > form fields with javascript when a page finishes loading, and it's > > irritating.) > > What do all think about attached patch. It switches the focus when > the user hits return. > So the focus switch does not happen at some random time when the > page has loaded which might be irritating. Any opinions? Does this solve the problem? Cheers, Johannes > > Cheers, > Johannes > diff -r a41372a38f02 src/ui.cc > --- a/src/ui.cc Wed Dec 02 17:40:33 2009 +0100 > +++ b/src/ui.cc Wed Dec 02 18:42:15 2009 +0100 > @@ -267,6 +267,7 @@ > * page. BUG: this must be investigated and reported to FLTK2 team */ > if (event_key() == ReturnKey) { > a_UIcmd_open_urlstr(a_UIcmd_get_bw_by_widget(i), i->value()); > + ui->focus_main(); > } > if (ui->get_panelmode() == UI_TEMPORARILY_SHOW_PANELS) { > ui->set_panelmode(UI_HIDDEN); From corvid at lavabit.com Tue Dec 15 02:46:31 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 15 02:50:52 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091214190058.GA2962@blob.baaderstrasse.com> References: <20091126113122.GB2645@dillo.org> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> Message-ID: <20091215014631.GC3000@local.gobigwest.com> Johannes wrote: > On Wed, Dec 02, 2009 at 06:42:27PM +0100, Johannes Hofmann wrote: > > On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > > > furaisanjin wrote: > > > > 2. When URL is given on address bar, cursor stays on address bar after > > > > the page rendering finishes. This isn't side effect. This may be > > > > matter of taste but I don't like this behavior. > > > > > > We'll need to be careful if changing focus in this case, since > > > the user may be in the middle of typing something somewhere. > > > > > > (My local public library's site, if used in firefox, likes to reset > > > form fields with javascript when a page finishes loading, and it's > > > irritating.) > > > > What do all think about attached patch. It switches the focus when > > the user hits return. > > So the focus switch does not happen at some random time when the > > page has loaded which might be irritating. > > Any opinions? Does this solve the problem? I like it. From furaisanjin at gmail.com Tue Dec 15 13:24:58 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Tue Dec 15 13:25:52 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091214190058.GA2962@blob.baaderstrasse.com> References: <20091126082225.GD7584@omphalos.singularity> <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> Message-ID: <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> 2009/12/15 Johannes Hofmann : > Any opinions? Does this solve the problem? Could you consider this patch? This solves both problems I reported. diff -r c38e7c577023 src/uicmd.cc --- a/src/uicmd.cc Thu Dec 10 21:50:17 2009 +0000 +++ b/src/uicmd.cc Tue Dec 15 21:17:49 2009 +0900 @@ -604,6 +604,7 @@ if (url) { a_Nav_push(bw, url); a_Url_free(url); + a_UIcmd_focus_main_area(bw); } } @@ -617,6 +618,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) { a_Nav_push(bw, url); + a_UIcmd_focus_main_area(bw); } static void UIcmd_open_url_nbw(BrowserWindow *new_bw, const DilloUrl *url) Regards, furaisanjin From Johannes.Hofmann at gmx.de Tue Dec 15 18:54:05 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Dec 15 18:56:37 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> References: <144aa14b0911260601w63c9e3abiefa9e257a55e2857@mail.gmail.com> <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> Message-ID: <20091215175405.GA1501@blob.baaderstrasse.com> On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > 2009/12/15 Johannes Hofmann : > > Any opinions? Does this solve the problem? > > Could you consider this patch? This solves both problems I reported. Looks good to me. Is this ok for all? If there are no complaints I would commit a slightly modified version (attached). Cheers, Johannes -------------- next part -------------- diff -r c38e7c577023 src/uicmd.cc --- a/src/uicmd.cc Thu Dec 10 21:50:17 2009 +0000 +++ b/src/uicmd.cc Tue Dec 15 18:52:11 2009 +0100 @@ -602,7 +602,7 @@ dFree(new_urlstr); if (url) { - a_Nav_push(bw, url); + a_UIcmd_open_url(bw, url); a_Url_free(url); } } @@ -617,6 +617,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUrl *url) { a_Nav_push(bw, url); + a_UIcmd_focus_main_area(bw); } static void UIcmd_open_url_nbw(BrowserWindow *new_bw, const DilloUrl *url) From corvid at lavabit.com Tue Dec 15 19:58:28 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 15 20:02:54 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091215175405.GA1501@blob.baaderstrasse.com> References: <20091126145312.GC2645@dillo.org> <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> Message-ID: <20091215185828.GB2764@local.gobigwest.com> Johannes wrote: > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > 2009/12/15 Johannes Hofmann : > > > Any opinions? Does this solve the problem? > > > > Could you consider this patch? This solves both problems I reported. > > Looks good to me. Is this ok for all? > If there are no complaints I would commit a slightly modified version (attached). I think I like having Location lose focus after I press enter. From tim.nieradzik at gmx.de Tue Dec 15 21:00:43 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Tue Dec 15 21:01:32 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091215185828.GB2764@local.gobigwest.com> References: <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> <20091215185828.GB2764@local.gobigwest.com> Message-ID: <20091215200043.GA3653@tim-laptop.tux> > I think I like having Location lose focus after I press enter. I agree. This would be nice. --Tim From Johannes.Hofmann at gmx.de Wed Dec 16 21:42:31 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 16 21:45:07 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091215185828.GB2764@local.gobigwest.com> References: <20091127184108.GA2425@blob.baaderstrasse.com> <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> <20091215185828.GB2764@local.gobigwest.com> Message-ID: <20091216204109.GA1471@blob.baaderstrasse.com> On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > 2009/12/15 Johannes Hofmann : > > > > Any opinions? Does this solve the problem? > > > > > > Could you consider this patch? This solves both problems I reported. > > > > Looks good to me. Is this ok for all? > > If there are no complaints I would commit a slightly modified version (attached). > > I think I like having Location lose focus after I press enter. but the patch I had proposed originally doesn't seem to fix all of furaisanjin's issues. E.g. when starting dillo with an URL on the commandline, the location bar will have the focus. Are there cases where my furaisanjin's patch causes unexpected switches of focus, i.e. not triggered directly by a user action? Cheers, Johannes From corvid at lavabit.com Thu Dec 17 01:37:36 2009 From: corvid at lavabit.com (corvid) Date: Thu Dec 17 01:41:59 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091216204109.GA1471@blob.baaderstrasse.com> References: <144aa14b0911272006o1ec55346y3df2a8d6078fa615@mail.gmail.com> <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> <20091215185828.GB2764@local.gobigwest.com> <20091216204109.GA1471@blob.baaderstrasse.com> Message-ID: <20091217003736.GB2725@local.gobigwest.com> Johannes wrote: > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > 2009/12/15 Johannes Hofmann : > > > > > Any opinions? Does this solve the problem? > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > Looks good to me. Is this ok for all? > > > If there are no complaints I would commit a slightly modified version (attached). > > > > I think I like having Location lose focus after I press enter. > > but the patch I had proposed originally doesn't seem to fix all of > furaisanjin's issues. E.g. when starting dillo with an URL on > the commandline, the location bar will have the focus. > > Are there cases where my furaisanjin's patch causes unexpected > switches of focus, i.e. not triggered directly by a user action? I've completely lost track of what various versions do; I'm just saying that typing in an address, pressing enter, and having focus switch from Location to Main is nice. From Johannes.Hofmann at gmx.de Thu Dec 17 21:40:34 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Dec 17 21:43:06 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091217003736.GB2725@local.gobigwest.com> References: <20091201211230.GA1802@blob.baaderstrasse.com> <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> <20091215185828.GB2764@local.gobigwest.com> <20091216204109.GA1471@blob.baaderstrasse.com> <20091217003736.GB2725@local.gobigwest.com> Message-ID: <20091217204033.GA1019@blob.baaderstrasse.com> On Thu, Dec 17, 2009 at 12:37:36AM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > > 2009/12/15 Johannes Hofmann : > > > > > > Any opinions? Does this solve the problem? > > > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > > > Looks good to me. Is this ok for all? > > > > If there are no complaints I would commit a slightly modified version (attached). > > > > > > I think I like having Location lose focus after I press enter. > > > > but the patch I had proposed originally doesn't seem to fix all of > > furaisanjin's issues. E.g. when starting dillo with an URL on > > the commandline, the location bar will have the focus. > > > > Are there cases where my furaisanjin's patch causes unexpected > > switches of focus, i.e. not triggered directly by a user action? > > I've completely lost track of what various versions do; > I'm just saying that typing in an address, pressing enter, and > having focus switch from Location to Main is nice. Ah ok. I just committed furaisanjin's patch with a minor change. I there should be unexpected focus switches please report them, so we can look it this again. Cheers, Johannes From corvid at lavabit.com Thu Dec 17 22:56:37 2009 From: corvid at lavabit.com (corvid) Date: Thu Dec 17 23:00:58 2009 Subject: [Dillo-dev] take_focus on a new tab In-Reply-To: <20091217204033.GA1019@blob.baaderstrasse.com> References: <144aa14b0912011514k3299b3b0tb5d6a5a0d0f00021@mail.gmail.com> <20091202002811.GA2816@local.gobigwest.com> <20091202174227.GB1976@blob.baaderstrasse.com> <20091214190058.GA2962@blob.baaderstrasse.com> <144aa14b0912150424t7b46afam25aa2ba8b6a3e067@mail.gmail.com> <20091215175405.GA1501@blob.baaderstrasse.com> <20091215185828.GB2764@local.gobigwest.com> <20091216204109.GA1471@blob.baaderstrasse.com> <20091217003736.GB2725@local.gobigwest.com> <20091217204033.GA1019@blob.baaderstrasse.com> Message-ID: <20091217215637.GB2749@local.gobigwest.com> Johannes wrote: > On Thu, Dec 17, 2009 at 12:37:36AM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Dec 15, 2009 at 06:58:28PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Tue, Dec 15, 2009 at 09:24:58PM +0900, furaisanjin wrote: > > > > > > 2009/12/15 Johannes Hofmann : > > > > > > > Any opinions? Does this solve the problem? > > > > > > > > > > > > Could you consider this patch? This solves both problems I reported. > > > > > > > > > > Looks good to me. Is this ok for all? > > > > > If there are no complaints I would commit a slightly modified version (attached). > > > > > > > > I think I like having Location lose focus after I press enter. > > > > > > but the patch I had proposed originally doesn't seem to fix all of > > > furaisanjin's issues. E.g. when starting dillo with an URL on > > > the commandline, the location bar will have the focus. > > > > > > Are there cases where my furaisanjin's patch causes unexpected > > > switches of focus, i.e. not triggered directly by a user action? > > > > I've completely lost track of what various versions do; > > I'm just saying that typing in an address, pressing enter, and > > having focus switch from Location to Main is nice. > > Ah ok. I just committed furaisanjin's patch with a minor change. I > there should be unexpected focus switches please report them, so we > can look it this again. Oh, I see the confusion now. I must have misapplied that last version somehow, because it wasn't changing focus for me, but now using that same patch from tip seems to be working fine. Sorry about that. From itsme_410 at yahoo.com Fri Dec 18 04:47:43 2009 From: itsme_410 at yahoo.com (Globe Trotter) Date: Fri Dec 18 04:48:38 2009 Subject: [Dillo-dev] dillo2.x on Fedora 12 Message-ID: <831306.84343.qm@web50908.mail.re2.yahoo.com> Hi, Any likelihood of getting some Fedora 12 dillo2 RPMS? Thanks for the great work!! Best, T From newman.x at gmail.com Fri Dec 18 12:26:57 2009 From: newman.x at gmail.com (Michal Nowak) Date: Fri Dec 18 12:27:52 2009 Subject: [Dillo-dev] dillo2.x on Fedora 12 In-Reply-To: <831306.84343.qm@web50908.mail.re2.yahoo.com> References: <831306.84343.qm@web50908.mail.re2.yahoo.com> Message-ID: <5e9a80350912180326j7fe943e2s134b1b793ecf68da@mail.gmail.com> On Fri, Dec 18, 2009 at 4:47 AM, Globe Trotter wrote: > Hi, > > Any likelihood of getting some Fedora 12 dillo2 RPMS? > You may try http://mnowak.fedorapeople.org/dillo2/ should be the last release. There are static RPMs for F-11 and SRPM, which you can rebuild yourself for F-12, when you have installed static FLTK2 http://mnowak.fedorapeople.org/fltk2/static/ Though, unlikely to have Dillo 2 in Fedora as a supported package due to FLTK2, which is used in Dillo 2, is unreleased version, we don't wanna in Fedora. (Anyway FLTK2 seemed to me dead, last time I've looked, anyway.) Unless Dillo 2 is based on some released and supported toolkit, Dillo 2 won't be Fedora-supported. > Thanks for the great work!! > > Best, > T Michal From corvid at lavabit.com Fri Dec 18 21:41:56 2009 From: corvid at lavabit.com (corvid) Date: Fri Dec 18 21:46:16 2009 Subject: [Dillo-dev] new fltk snapshot Message-ID: <20091218204156.GA2753@local.gobigwest.com> There's a new fltk2 snapshot with a change to the key handling code. I don't know whether it could make any difference for people who have had modifier problems, but it would probably be good to give it a try. http://fltk.org/articles.php?L958 From jcid at dillo.org Sun Dec 20 15:28:15 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Dec 20 15:28:57 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] Message-ID: <20091220142815.GC4962@dillo.org> Hi, I just received this email. The attached example shows the bug. Does anybody remember what we did with valign? ;) -- Cheers Jorge.- -------------- next part -------------- An embedded message was scrubbed... From: oph-villedieu Subject: dillo_2.1.1 Date: Sat, 19 Dec 2009 20:52:50 +0100 Size: 1775 Url: /pipermail/attachments/20091220/43ee0f95/attachment.mht -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091220/43ee0f95/valign.html From Johannes.Hofmann at gmx.de Sun Dec 20 17:33:03 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Dec 20 17:35:36 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] In-Reply-To: <20091220142815.GC4962@dillo.org> References: <20091220142815.GC4962@dillo.org> Message-ID: <20091220163303.GA869@blob.baaderstrasse.com> Hi, On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > Hi, > > I just received this email. The attached example shows the bug. > Does anybody remember what we did with valign? ;) > > > > I'm afraid I found a bug in this release (?) : > > it does not understand the html tag > > it reads instead > > #:-(( > > hoping it helps, > > best whishes for Christmas and New year, > > > > Edouard BENOIS (France) > > > > http://pagesperso-orange.fr/edouard.benois/photos.htm > > Ouch, that doesn't look good :-) > > > > > > > > >
        1
        2
        3 >         		* > * > * >
        > > I think we never supported valign=top | middle | bottom in dillo-fltk. We probabely need to implement it in Textblock::sizeAllocateImpl(). Cheers, Johannes From corvid at lavabit.com Sun Dec 20 20:08:42 2009 From: corvid at lavabit.com (corvid) Date: Sun Dec 20 20:13:01 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] In-Reply-To: <20091220163303.GA869@blob.baaderstrasse.com> References: <20091220142815.GC4962@dillo.org> <20091220163303.GA869@blob.baaderstrasse.com> Message-ID: <20091220190841.GA2772@local.gobigwest.com> Johannes wrote: > On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > I just received this email. The attached example shows the bug. > > Does anybody remember what we did with valign? ;) > > > > > > I'm afraid I found a bug in this release (?) : > > > it does not understand the html tag > > > it reads instead > I think we never supported valign=top | middle | bottom > in dillo-fltk. > We probabely need to implement it in Textblock::sizeAllocateImpl(). The vertical-align code I have around doesn't do anything for table cells. I guess I have increased incentive to clean up what I already have, at least. From corvid at lavabit.com Mon Dec 21 01:37:05 2009 From: corvid at lavabit.com (corvid) Date: Mon Dec 21 01:41:48 2009 Subject: [Dillo-dev] patch: vertical-align Message-ID: <20091221003705.GC2772@local.gobigwest.com> http://www.dillo.org/test/vertical-align.patch - this won't do anything for table cells - it sometimes won't do the right thing because it doesn't know what is yet to come later in the line - it calculates Y offsets for words when drawing them. It may be better to add a field to Word From corvid at lavabit.com Tue Dec 22 02:09:12 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 22 02:13:31 2009 Subject: [Dillo-dev] patch: vertical-align In-Reply-To: <20091221003705.GC2772@local.gobigwest.com> References: <20091221003705.GC2772@local.gobigwest.com> Message-ID: <20091222010912.GC2715@local.gobigwest.com> I just put up a new version. I had introduced a bug while cleaning up the code yesterday. I would've expected it to have broken everything quickly and horribly, but somehow I managed to run happily for hours before triggering the bug. From corvid at lavabit.com Tue Dec 22 04:23:10 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 22 04:27:58 2009 Subject: [Dillo-dev] patch: no size 0 images Message-ID: <20091222032310.GD2715@local.gobigwest.com> Just a little toy to ignore images of size 0. I also tried checking for display:none, but this made css very unhappy when it reached the noncss hints code later in the function. I didn't bother to try to fit it in with the neighboring code yet, since I don't know how well this will go over. So far, a bit of browsing has mostly shown me that there is a company at scorecardresearch.com that has infected a nontrivial portion of the web. (Of course we could still dig up the same-domain code and do something with that instead.) -------------- next part -------------- diff -r 6df6a0e4b2b9 src/html.cc --- a/src/html.cc Sun Dec 20 21:09:57 2009 +0000 +++ b/src/html.cc Tue Dec 22 02:49:57 2009 +0000 @@ -2010,6 +2010,14 @@ dFree(height_ptr); width_ptr = height_ptr = NULL; MSG("a_Html_image_new: suspicious image size request %dx%d\n", w, h); + } else if ((CSS_LENGTH_TYPE(l_w) != CSS_LENGTH_TYPE_AUTO && + CSS_LENGTH_VALUE(l_w) == 0) || + (CSS_LENGTH_TYPE(l_w) != CSS_LENGTH_TYPE_AUTO && + CSS_LENGTH_VALUE(l_w) == 0)) { + dFree(width_ptr); + dFree(height_ptr); + width_ptr = height_ptr = NULL; + MSG("a_Html_image_new: spy image %s ignored.\n", URL_STR(url)); } else { if (CSS_LENGTH_TYPE(l_w) != CSS_LENGTH_TYPE_AUTO) props.set (CSS_PROPERTY_WIDTH, CSS_TYPE_LENGTH_PERCENTAGE, l_w); From corvid at lavabit.com Wed Dec 23 20:28:40 2009 From: corvid at lavabit.com (corvid) Date: Wed Dec 23 20:32:58 2009 Subject: [Dillo-dev] dpi program names Message-ID: <20091223192211.GA2906@local.gobigwest.com> When talking with the submitter for bug#930, I found that he used --prefix, which meant that dpid couldn't be found when the directory wasn't in his path. --program-suffix, which meant that dillo wasn't going to find dpid anyway. (Apparently the dpis also had the suffix, which is probably not handled by anything, either.) To what degree do you think it would be reasonable to handle this? Teaching dillo to try the --prefix when searching for dpid is pretty easy, but when it comes to --program-suffix...well, I'm not sure whether that's hard to extract from autoconf or not, but there's also "--program-transform-name" which takes a sed program that transforms names into who-knows-what, and the prospect of teaching src/IO/dpi.c to know what happened over in dpid/ makes me want to write something in the FAQ about leaving the filenames themselves alone. PS I discovered that I could get vertical-align and table cells to pretty much work by making a TableCell::lineYOffsetWidgetAllocation (so much for having the Textblock version inline!). Something...somewhere...gets confused sometimes, though. Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in the redraw optimizations or something. From Johannes.Hofmann at gmx.de Wed Dec 23 22:43:03 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Dec 23 23:06:36 2009 Subject: [Dillo-dev] dpi program names In-Reply-To: <20091223192211.GA2906@local.gobigwest.com> References: <20091223192211.GA2906@local.gobigwest.com> Message-ID: <20091223214302.GB957@blob.baaderstrasse.com> On Wed, Dec 23, 2009 at 07:28:40PM +0000, corvid wrote: > When talking with the submitter for bug#930, I found that he used > --prefix, which meant that dpid couldn't be found when > the directory wasn't in his path. > --program-suffix, which meant that dillo wasn't going to find dpid > anyway. (Apparently the dpis also had the suffix, which is probably > not handled by anything, either.) > > To what degree do you think it would be reasonable to handle this? > > Teaching dillo to try the --prefix when searching for dpid is pretty > easy, but when it comes to --program-suffix...well, I'm not sure > whether that's hard to extract from autoconf or not, but there's also > "--program-transform-name" which takes a sed program that transforms > names into who-knows-what, and the prospect of teaching src/IO/dpi.c to > know what happened over in dpid/ makes me want to write something > in the FAQ about leaving the filenames themselves alone. We could do something about --prefix, but for the rest I would just add a note in the FAQ or improve error messages if necessary. > > > PS I discovered that I could get vertical-align and table cells to > pretty much work by making a TableCell::lineYOffsetWidgetAllocation > (so much for having the Textblock version inline!). Nice! > Something...somewhere...gets confused sometimes, though. > Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in > the redraw optimizations or something. If that's the case, i.e. it get's fixed by dragging another window over the dillo window, then I will try to fix that. Let's not hold off features because of this optimization thing. Cheers, Johannes From corvid at lavabit.com Thu Dec 24 08:50:18 2009 From: corvid at lavabit.com (corvid) Date: Thu Dec 24 08:54:36 2009 Subject: valign table cells (Re: [Dillo-dev] dpi program names) In-Reply-To: <20091223214302.GB957@blob.baaderstrasse.com> References: <20091223192211.GA2906@local.gobigwest.com> <20091223214302.GB957@blob.baaderstrasse.com> Message-ID: <20091224075018.GB2906@local.gobigwest.com> Johannes wrote: > On Wed, Dec 23, 2009 at 07:28:40PM +0000, corvid wrote: > > Something...somewhere...gets confused sometimes, though. > > Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in > > the redraw optimizations or something. > > If that's the case, i.e. it get's fixed by dragging another window > over the dillo window, then I will try to fix that. Let's not hold > off features because of this optimization thing. Luckily it turned out to be a bug in my code. I was using getContentHeight() when I needed to determine this manually from the passed allocation instead. From corvid at lavabit.com Thu Dec 24 10:35:12 2009 From: corvid at lavabit.com (corvid) Date: Thu Dec 24 10:39:29 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] In-Reply-To: <20091220163303.GA869@blob.baaderstrasse.com> References: <20091220142815.GC4962@dillo.org> <20091220163303.GA869@blob.baaderstrasse.com> Message-ID: <20091224093512.GC2906@local.gobigwest.com> Johannes wrote: > I think we never supported valign=top | middle | bottom > in dillo-fltk. > We probabely need to implement it in Textblock::sizeAllocateImpl(). I realized that my current solution, already known to be awfully inefficient, wouldn't let me implement baseline alignment. So, back to Table::sizeAllocateImpl(). When I had tried modifying y and descent here the other day, it put things in roughly the right place, but my problem was that the box drawn around the cell wouldn't reach to the top anymore. I imagine modifying the top padding value might help. Would that be an improper way to go about it? From bblochl at arcor.de Fri Dec 25 12:13:11 2009 From: bblochl at arcor.de (bb) Date: Fri Dec 25 12:14:36 2009 Subject: [Dillo-dev] web bug save? Message-ID: <4B349E47.1050506@arcor.de> *On http://www.dillo.org/ I found the item News and a remark: 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for malicious images. I am not shure what is meant with **malicious images? Are this so called Web bugs? If yes - how is the blocking done? I think there are some strategies possible to prevent a browser from a Web Bug attack: 1. Dont allow to load gifs or pngs from another URL as the actual page comes from. (I think to remember that firefox **originally **had such an option - not available in the actual version.) 2. I think one might prepare HTML/CSS not to load such gifs or pngs smaller than say about 5x5. Do you think such a measure is feasible in Dillo and could that really stop Web Bugs? But I think that there should not be a problem to make Web Bugs larger than 1x1pixel as long as they are transparent - may be I am wrong, I am just a simple minded user, not a web professional. So such a limit might be useless? Are there other ideas? I am highly interested in that Web Bug problem. Seasons greetings bblochl ** * From corvid at lavabit.com Fri Dec 25 18:46:22 2009 From: corvid at lavabit.com (corvid) Date: Fri Dec 25 18:50:37 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <4B349E47.1050506@arcor.de> References: <4B349E47.1050506@arcor.de> Message-ID: <20091225174621.GA2726@local.gobigwest.com> bb wrote: > *On http://www.dillo.org/ I found the item News and a remark: > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > malicious images. I am not shure what is meant with **malicious images? > Are this so called Web bugs? If yes - how is the blocking done? Here's the advisory about the image size problem: http://www.ocert.org/advisories/ocert-2009-008.html > I think there are some strategies possible to prevent a browser from a > Web Bug attack: > > 1. Dont allow to load gifs or pngs from another URL as the actual page > comes from. (I think to remember that firefox **originally **had such an > option - not available in the actual version.) Here's the beginning of a thread and a patch experimenting with this: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html (the "same host" option was found to be useless, but I'm still interested in "same domain") > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > smaller than say about 5x5. Do you think such a measure is feasible in > Dillo and could that really stop Web Bugs? But I think that there should > not be a problem to make Web Bugs larger than 1x1pixel as long as they > are transparent - may be I am wrong, I am just a simple minded user, not > a web professional. So such a limit might be useless? Here's a post and patch experimenting with rejecting images with a dimension of 0: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > Are there other ideas? I am highly interested in that Web Bug problem. I'm glad to hear this, since user interest may encourage things to happen... From Johannes.Hofmann at gmx.de Sat Dec 26 15:13:08 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Dec 26 15:15:39 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] In-Reply-To: <20091220190841.GA2772@local.gobigwest.com> References: <20091220142815.GC4962@dillo.org> <20091220163303.GA869@blob.baaderstrasse.com> <20091220190841.GA2772@local.gobigwest.com> Message-ID: <20091226141308.GA1336@blob.baaderstrasse.com> On Sun, Dec 20, 2009 at 07:08:42PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > I just received this email. The attached example shows the bug. > > > Does anybody remember what we did with valign? ;) > > > > > > > > I'm afraid I found a bug in this release (?) : > > > > it does not understand the html tag > > > > it reads instead > > > I think we never supported valign=top | middle | bottom > > in dillo-fltk. > > We probabely need to implement it in Textblock::sizeAllocateImpl(). > > The vertical-align code I have around doesn't do anything for table cells. > Can you share what you have so far? Cheers, Johannes From Johannes.Hofmann at gmx.de Sat Dec 26 15:14:43 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Dec 26 15:17:14 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091225174621.GA2726@local.gobigwest.com> References: <4B349E47.1050506@arcor.de> <20091225174621.GA2726@local.gobigwest.com> Message-ID: <20091226141443.GB1336@blob.baaderstrasse.com> On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > bb wrote: > > *On http://www.dillo.org/ I found the item News and a remark: > > > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > > malicious images. I am not shure what is meant with **malicious images? > > Are this so called Web bugs? If yes - how is the blocking done? > > Here's the advisory about the image size problem: > http://www.ocert.org/advisories/ocert-2009-008.html > > > I think there are some strategies possible to prevent a browser from a > > Web Bug attack: > > > > 1. Dont allow to load gifs or pngs from another URL as the actual page > > comes from. (I think to remember that firefox **originally **had such an > > option - not available in the actual version.) > > Here's the beginning of a thread and a patch experimenting with this: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html > (the "same host" option was found to be useless, but I'm still interested in > "same domain") > > > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > > smaller than say about 5x5. Do you think such a measure is feasible in > > Dillo and could that really stop Web Bugs? But I think that there should > > not be a problem to make Web Bugs larger than 1x1pixel as long as they > > are transparent - may be I am wrong, I am just a simple minded user, not > > a web professional. So such a limit might be useless? > > Here's a post and patch experimenting with rejecting images with a dimension > of 0: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > > > Are there other ideas? I am highly interested in that Web Bug problem. > > I'm glad to hear this, since user interest may encourage things to happen... > Absolutely. We really need to address this. Maybe we can do some more research again about what other browsers or plugins do about this. Cheers, Johannes From jcid at dillo.org Sat Dec 26 18:22:57 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Dec 26 18:23:33 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091225174621.GA2726@local.gobigwest.com> References: <4B349E47.1050506@arcor.de> <20091225174621.GA2726@local.gobigwest.com> Message-ID: <20091226172256.GE13066@dillo.org> On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > bb wrote: > > *On http://www.dillo.org/ I found the item News and a remark: > > > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > > malicious images. I am not shure what is meant with **malicious images? > > Are this so called Web bugs? If yes - how is the blocking done? > > Here's the advisory about the image size problem: > http://www.ocert.org/advisories/ocert-2009-008.html > > > I think there are some strategies possible to prevent a browser from a > > Web Bug attack: > > > > 1. Dont allow to load gifs or pngs from another URL as the actual page > > comes from. (I think to remember that firefox **originally **had such an > > option - not available in the actual version.) > > Here's the beginning of a thread and a patch experimenting with this: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html > (the "same host" option was found to be useless, but I'm still interested in > "same domain") > > > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > > smaller than say about 5x5. Do you think such a measure is feasible in > > Dillo and could that really stop Web Bugs? But I think that there should > > not be a problem to make Web Bugs larger than 1x1pixel as long as they > > are transparent - may be I am wrong, I am just a simple minded user, not > > a web professional. So such a limit might be useless? AFAIS your analysis is correct. There's no problem in increasing the web bug image size, specially on these broadband days... Personally I have hopes on restricting resource loading from other sites, but as corvid cites, it's non trivial and requires careful thought. As a highly interested user, you may gather some information on web bugs, techniques to avoid them etc. and post a summary of your findings here. That would help a lot. We have the knowledge on how to code dillo and restricted time to work on it. If you can help us everybody gains. > Here's a post and patch experimenting with rejecting images with a dimension > of 0: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > > > Are there other ideas? I am highly interested in that Web Bug problem. > > I'm glad to hear this, since user interest may encourage things to happen... I'm very interested in this topic, although haven't found free time these days... -- Cheers Jorge.- From corvid at lavabit.com Sat Dec 26 18:36:02 2009 From: corvid at lavabit.com (corvid) Date: Sat Dec 26 18:40:29 2009 Subject: [Dillo-dev] [oph-villedieu@orange.fr: dillo_2.1.1] In-Reply-To: <20091226141308.GA1336@blob.baaderstrasse.com> References: <20091220142815.GC4962@dillo.org> <20091220163303.GA869@blob.baaderstrasse.com> <20091220190841.GA2772@local.gobigwest.com> <20091226141308.GA1336@blob.baaderstrasse.com> Message-ID: <20091226173602.GA2730@local.gobigwest.com> Johannes wrote: > On Sun, Dec 20, 2009 at 07:08:42PM +0000, corvid wrote: > > The vertical-align code I have around doesn't do anything for table cells. > > > > Can you share what you have so far? The latest for non-table-cell was http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007099.html (which points to a patch) and the latest for table-cell was http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007105.html From corvid at lavabit.com Sat Dec 26 18:55:45 2009 From: corvid at lavabit.com (corvid) Date: Sat Dec 26 19:00:03 2009 Subject: [Dillo-dev] [un]highlighting and drawing lines Message-ID: <20091226175545.GB2730@local.gobigwest.com> Yesterday, I noticed that simply clicking on a random spot on a page caused a bunch of drawLine()s. This turned out to be an unnecessary unhighlight. The attached code is what I got from playing around to see how much highlighting and unhighlighting is unnecessary. (Highlighting part of a single word was still relatively inefficient, but there was a variable named brute_highllighting controlling it, so I figured it was for a good reason.) However, if I move the mouse around more rapidly, I get a lot fewer mouse motion notifications, which means to some degree that we're doing redraws when the motion is slow enough that we can more likely afford it. It might be different over a network; I don't know. Any opinions? -------------- next part -------------- diff -r 4941b1624ecc dw/textblock.cc --- a/dw/textblock.cc Fri Dec 25 07:50:47 2009 +0000 +++ b/dw/textblock.cc Sat Dec 26 17:42:49 2009 +0000 @@ -1528,7 +1528,7 @@ line = lines->getRef (lineIndex); if (lineYOffsetWidget (line) >= area->y + area->height) break; - +MSG("draw line %d!\n", lineIndex); drawLine (line, view, area); } } @@ -2034,11 +2034,18 @@ { Textblock *textblock = (Textblock*)getWidget(); int index1 = index, index2 = index; + bool draw = false; if (textblock->hlStart[layer].index > textblock->hlEnd[layer].index) { /* nothing is highlighted */ textblock->hlStart[layer].index = index; textblock->hlEnd[layer].index = index; + } else { + if (!(index == textblock->hlStart[layer].index && + start == textblock->hlStart[layer].nChar) && + !(index == textblock->hlEnd[layer].index && + end == textblock->hlEnd[layer].nChar)) + draw = true; } if (textblock->hlStart[layer].index >= index) { @@ -2053,7 +2060,10 @@ textblock->hlEnd[layer].nChar = end; } - textblock->queueDrawRange (index1, index2); + if (draw) + textblock->queueDrawRange (index1, index2); + else + MSG("highlight: don't bother to draw\n"); } void Textblock::TextblockIterator::unhighlight (int direction, @@ -2065,6 +2075,10 @@ if (textblock->hlStart[layer].index > textblock->hlEnd[layer].index) return; + bool highlighted = + textblock->hlStart[layer].index != textblock->hlEnd[layer].index || + textblock->hlStart[layer].nChar != textblock->hlEnd[layer].nChar; + if (direction == 0) { index1 = textblock->hlStart[layer].index; index2 = textblock->hlEnd[layer].index; @@ -2080,7 +2094,10 @@ textblock->hlEnd[layer].nChar = INT_MAX; } - textblock->queueDrawRange (index1, index2); + if (highlighted) + textblock->queueDrawRange (index1, index2); + else + MSG("unhighlight: don't bother to draw\n"); } void Textblock::queueDrawRange (int index1, int index2) From corvid at lavabit.com Sun Dec 27 06:20:26 2009 From: corvid at lavabit.com (corvid) Date: Sun Dec 27 06:24:42 2009 Subject: [Dillo-dev] are cookies supposed to be working nowadays? Message-ID: <20091227052026.GE2730@local.gobigwest.com> Tried enabling some cookies to test something, and I'm getting a lot of this sort of thing: [cookies dpi]: Enabling cookies as from cookiesrc... [cookies dpi]: (v.1) accepting connections... [cookies dpi]: Old netscape-style cookie... [cookies dpi]: Expires in 2000223 seconds, at Tue Jan 19 08:35:26 2010 ** ERROR **: [a_Dpi_send_blocking_cmd] Can't read message. It's a shiny new copy of the cookies dpi, and I haven't been seeing any problems with other dpis... From corvid at lavabit.com Sun Dec 27 06:27:08 2009 From: corvid at lavabit.com (corvid) Date: Sun Dec 27 06:31:22 2009 Subject: [Dillo-dev] table/cell width problem Message-ID: <20091227052708.GF2730@local.gobigwest.com> Also, I finally got around to looking into why the columns are strange on http://hg.dillo.org/dillo when I have remote style sheets enabled. Each row is a separate table, and the date and submitter fields have fixed widths specified in ems. That seems to work in general, but the problem is that the tables have width specified as 100%, which seems to make the table code forget about the column widths. From bblochl at arcor.de Sun Dec 27 13:35:37 2009 From: bblochl at arcor.de (bb) Date: Sun Dec 27 13:36:32 2009 Subject: [Dillo-dev] web bug save? Message-ID: <4B375499.8000206@arcor.de> Jorge Arellano Cid schrieb: > On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > >> bb wrote: >> >>> *On http://www.dillo.org/ I found the item News and a remark: >>> >>> 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix >>> for malicious images. I am not shure what is meant with **malicious >>> images? Are this so called Web bugs? If yes - how is the blocking >>> done? >>> >> Here's the advisory about the image size problem: >> http://www.ocert.org/advisories/ocert-2009-008.html >> >> >>> I think there are some strategies possible to prevent a browser from >>> a Web Bug attack: >>> >>> 1. Dont allow to load gifs or pngs from another URL as the actual >>> page comes from. (I think to remember that firefox **originally >>> **had such an option - not available in the actual version.) >>> >> Here's the beginning of a thread and a patch experimenting with this: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html >> >> (the "same host" option was found to be useless, but I'm still >> interested in >> "same domain") >> >> >>> 2. I think one might prepare HTML/CSS not to load such gifs or pngs >>> smaller than say about 5x5. Do you think such a measure is feasible >>> in Dillo and could that really stop Web Bugs? But I think that there >>> should not be a problem to make Web Bugs larger than 1x1pixel as >>> long as they are transparent - may be I am wrong, I am just a simple >>> minded user, not a web professional. So such a limit might be useless? >>> > > AFAIS your analysis is correct. There's no problem in increasing the > web bug image size, specially on these broadband days... > > Personally I have hopes on restricting resource loading from other > sites, > but as corvid cites, it's non trivial and requires careful thought. > > As a highly interested user, you may gather some information on > web bugs, techniques to avoid them etc. and post a summary of > your findings here. That would help a lot. We have the knowledge > on how to code dillo and restricted time to work on it. If you > can help us everybody gains. > > > >> Here's a post and patch experimenting with rejecting images with a >> dimension >> of 0: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html >> >> >> >>> Are there other ideas? I am highly interested in that Web Bug problem. >>> >> I'm glad to hear this, since user interest may encourage things to >> happen... >> > > I'm very interested in this topic, although haven't found free time > these days... > > > Thank you for your response. The begin of my web bug adventure was some curiousity as I gamed around with http://livehttpheaders.mozdev.org. I found some strange things, and momentarily felt like the guy in "The blue velvet", finding an cut ear and come into touch with an strange and eval world outside a wardrobe. The real eval things can only be done by javascript - so dillo is on the save side. It may be of general Interest: I found as a countermeasure the plugin ghostery for firefox. ghostery has a large list of known web bugs and can block it. Most of that software one may find is googles urchin.js, but ggogle has a new software ga.js. There was even launched "Turn Key Web Analytics In A Box" on Friday, December 18, 2009, see http://www.coradiant.com/news/091209_analyticsbox.htm. The List of web bugs you can find: http://code.google.com/p/ghostery/source/browse/trunk/firefox/ghostery-statusbar/ghostery/chrome/content/db.js?r=112 One may check out a read-only working copy anonymously over HTTP: http://code.google.com/p/ghostery/source/checkout As I just pointed out, a dillo user cannot be tracked by any javascript code. But even a simple Web Bug with a http-rquest to a tracking server can get a lot of Information about the request AFAIK that is client IP address, certainly the request date/time, the page requested, HTTP code, bytes served, user agent, and referer. So the tracker knows the URL of the page containing the bug and allows the server to determine which particular Web page the user has accessed. But more, the URL of the bug can be appended with an arbitrary string in various ways with extra information to identify the loading conditions of the bug. This extra information can be added while sending the page or by JavaScript scripts after the download (but as ponted out - no Javascript with Dillo). Web bugs can also be used in combination with HTTP cookies (if there are any) like any other object transferred using the HTTP protocol. One might say, use a proxy. But I found that nearly all of the free proxys are real trojans and sending such web bugs, most often in the advertising pictures. I asked a couple of the providers of free proxy services. The usual answer was, that they do not send web bugs, but the bad advertisers do. And usually they offered ma thei payed service that is free of advertising. And very often that web bug requests will NOT be send via the proxy!! You sent me an option switch to forbid dillo to request another domain as that of the actually used page: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html How can I patch Dillo in this way? It might be useful to have that as an option in Dillo, I am shure not every user is comfortable with that restriction. Seasons greetings BB From corvid at lavabit.com Sun Dec 27 22:38:30 2009 From: corvid at lavabit.com (corvid) Date: Sun Dec 27 22:42:45 2009 Subject: [Dillo-dev] secure cookies Message-ID: <20091227213830.GA2791@local.gobigwest.com> [cookies seem to be working for me after all, despite the error messages] Cookies can have an optional Secure attribute that instructs the user agent to send the cookie only over a secure connection. I can't find anything at all saying that they can only be set by secure connections. This seems strange to me. I'd think that the man in the middle could have fun by giving the user some other session key or whatever when, say, an image is being retrieved over plain http. From corvid at lavabit.com Mon Dec 28 02:21:41 2009 From: corvid at lavabit.com (corvid) Date: Mon Dec 28 02:25:56 2009 Subject: [Dillo-dev] patch: .domain cookies from/to domain Message-ID: <20091228012141.GC2791@local.gobigwest.com> Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */ The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it... Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch. PS I just committed a change today to fix up expiration/replacement of cookies, which was somewhat broken in general, and especially broken with respect to session cookies, so if anyone out there uses cookies much, please test! -------------- next part -------------- diff -r a749c1b10fbe dpi/cookies.c --- a/dpi/cookies.c Mon Dec 28 00:27:21 2009 +0000 +++ b/dpi/cookies.c Mon Dec 28 01:09:58 2009 +0000 @@ -57,6 +57,13 @@ #include "dpiutil.h" #include "../dpip/dpip.h" +/* + * Technically, cookies set with a domain of .example.com cannot be sent + * back to the host example.com, even if example.com set them in the first + * place. Do most user agents allow it? Yes. Does a large percentage of the + * web require it in order to work at all? Yes. + */ +#define SEND_DOTDOMAIN_COOKIES_TO_DOMAIN 1 /* * Debugging macros @@ -1114,6 +1121,13 @@ if (Cookies_validate_domain(cookie, url_host, url_path)) { if (action == COOKIE_ACCEPT_SESSION) cookie->session_only = TRUE; +#if SEND_DOTDOMAIN_COOKIES_TO_DOMAIN + if (cookie->domain && cookie->domain[0] == '.' && + !dStrcasecmp(cookie->domain + 1, url_host)) { + MSG("%s gave me a cookie for %s, and I am planning to give it" + " back if asked.\n", url_host, cookie->domain); + } +#endif Cookies_add_cookie(cookie); } else { MSG("Rejecting cookie for %s from host %s path %s\n", @@ -1202,6 +1216,27 @@ } } +#if SEND_DOTDOMAIN_COOKIES_TO_DOMAIN + domain_str = dStrconcat(".", url_host, NULL); + node = dList_find_sorted(cookies, domain_str, Cookie_node_by_domain_cmp); + domain_cookies = (node) ? node->dlist : NULL; + + for (i = 0; (cookie = dList_nth_data(domain_cookies, i)); ++i) { + /* Remove expired cookie. */ + if (cookie->expires_at < time(NULL)) { + Cookies_remove_cookie(cookie); + --i; continue; + } + /* Check if the cookie matches the requesting URL */ + if (Cookies_match(cookie, url_port, path, is_ssl)) { + MSG("I have a cookie whose domain is %s, and I am sending it to %s\n", + domain_str, url_host); + dList_append(matching_cookies, cookie); + } + } + dFree(domain_str); +#endif + /* Found the cookies, now make the string */ cookie_dstring = dStr_new(""); if (dList_length(matching_cookies) > 0) { From corvid at lavabit.com Mon Dec 28 03:01:46 2009 From: corvid at lavabit.com (corvid) Date: Mon Dec 28 03:06:00 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <4B375499.8000206@arcor.de> References: <4B375499.8000206@arcor.de> Message-ID: <20091228020146.GD2791@local.gobigwest.com> bb wrote: > You sent me an option switch to forbid dillo to request another domain > as that of the actually used page: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html > > How can I patch Dillo in this way? > It might be useful to have that as an option in Dillo, I am shure not > every user is comfortable with that restriction. I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again. http://www.dillo.org/test/filtering.2.patch from the main directory of the dillo source, "patch -p1 < filtering.2.patch" and then put filter_auto_requests=same_domain in ~/.dillorc From rmarathe at i-rode.com Mon Dec 28 12:19:42 2009 From: rmarathe at i-rode.com (Rajesh Marathe) Date: Mon Dec 28 12:20:46 2009 Subject: [Dillo-dev] Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS Message-ID: <1261999182.3724.26.camel@localhost.localdomain> Hi, We are working on IMX27 ADS board and have taken latest CVS based LTIB code. I have included 'Dillo2' and 'fltk' packages as my objective would be to run the browser dillo on the imx27 system. After the Linux boots up, I go to the console and try to run the browser. But, I get the following error: ---------------------------------------------------------------------- mx27# mx27# mx27# ./dillo paths: Cannot open file '//.dillo/dillorc' paths: Using /usr/etc/dillo/dillorc paths: Cannot open file '//.dillo/keysrc' paths: Using /usr/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Can't open display ":0.0" mx27# ---------------------------------------------------------------------- I did try to debug and found out that the function fltk::open_display returns the above display error. How do I set the display correctly so that the browser's opening page gets displayed on the LCD panel connected to IMX27 board ? regards, Rajesh Marathe. From jcid at dillo.org Mon Dec 28 16:34:01 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Dec 28 16:34:38 2009 Subject: [Dillo-dev] Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS In-Reply-To: <1261999182.3724.26.camel@localhost.localdomain> References: <1261999182.3724.26.camel@localhost.localdomain> Message-ID: <20091228153401.GJ13066@dillo.org> On Mon, Dec 28, 2009 at 04:49:42PM +0530, Rajesh Marathe wrote: > Hi, > > We are working on IMX27 ADS board and have taken latest CVS based LTIB > code. I have included 'Dillo2' and 'fltk' packages as my objective would > be to run the browser dillo on the imx27 system. > > After the Linux boots up, I go to the console and try to run the > browser. But, I get the following error: > > ---------------------------------------------------------------------- > mx27# > mx27# > mx27# ./dillo > paths: Cannot open file > '//.dillo/dillorc' > paths: > Using /usr/etc/dillo/dillorc > paths: Cannot open file > '//.dillo/keysrc' > paths: > Using /usr/etc/dillo/keysrc > dillo_dns_init: Here we go! > (threaded) > Disabling > cookies. > Can't open display > ":0.0" > mx27# > ---------------------------------------------------------------------- > > I did try to debug and found out that the function fltk::open_display > returns the above display error. > > How do I set the display correctly so that the browser's opening page > gets displayed on the LCD panel connected to IMX27 board ? Assuming you have the X server already running, run dillo as the same user that has the X server running (not root). Dillo needs the X server (or kdrive) to run. If you can run the fltk demo, dillo should run too. -- Cheers Jorge.- From jcid at dillo.org Tue Dec 29 13:33:18 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Dec 29 13:33:56 2009 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20091228012141.GC2791@local.gobigwest.com> References: <20091228012141.GC2791@local.gobigwest.com> Message-ID: <20091229123318.GL13066@dillo.org> On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > Like the patch says, > /* > * Technically, cookies set with a domain of .example.com cannot be sent > * back to the host example.com, even if example.com set them in the first > * place. Do most user agents allow it? Yes. Does a large percentage of the > * web require it in order to work at all? Yes. > */ > > The downside might be the scenario of sub.example.com setting a cookie > that example.com didn't expect to receive, but if everyone else does it... AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you. Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides. :) > Unless someone tells me not to within the next few days, I'll commit > something along the lines of this patch. I'd use a cookiesrc option set to NO by default instead of the #define. Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work. -- Cheers Jorge.- From jcid at dillo.org Tue Dec 29 13:39:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Dec 29 13:40:11 2009 Subject: [Dillo-dev] table/cell width problem In-Reply-To: <20091227052708.GF2730@local.gobigwest.com> References: <20091227052708.GF2730@local.gobigwest.com> Message-ID: <20091229123935.GM13066@dillo.org> On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > Also, I finally got around to looking into why the columns are strange > on http://hg.dillo.org/dillo when I have remote style sheets enabled. > > Each row is a separate table, and the date and submitter fields have > fixed widths specified in ems. That seems to work in general, but the > problem is that the tables have width specified as 100%, which seems > to make the table code forget about the column widths. IIRC a CSS-aware user agent can act as if old HTML presentation directives weren't there. Which could apply here. OTOH I don't know whether this would cause more harm. -- Cheers Jorge.- From corvid at lavabit.com Tue Dec 29 14:44:13 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 29 14:48:27 2009 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20091229123318.GL13066@dillo.org> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> Message-ID: <20091229134413.GA2768@local.gobigwest.com> Jorge wrote: > On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > > Like the patch says, > > /* > > * Technically, cookies set with a domain of .example.com cannot be sent > > * back to the host example.com, even if example.com set them in the first > > * place. Do most user agents allow it? Yes. Does a large percentage of the > > * web require it in order to work at all? Yes. > > */ > > > > The downside might be the scenario of sub.example.com setting a cookie > > that example.com didn't expect to receive, but if everyone else does it... > > AFAIS it would provide a very good way for tracking what pages > a user is reading to big hosting sites. e.g. blogspot.com I believe in that case, subdomains of blogspot.com would already be able to read/write a .blogspot.com cookie. > If you're using a unique IP, it may not add much, but if you're > behind a NAT or proxy or similar, this cookie singles out you. > > Considering most browsers allow these cookies, chances of > finding tracking code using this technique increases! Probably > only opaqued by the much bigger privacy hole javascript provides. > > :) > > > Unless someone tells me not to within the next few days, I'll commit > > something along the lines of this patch. > > I'd use a cookiesrc option set to NO by default instead of the > #define. > > Maybe allowing to set it by site (as the rest of cookiesrc) is > not a bad idea too. After all, people would enable it when they > need a specific site to work. Setting it by site sounds like a good idea. From corvid at lavabit.com Tue Dec 29 14:54:45 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 29 14:58:58 2009 Subject: [Dillo-dev] table/cell width problem In-Reply-To: <20091229123935.GM13066@dillo.org> References: <20091227052708.GF2730@local.gobigwest.com> <20091229123935.GM13066@dillo.org> Message-ID: <20091229135445.GB2768@local.gobigwest.com> Jorge wrote: > On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > > Also, I finally got around to looking into why the columns are strange > > on http://hg.dillo.org/dillo when I have remote style sheets enabled. > > > > Each row is a separate table, and the date and submitter fields have > > fixed widths specified in ems. That seems to work in general, but the > > problem is that the tables have width specified as 100%, which seems > > to make the table code forget about the column widths. > > IIRC a CSS-aware user agent can act as if old HTML presentation > directives weren't there. Which could apply here. > > OTOH I don't know whether this would cause more harm. Let's suppose that it had been specified as , then. From Johannes.Hofmann at gmx.de Tue Dec 29 16:00:37 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Dec 29 16:01:34 2009 Subject: [Dillo-dev] table/cell width problem In-Reply-To: <20091229135445.GB2768@local.gobigwest.com> References: <20091227052708.GF2730@local.gobigwest.com> <20091229123935.GM13066@dillo.org> <20091229135445.GB2768@local.gobigwest.com> Message-ID: <20091229150037.271110@gmx.net> -------- Original-Nachricht -------- > Datum: Tue, 29 Dec 2009 13:54:45 +0000 > Von: "corvid" > An: dillo-dev@dillo.org > Betreff: Re: [Dillo-dev] table/cell width problem > Jorge wrote: > > On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > > > Also, I finally got around to looking into why the columns are strange > > > on http://hg.dillo.org/dillo when I have remote style sheets enabled. > > > > > > Each row is a separate table, and the date and submitter fields have > > > fixed widths specified in ems. That seems to work in general, but the > > > problem is that the tables have width specified as 100%, which seems > > > to make the table code forget about the column widths. > > > > IIRC a CSS-aware user agent can act as if old HTML presentation > > directives weren't there. Which could apply here. > > > > OTOH I don't know whether this would cause more harm. > > Let's suppose that it had been specified as
        , > then. Enabling the code in dw/table.cc around line 697 seems to change this behaviour. Not sure if it already fixes it though. Cheers, Johannes -- Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 From corvid at lavabit.com Tue Dec 29 16:04:44 2009 From: corvid at lavabit.com (corvid) Date: Tue Dec 29 16:08:58 2009 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20091229134413.GA2768@local.gobigwest.com> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> <20091229134413.GA2768@local.gobigwest.com> Message-ID: <20091229150444.GC2768@local.gobigwest.com> I realized that there's an asymmetry in the dillo code with it accepting but not sending .example.com for a host example.com, when this asymmetry is not in the spec, AFAICT. Cookies are to be rejected if the "value for the request-host does not domain-match the Domain attribute", and "Host A's name domain-matches host B's if * both host names are IP addresses and their host name strings match exactly; or * both host names are FQDN strings and their host name strings match exactly; or * A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)" So it seems that we "shouldn't" accept them in the first place. From onepoint at starurchin.org Wed Dec 30 17:23:04 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Wed Dec 30 17:24:08 2009 Subject: [Dillo-dev] [bug]: CSS - attack of the mega-images Message-ID: <20091230162304.GB3516@omphalos.singularity> See http://blog.worldlabel.com/2009/inkscape-0-47-totally-solid-with-lots-of-new-tools.html Dillo inflates the images in the top toolbar to the full width of the window. The problem is this CSS (taken from the original stylesheet and simplified) a { display:block; float:left; } a img { width:100%; height:100%; } I guess Dillo is interpreting 100% relative to the wrong length? Firefox renders the images at normal size. (Minimal example attached.) Regards, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091230/eb167cc3/images.html -------------- next part -------------- a { display:block; float:left; } a img { width:100%; height:100%; } From corvid at lavabit.com Wed Dec 30 20:32:19 2009 From: corvid at lavabit.com (corvid) Date: Wed Dec 30 20:36:34 2009 Subject: [Dillo-dev] patch: handle cookie time overflow Message-ID: <20091230193219.GB2743@local.gobigwest.com> I saw a cookie with an expiration date of 2039, which is beyond the end of the universe for me, so it turned into 1903. So I made this, and it's working for me, but maybe you will know a nicer calculation, or a portability subtlety that I should handle. -------------- next part -------------- diff -r 6e889910a5fe dpi/cookies.c --- a/dpi/cookies.c Wed Dec 30 06:38:20 2009 +0000 +++ b/dpi/cookies.c Wed Dec 30 19:28:37 2009 +0000 @@ -64,6 +64,7 @@ #define _MSG(...) #define MSG(...) printf("[cookies dpi]: " __VA_ARGS__) +#define DILLO_TIME_MAX ((time_t) ((1UL << (sizeof(time_t) * 8 - 1)) - 1)) /* * a_List_add() @@ -583,6 +584,10 @@ (minutes * 60) + seconds); + /* handle overflow */ + if (year > 1970 && ret < 0) + ret = DILLO_TIME_MAX; + MSG("Expires in %ld seconds, at %s", (long)ret - time(NULL), ctime(&ret)); @@ -884,7 +889,14 @@ } else if (dStrcasecmp(attr, "Max-Age") == 0) { value = Cookies_parse_value(&str, FALSE, FALSE); if (value) { - cookie->expires_at = time(NULL) + strtol(value, NULL, 10); + time_t now = time(NULL); + long age = strtol(value, NULL, 10); + + cookie->expires_at = now + age; + if (age > 0 && cookie->expires_at < 0) { + /* handle overflow */ + cookie->expires_at = DILLO_TIME_MAX; + } expires = max_age = TRUE; dFree(value); } else { From jcid at dillo.org Thu Dec 31 04:27:36 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Dec 31 04:28:14 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091228020146.GD2791@local.gobigwest.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> Message-ID: <20091231032736.GQ13066@dillo.org> On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > bb wrote: > > You sent me an option switch to forbid dillo to request another domain > > as that of the actually used page: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html > > > > How can I patch Dillo in this way? > > It might be useful to have that as an option in Dillo, I am shure not > > every user is comfortable with that restriction. > > I just remembered that I had another version later in the thread, > and I just took a couple of minutes to get the patch to apply cleanly again. > > http://www.dillo.org/test/filtering.2.patch I like the patch! Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo. > > [Somebodey wrote:] > > I have also found same_host not to have any value. > > > > > Generally, is it really a problem if we load url's from other > > > hosts/domains? > > > > Sites have no right to redirect me to unrelated sites, and > > sites have no right to subject me to images from unrelated sites. > > I tend to agree. With your patch I noticed that many popular sites > contain 1x1 images from some statistics gathering companies. > However I think these images do not really leak additional information as > the sites could report your IP address behind the scenes as well. The IP sometimes is not one-to-one (proxies, NATs, etc). The cookie guarantees user tracking, when they're using the same IP or even the same machine! > I think the term "user agent" for a browser is very apt. > These companies ask dillo to serve as an accomplice > as they violate the user's right to privacy. Privacy is very complex to achieve. Very accurate knowledge in a broad range is necessary. Sometimes I wonder whether connecting through to a TOR network could help us a lot with it. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Dec 31 13:18:49 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Dec 31 13:21:25 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091231032736.GQ13066@dillo.org> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> Message-ID: <20091231121849.GA947@blob.baaderstrasse.com> On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > bb wrote: > > > You sent me an option switch to forbid dillo to request another domain > > > as that of the actually used page: > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.html > > > > > > How can I patch Dillo in this way? > > > It might be useful to have that as an option in Dillo, I am shure not > > > every user is comfortable with that restriction. > > > > I just remembered that I had another version later in the thread, > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > http://www.dillo.org/test/filtering.2.patch > > I like the patch! > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > give it broader testing from the Hg repo. My idea is to commit, > if you agree, and to polish from the repo. I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs. > > > > > [Somebodey wrote:] > > > I have also found same_host not to have any value. > > > > > > > Generally, is it really a problem if we load url's from other > > > > hosts/domains? > > > > > > Sites have no right to redirect me to unrelated sites, and > > > sites have no right to subject me to images from unrelated sites. > > > > I tend to agree. With your patch I noticed that many popular sites > > contain 1x1 images from some statistics gathering companies. > > However I think these images do not really leak additional information as > > the sites could report your IP address behind the scenes as well. > > The IP sometimes is not one-to-one (proxies, NATs, etc). The > cookie guarantees user tracking, when they're using the same IP > or even the same machine! > > > I think the term "user agent" for a browser is very apt. > > These companies ask dillo to serve as an accomplice > > as they violate the user's right to privacy. > > Privacy is very complex to achieve. Very accurate knowledge in > a broad range is necessary. Sometimes I wonder whether > connecting through to a TOR network could help us a lot with it. You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc. Cheers, Johannes From corvid at lavabit.com Thu Dec 31 19:25:06 2009 From: corvid at lavabit.com (corvid) Date: Thu Dec 31 19:29:18 2009 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091231121849.GA947@blob.baaderstrasse.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> Message-ID: <20091231182506.GA2844@local.gobigwest.com> Johannes wrote: > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > Sometimes I wonder whether > > connecting through to a TOR network could help us a lot with it. > > You can already use dillo with privoxy and tor. We could perhaps > make it more convenient to configure such a setup. > We also would need to make sure that really all requests go through > the proxy, e.g. I'm not sure, whether wget called from dowload.dpi > uses the proxy from dillorc. I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.