- Dillo-dev - lists.mailman3.com

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Hi I have a cnm minibook which is part of a little Linux laptop family of mini laptops that use low powered Mipsel processors running Lnux. An unofficial site is here: http://linuxlaptopforum.ark2webdesign.co.uk/index.php One of the users has come up with a Linux distro called 3MX which uses IceWeseal but has also Dillo. The reason for this is because IceWeasel is a bit slow due to the low spec processor. Dillo runs far better than IceWeasel and would be an ideal replacement if it had the functionality of Javascript. Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. It is theoritcally possible as I use the noscript plugin on Firefox on my home PC which blocks javascript from certain 3rd party sites from running. I was wondering if anybody had any thoughts if the above is achievable and if so what would be the best Javascript engine to use with Dillo to achive this? Thanks in advance alsaf. _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/

April 7, 2009

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