April 2009 - Dillo-dev - lists.mailman3.com

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

April 7, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

On Sun, Apr 05, 2009 at 04:49:16PM +0000, corvid wrote: > Johannes wrote: > > But first I'd like to fix the cyclic dependency. Maybe we can move > > a_Html_load_stylesheet() from html.cc to some other place? > > Perhaps some code could move to the bw. Yes, but maybe it isn't as bad as I initially thought anyway... Attached is an improved version of the patch that avoids looping on recursive @import and resolves relative urls properly. Cheers, Johannes

April 5, 2009

CSS @import

by corvid＠lavabit.com

Johannes wrote: > But first I'd like to fix the cyclic dependency. Maybe we can move > a_Html_load_stylesheet() from html.cc to some other place? Perhaps some code could move to the bw.

April 5, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

On Sat, Apr 04, 2009 at 03:19:06PM +0000, corvid wrote: > Johannes wrote: > > for quite some while I've been trying to add support for the @import > > directive in CSS. The problem is that it creates a cyclic dependency > > between CssParser and DilloHtml: > > CssParser now calls a_Html_load_stylesheet(). > > > > This is extremely ugly and needs to be decoupled somehow. > > > > Anyway, attached is what I currently have - cleanup ideas welcome. > > > > Note, that we also need to use the URL of the current stylesheet to > > resolve relative URLs in @import. This is not implemented yet. > > Good! > > - Is strcat safe here? Argh, no of course not. And I was wondering why dillo was crashing all the time :-) > - strcasecmp -> dStrcasecmp Yes. > - needs a check for prefs.load_stylesheets That should probabely go into a_Html_load_stylesheet(). > - Can we get into loops if an imported stylesheet imports itself > (directly or indirectly) Yes, we need to detect such loops. Should be not too hard. But first I'd like to fix the cyclic dependency. Maybe we can move a_Html_load_stylesheet() from html.cc to some other place? Thanks for having a look! Johannes

April 4, 2009

CSS @import

by corvid＠lavabit.com

Johannes wrote: > for quite some while I've been trying to add support for the @import > directive in CSS. The problem is that it creates a cyclic dependency > between CssParser and DilloHtml: > CssParser now calls a_Html_load_stylesheet(). > > This is extremely ugly and needs to be decoupled somehow. > > Anyway, attached is what I currently have - cleanup ideas welcome. > > Note, that we also need to use the URL of the current stylesheet to > resolve relative URLs in @import. This is not implemented yet. Good! - Is strcat safe here? - strcasecmp -> dStrcasecmp - needs a check for prefs.load_stylesheets - Can we get into loops if an imported stylesheet imports itself (directly or indirectly)

April 4, 2009

CSS @import

by Johannes.Hofmann＠gmx.de

Hi, for quite some while I've been trying to add support for the @import directive in CSS. The problem is that it creates a cyclic dependency between CssParser and DilloHtml: CssParser now calls a_Html_load_stylesheet(). This is extremely ugly and needs to be decoupled somehow. Anyway, attached is what I currently have - cleanup ideas welcome. Note, that we also need to use the URL of the current stylesheet to resolve relative URLs in @import. This is not implemented yet. Cheers, Johannes

April 4, 2009

bugg 903, correcting problems

by corvid＠lavabit.com

Johannes wrote: > On Fri, Apr 03, 2009 at 09:41:00PM +0200, Fredrik Gustafsson wrote: > > Hi, > > after submitting bug 903 I started to work an a solution. (bugg desc. > > added below for your convinience). > > 903 > > Impact: feature fault > > At: run time > > Type: misbehaviour > > Comments: <textarea> doesn't wrap lines (should be an option i dillorc) > > HTReproduce: visit a <textarea> and start typing a really long line > > without any linebreaks > > WorkedBy: nobody > > Submitter: iveqy*iveqy*com > > > > My solution was to add > > text->wrap_mode(true,0); > > on line 678 in dw/fltkui.cc > > > > This worked fine. The line is now wrapped. But after a post, dillo will > > crash (after sending the post, a post sent will be recieved by the > > webbserver before dillo crashes). I can't find where and why dillo > > crash. Does anyone have an id?? > > On deletion we remove the buffer from the fltk:TextEditor class > which seems to cause the crash if wrap_mode is switched on. > Attached patch simply resets wrap_mode on deletion. > It seems to work fine here. Please give it a try. > > Not sure if we want a dillorc option or if we switch this on > generally? What does the spec say and what do other browsers? The spec lets the user agent do as it wishes: cols = number [CN] This attribute specifies the visible width in average character widths. Users should be able to enter longer lines than this, so user agents should provide some means to scroll through the contents of the control when the contents extend beyond the visible area. User agents may wrap visible text lines to keep long lines visible without the need for scrolling.

April 4, 2009

bugg 903, correcting problems

by Johannes.Hofmann＠gmx.de

On Fri, Apr 03, 2009 at 09:41:00PM +0200, Fredrik Gustafsson wrote: > Hi, > after submitting bug 903 I started to work an a solution. (bugg desc. > added below for your convinience). > 903 > Impact: feature fault > At: run time > Type: misbehaviour > Comments: <textarea> doesn't wrap lines (should be an option i dillorc) > HTReproduce: visit a <textarea> and start typing a really long line > without any linebreaks > WorkedBy: nobody > Submitter: iveqy*iveqy*com > > My solution was to add > text->wrap_mode(true,0); > on line 678 in dw/fltkui.cc > > This worked fine. The line is now wrapped. But after a post, dillo will > crash (after sending the post, a post sent will be recieved by the > webbserver before dillo crashes). I can't find where and why dillo > crash. Does anyone have an id?? On deletion we remove the buffer from the fltk:TextEditor class which seems to cause the crash if wrap_mode is switched on. Attached patch simply resets wrap_mode on deletion. It seems to work fine here. Please give it a try. Not sure if we want a dillorc option or if we switch this on generally? What does the spec say and what do other browsers? Cheers and thanks for Your contribution, Johannes > -- > Med v?nliga h?lsningar > Fredrik Gustafsson > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 3, 2009

bugg 903, correcting problems

by iveqy＠iveqy.com

Hi, after submitting bug 903 I started to work an a solution. (bugg desc. added below for your convinience). 903 Impact: feature fault At: run time Type: misbehaviour Comments: <textarea> doesn't wrap lines (should be an option i dillorc) HTReproduce: visit a <textarea> and start typing a really long line without any linebreaks WorkedBy: nobody Submitter: iveqy*iveqy*com My solution was to add text->wrap_mode(true,0); on line 678 in dw/fltkui.cc This worked fine. The line is now wrapped. But after a post, dillo will crash (after sending the post, a post sent will be recieved by the webbserver before dillo crashes). I can't find where and why dillo crash. Does anyone have an id?? -- Med v?nliga h?lsningar Fredrik Gustafsson

April 3, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

On Wed, Apr 01, 2009 at 11:53:29PM +0200, Michal Nowak wrote: > On Wed, Apr 01, 2009 at 10:16:41PM +0200, Hofmann Johannes wrote: > > On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > > > dpi.c: In function ?a_Dpi_bye_dpid?: > > > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > > > > > Can you please check whether attached patches fix the warnings? > > > > Michal, do the patches fix the warnings for you? > > > > Cheers, > > Johannes > > Yes, the mentioned warnings are fixed now, thanks Johannes! Ok, also committed the second part now. Cheers, Johannes

April 2, 2009