- Dillo-dev - lists.mailman3.com

Valgrind errors
by onepoint＠starurchin.org Jan. 24, 2009

Jan. 24, 2009

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

4 8

Valgrind error: possible link to Imgbuf crash?
by onepoint＠starurchin.org Jan. 23, 2009

Jan. 23, 2009

Here's another valgrind error that I think might be related to the crashes I have been seeing. The gdb stack trace showed that a_Imgbuf_new() was calling a layout method with an invalid address for the layout object. The valgrind error shows a_Imgbuf_new() reading invalid memory when it calls Widget::getLayout(). It looks to me as though a_Imgbuf_new() is being passed an Image that has already been freed. Regards, Jeremy Henty

1 0

[patch]: control lout's MSG from the preferences
by onepoint＠starurchin.org Jan. 23, 2009

Jan. 23, 2009

This patch makes the dillorc show_msg preference control lout's MSG macros as well as dillo's. Please comment. Regards, Jeremy Henty

2 1

[patch]: fix DBG build of table.cc
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

If you uncomment the #define of DBG in table.cc it won't compile. It looks as though most of the DBG code was fixed not to use the non-existent "result" variable, but one instance was left unchanged. Patch attached. Regards, Jeremy Henty

2 1

Crashes in dw::core::Layout::createImgbuf()
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

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

2 2

[bug]: hang in Css_parse_delaration()
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

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

2 2

[bug]: hang in Css_parse_declaration()
by onepoint＠starurchin.org Jan. 19, 2009

Jan. 19, 2009

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

2 2

Re: A couple of patches
by jcid＠dillo.org Jan. 19, 2009

Jan. 19, 2009

Hi Johannes, On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here go couple of patches. Please test and apply. > > Thanks, applied. > > > > > Note: the image background support is partial. It works well > > when coming back to a page. AFAIS the right solution is to decode > > transparent images to RGBA and let FLTK handle it. > > Yes, I think that would be the correct way to do it. > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > What do you think? > > Yes, it feels pretty stable and now that there is an option to > disable remote stylesheet loading, I think we can consider making > css-prototype the main branch of dillo. > However I'd like to have some issues fixed: > > * should load_stylesheets=NO only disable remote style-sheet loading > (as it does now), or should it disable all remote style processing > (e.g. style given in <style type="text/css"> </style>)? We can add a "parse_embedded_css" option. That way there's no ambiguity. My next task is to add the toolbox button mentioned in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html It may hold CSS options akin to: [Tb Icon] .-------------------. .---------. | Change charset >|--------------------------------->| UTF-8 | | CSS >|-->.---------------. | Cp 1250 | | Free memory >|-. |* remote CSS | | ... | '-------------------' | |* embedded CSS | '---------' | |* use my CSS | | |* no CSS at all| | '---------------' | .------------------. '->| Images | | Local Files | | Everything unused | '-------------------' Note: '*' means a toggle option Note2: "use my CSS" replaces "Force my colors" We can polish from there. > * form.cc is not yet converted to the new style handling and widget > coloring is broken. OK. > * css-prototype displays e.g. table borders in the current color not > in shaded background-color as dillo-main does. > This is because CSS 2.1 states: > "If an element's border color is not specified with a border > property, user agents must use the value of the element's 'color' > property as the computed value for the border color. " > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > firefox however also uses a shaded background color. > I'd don't know how to deal with that at the moment. I'd say leave it as the standard says until it becomes an issue. In that case we can follow FF or decide better. > Then there is of course tons of issues with CSS, but we can improve > on that gradually. That's the idea. BTW, I have a question. How can a minimal font size be specified? Currently I have: body {font-size: 18px !important} in style.css, but often pages come with smaller fonts. e.g. http://www.linux.org.uk/Portaloo.cs For me is important because I have a problems reading tiny fonts, and my working laptop has a high screen resolution. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

3 4

CSS branch merged!
by furaisanjin＠gmail.com Jan. 18, 2009

Jan. 18, 2009

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

1 0

CSS branch merged!
by Johannes.Hofmann＠gmx.de Jan. 17, 2009

Jan. 17, 2009

On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: > Sorry, I mixed up 2 things. I guess default font is something I > specified in ~/.dillo/style.css if dillo can't find any fonts > specified in style. It seems that there is some timing issue when the > page is loaded. The first time somehow the page is unreadable but if I > goto to bookmark page and come back to the page, the page is readable. Argh, timing issues are bad. Can you please point me to a page where this happens? > > Another issue is that if style sheet specified none Japanese font and > the font exists on my machine, then of course the page isn't readable > at all. This isn't dillo problem but style sheet problem. Do you have an example? How does firefox handle these pages? Regards, Johannes

1 0

CSS branch merged!
by Johannes.Hofmann＠gmx.de Jan. 17, 2009

Jan. 17, 2009

On Sat, Jan 17, 2009 at 11:04:12PM +0900, furaisanjin wrote: > 2009/1/17 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > In this case dillo should try the three fonts given. At least > > "monospace" should exist and be mapped to some default monospace > > font. > > I don't have such font which name is "monospace" on my machine. > fc-list command doesn't show such name. What is the default mono space > font in the current CSS implementation? None. That part is not yet implemented. > > Because some pages written in Japanese contain fonts that I don't have > at all, I can't read such pages. See my answer to Jorge's mail on how to force a fixed font-family. Regards, Johannes

1 0

[patch]: add copyright and license declarations to dpid sources
by onepoint＠starurchin.org Jan. 17, 2009

Jan. 17, 2009

I checked all the *.{c,cc} files and found that a couple of the dpid/ files were missing copyrights too. Patch attached. Regards, Jeremy Henty

2 1

[patch]: add copyright and license declaration to cssparser.cc
by onepoint＠starurchin.org Jan. 17, 2009

Jan. 17, 2009

There's no copyright or license in cssparser.cc . Patch attached. Regards, Jeremy Henty

2 2

Re: patch: some consts
by Johannes.Hofmann＠gmx.de Jan. 17, 2009

Jan. 17, 2009

On Sat, Jan 17, 2009 at 01:09:12AM +0000, corvid wrote: > (and an unrelated static) > It was time for my occasional running of nm... > committed! Thanks, Johannes

1 0

focus after closing tab
by Johannes.Hofmann＠gmx.de Jan. 15, 2009

Jan. 15, 2009

Hi, sometimes when closing a tab it feels that dillo focuses the "wrong" tab. Therefore I made a patch that puts the focus back to the tab from which a tab was opened. That way I always get back to the "base page" when closing a tab. Howerver I'm not sure that this is always right, e.g. when opening multiple tabs from one base page, one might want to read one after the other without going back to the base page. What do you think, which page should be focused when closing a tab: * the tab from which the closed one was opened? * the tab to the left of the closed one? * the most recently opened one? Cheers, Johannes

3 4

Re: focus after closing tab
by sandshrew＠gmail.com Jan. 15, 2009

Jan. 15, 2009

I would vote for "the most recently opened one" too. -- Brain: an apparatus with which we think we think. - A. Bierce

1 0

CSS speed
by Johannes.Hofmann＠gmx.de Jan. 15, 2009

Jan. 15, 2009

Hi, pages with complex CSS feel a bit slow with the current css-prototype and gprof shows a huge number of CssSelector::match() calls. Attached is a patch that tries to improve that by: * putting CssSelectors into hashtables so that we only need to match against a small subset of CssSelectors. * avoiding repeated matches of CssSimpleSelectors against the same part of the doctree. Please test and report if there is a real world speedup. Cheers, Johannes

2 4

Dillo 2 in Tiny Core Linux
by xentalion＠gmail.com Jan. 15, 2009

Jan. 15, 2009

Hello, Just wanted to let you that I've built a package of Dillo 2 for Tiny Core Linux. http://www.tinycorelinux.com/ It is now in the repositories for Tiny Core. :D Dillo 2 doesn't use any OpenGL does it? I compiled FLTK 2 without OpenGL support, and I didn't know if that would be a problem. Thanks, Colin

2 1

patch: focus URL opened from command line
by corvid＠lavabit.com Jan. 14, 2009

Jan. 14, 2009

I see there's a new entry in the bug tracker reporting that after opening multiple URLs from the command line, shift-right and shift-left do not work immediately. What do you think of something like the attached patch? The downside is that it wastes cycles when you click on a link, but I was reluctant to let dillo.cc know about this UI stuff.

1 0

CSS freeze
by jcid＠dillo.org Jan. 13, 2009

Jan. 13, 2009

Hi, Current and former CSS protos freeze on this page: http://www.instantfundas.com/2007/12/5-opera-tricks-you-did-not-know-about.… -- Cheers Jorge.-

2 3

IMG ratio
by jcid＠dillo.org Jan. 11, 2009

Jan. 11, 2009

Hi Johannes, Now that I have the image process mostly in my head, I'd like to hook correct image ratio scaling when only one of width/height is given. I see scaling done with the styleengine in a_Html_add_new_image but 'props' goes away when popping the tag. How do I handle this? Do I have to preserve props in the stack until I have the final data, or is there another way? Please explain. -- Cheers Jorge.-

3 18

Blimey, when was this fixed? Selections are fast!
by onepoint＠starurchin.org Jan. 11, 2009

Jan. 11, 2009

I used to complain that drawing the text selection was desperately slow when I dragged the mouse across the contents of a table with two columns and very many rows. Today I suddenly realised that this hadn't bothered me for a while, so I checked the problem page and indeed the selection now draws itself as fast I can drag the mouse. Big thanks to whoever fixed this performance bug! Regards, Jeremy Henty

1 0

RE: Dillo in Debian
by devidfil＠gmail.com Jan. 9, 2009

Jan. 9, 2009

Hi, I'm the current dillo Debian maintainer. I know, dillo 2.0 isn't in Debian right now but it isn't caused by me, fltk2 package is missing in Debian so I can't upload the 2.0 version right now. However I've done the fltk2 package for Debian and if all is ok it will uploaded (and accepted) in Debian as soon as possible (but it won't be in Lenny). If you will switch dillo to fltk1.3 then the problem will be the same because actually Debian doesn't have the 1.3 version of fltk (only 1.1) so I will need to work on a new package for fltk1.3 and this will require time (there is no a good documentation about how to work on a static lib package). So please continue to use fltk2. I'm sorry for the delay. Devid Antonio Filoni

1 0

one more crash
by Johannes.Hofmann＠gmx.de Jan. 9, 2009

Jan. 9, 2009

Sorry, but I'm seeing one more crash with current css-prototype. I think it has to do with abdae95b1c9e. I get it often - but not always e.g. on www.spiegel.de. Somehow layout is not set properly in the Image widget. Below is the stack. Cheers, Johannes Program terminated with signal 11, Segmentation fault. #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 241 return platform->createImgbuf (type, width, height); (gdb) bt #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, type=DILLO_IMG_TYPE_RGB) at dicache.c:268 #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 #5 0x0805de7a in Cache_process_queue (entry=0x2952d080) at cache.c:1134 #6 0x0805d624 in a_Cache_process_dbuf (Op=0, buf=0x2955d000 "Z121\034\002\n", buf_size=7930, Url=0x2952d200) at cache.c:856 #7 0x08060af9 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6b40, Data1=0x286bb5b0, Data2=0x80fb16c) at capi.c:596 #8 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6740, Data1=0x286bb5b0, Data2=0x80fb16c) at chain.c:112 #9 0x080794d2 in Dpi_parse_token (conn=0x2952d240) at dpi.c:219 #10 0x080797b2 in Dpi_process_dbuf (Op=0, Data1=0x286bbca0, conn=0x2952d240) at dpi.c:278 #11 0x0807a545 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6740, Data1=0x286bbca0, Data2=0x0) at dpi.c:668 #12 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6fa0, Data1=0x286bbca0, Data2=0x0) at chain.c:112 #13 0x0807b197 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6fa0, Data1=0x294d6560, Data2=0x0) at IO.c:414 #14 0x0807abdd in IO_read (io=0x294d6560) at IO.c:201 #15 0x0807acf7 in IO_callback (io=0x294d6560) at IO.c:266 #16 0x0807ad80 in IO_fd_read_cb (fd=64, data=0x8e) at IO.c:287 #17 0x080c8c99 in fltk::wait () #18 0x080c8e49 in fltk::run () #19 0x0804f19c in main (argc=1, argv=Cannot access memory at address 0x3c ) at dillo.cc:334 (gdb)

2 5

Dillo in Debian
by jcid＠dillo.org Jan. 8, 2009

Jan. 8, 2009

Hi Wookey, A post in dillo-dev made me aware of this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 Thanks for your comment ;-) Some technical facts (all available from dillo.org) * dillo-0.8.x is unmaintained * dillo-2.x is the official stable branch * dillo-2.x uses FLTK2 not GTK2 as stated in the thread IMHO it'd be good to have dillo-0.8.x in Lenny, at least until dillo-2.x makes its way into Debian. We've been working on this branch for more than a year and it's way better than the former (details in the website). I'm aware of the problem distros have with including statically linked packages, and it looks like dillo-2.x will be left out of them until this issue is solved. Unfortunately FLTK-2.0 is stalled and an official release of it is nowhere near in the future. OTOH, an active set of developers is pushing FLTK-1.3.x very fast. This branch provides more or less the same FLTK-2.0 does. It's being actively developed, is less buggy and more stable, and will most probably be released soon (I'm yet to ask the team about dates). At some point in time we'll be migrating to FLTK-1.3.x (it has almost the same API), and hopefully then it'll be easier to include dillo in Debian. If you make progress with the certificate patch, please let us know. We're fully devoted to CSS now, and have no SSL expert in the team :( -- On a personal level, I'd love to have Dillo used in Debian as a help browser. This is, since a long time ago I've noticed applications come with almost no help (F1 button in the old days) and help drives you to an "About" window. But OTOH they have very good HTML docs (usually in usr/share/), that could provide for accurate context-sensitive help pages. The problem is they don't hook a web browser to the help button because a bloated app. that takes a long time to start, only to crawl the computer afterwards, is the last thing a developer hopes as her end user experience. There's the possibility of having a simple API to remote control the browser so the same instance is used. Dillo is fast, lean, and low on library dependencies. Any doubts, just don't hesitate to ask. -- Cheers Jorge.-

2 1

dillo about to be dropped from debian
by r00t＠constancy.org Jan. 8, 2009

Jan. 8, 2009

FYI: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 it seems that dillo is about to be dropped from debian, because * ssl lacks proper certificate verification * it still uses gtk1.2 (personally, the first never bothered me, and i consider the second a _feature_) Greetings, Thorben Thuermer

1 0

Strange valgrind complain
by jcid＠dillo.org Jan. 7, 2009

Jan. 7, 2009

Hi there, With Johannes, we're trying to find out why valgrind complains on the newest CSS branch with a certain URL: $ valgrind --tool=memcheck --leak-check=yes \ ./dillo http://selenic.com/pipermail/mercurial/ &>out $ less out There're several "Invalid read of size 1". It doesn't complain with a local file, nor after repush. It seems the timing is important, and maybe the decoder... Please help us, it's important to stabilize this branch before merging into main. -- BTW, after we merge CSS into the main branch, it seems like floating objects will be the highest priority. Dillo rendering would improve a lot by using both! -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

3 11

default search engine
by corvid＠lavabit.com Jan. 7, 2009

Jan. 7, 2009

I was thinking about the news that was going around last month about yahoo making its data retention period shorter (with exceptions to let them get away with whatever they want, but that's par for the course). e.g. http://www.theregister.co.uk/2008/12/17/yahoo_anonymization_explained/ It seems like a good idea to set the search_url default to whoever is the...let's say "least bad" in terms of privacy at a given time.

1 0

Re: Added a right-click menu to the form submit button (allows to show hiddens)
by Johannes.Hofmann＠gmx.de Jan. 6, 2009

Jan. 6, 2009

this is cool! Johannes

1 0

Re: We have competition!
by sandshrew＠gmail.com Jan. 4, 2009

Jan. 4, 2009

> http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! I was testing hv3 for quite awhile when the project was still active and would like to point out some stupid mistakes made in the article: 1) it's NOT h3v or h3w - it's hv3 (Html Viewer 3)! 2) it's written primarily in TCL, not in C; 3) both dillo and hv3 do support SSL (hv3 requires TLS for that and TLS is incorporated in the startkits, provided in the official website) 4) in both articles it is said "developerS". Actually 99% of the code (some parts were borrowed from another TCL browser called "BrowseX"(http://wiki.tcl.tk/2136)) was written by one genius named Daniel Kennedy. 5) Dillo actually launches a lot faster than hv3, but hv3 renders pages really fast too. And few comments from my side... Hv3 has a lot better bookmark manager when compared to dillo. Furthermore, in addition to bookmark, setting and cookie saving it can save history and has autocompletion. It has highly advanced css support - it even passes ACID2 test (something what microsoft with their internet exploiter was trying achieve for quite awhile...). As it's primarily written in TCL, it's platform independent, doesn't require any external dependencies, can run straight from USB flash memory (it can also save its db there too). Unlike dillo, hv3 also supports frames. Finally, even it's considered to be alpha state software, at least when javascript support is disabled, it is pretty stable. If you'd like to know something more about hv3, I think, you should still be able to contact Daniel - danielk1977 AT gmail DOT com. BTW, I don't know the current status of SEE project, I just know that the last time I checked (half a year ago or so) it had really many problems. SEE: http://www.adaptive-enterprises.com.au/~d/software/see/ -- Brain: an apparatus with which we think we think. - A. Bierce

1 0

Re: We have competition!
by sandshrew＠gmail.com Jan. 4, 2009

Jan. 4, 2009

Sorry to disappoint you, but hv3 is officially unmaintained already for almost a year and SEE has LOTS of problems... -- Brain: an apparatus with which we think we think. - A. Bierce

3 3

open new tab
by Hole.destructor＠gmx.de Jan. 3, 2009

Jan. 3, 2009

Hi Dillo team, I have a simple question concerning the new tabbed browsing feature in Dillo2: The only way to open a link in a new tab seems to be a click with the middle mouse button. Since there are some people, who don't have a mouse (for example on Laptops, MacBooks etc.) and therefore must find this middle-click very unhandy, I was wondering whether it is possible to open a link within a new tab by using another method, for example the common <CTRL>-<left mous button> combination? If this is currently not possible, could you introduce it in a future version of dillo? (I think the inofficial Dillo version, which is currently shipped with Debian/Ubuntu knows this alternative combination.) Many thanks in advance for your help, Alexander

1 0

[patch]: use the dlib dStr* functions everywhere
by onepoint＠starurchin.org Jan. 2, 2009

Jan. 2, 2009

This is a small consistency cleanup. Most of the Dillo source uses dlib's dStr* functions for string operations. This patch fixes the few places that do not. Jeremy Henty

2 1

Best wishes for 2009!
by jcid＠dillo.org Jan. 2, 2009

Jan. 2, 2009

Hi there, Please receive my best wishes for this new year 2009! We've come a long way since dillo restarted, and progress in several fronts has improved the browser a lot. Thanks to you all for the good work!!! > Amyway, it looks like 2009 will be an exciting year for Dillo. In the hope of it coming true, I just sent Johannes an image handling patch series for CSS to work properly with stylesheet loading. Just wait for his signal after he commits to download and enjoy the new code. Note: I'm still working on it, but it's quite usable "as is". -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 1

[patch]: fix dialog callback
by onepoint＠starurchin.org Jan. 2, 2009

Jan. 2, 2009

Dialog_user_password_cb() should not use VOIDP2INT, because the (void *) argument was originally an (int *), not an int or long. This bug makes the dialog always call its callback even when the user presses the Cancel button. As a result it is futile to cancel the Basic Authentication dialog: the page reloads and the dialog pops up again. Patch attached. Jeremy Henty

2 1

[patch]: refactor Auth_parse_auth_basic()
by onepoint＠starurchin.org Jan. 2, 2009

Jan. 2, 2009

This patch implements a previous suggestion to break up Auth_parse_auth_basic() into smaller functions and eliminate gotos. Please comment. Jeremy Henty

2 1

We have competition!
by onepoint＠starurchin.org Jan. 2, 2009

Jan. 2, 2009

Linux Weekly News covers Hv3, a Tcl-based lightweight browser. http://lwn.net/Articles/311823/ They refer to Dillo as "perhaps the best known minimalist browser"! It's worth reading the comments to see what people want to see in a lightweight browser and what they don't miss if it's not there. They certainly appreciate the speed. Hv3 claims to support CSS, but I'm not seeing it: Slashdot and the BBC look almost exactly the same as they do in Dillo. Mind you, I'm running it from the latest CVS and getting plagued with Tcl errors too, so maybe it's just temporarily broken. Hv3 is also supposed to support Javascript through SEE, but the SEE site is not responding right now so I can't try it out (and comments suggest that getting it into a source build is broken). Maybe SEE would be a way to support JavaScript in Dillo? Amyway, it looks like 2009 will be an exciting year for Dillo. Jeremy

4 4

patch: Accept-Language header
by corvid＠lavabit.com Dec. 29, 2008

Dec. 29, 2008

For people who don't want to always get language-of-place-where-I'm-physically-located.

2 1

Re: CSS loading part#2
by jcid＠dillo.org Dec. 29, 2008

Dec. 29, 2008

Hi, On Sun, Dec 21, 2008 at 04:48:42PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > Here I'm attaching the second part of the CSS loading patch. > This one is coherent and works better :-). Please commit after > some testing. > > Note: images are still truncated sometimes, but AFAIS this is a > problem in the dicache, not in CSS loading. I hope to fix this > soon. Well, in fact, images were always truncated when the repush caught them still rendering. I've been working on this for days and yes, it's a problem in the dicache. Unfortunately the cache/dicache/image-decode/image code is so entangled that it needs a rewrite. Quite surprising it works stable "as is". The idea is to try to devise a single path of execution that allows handling each image request (repeated or not) as a simple cache client. It's more complex than it sounds! The good news is that after you merge the latest cleanups in dillo main, the attached patch will more or less make it work as desired. There'll be some added unstability, and the underlying mess ;), but it should be a good basis to keep improving CSS while I work in the image process stream. -- Cheers Jorge.- _... o_.-"` `\ .--. _ `'-._.-'""-; _ .' \`_\_ {_.-a"a-} _ / \ _/ .-' '. {c-._o_.){\|` | (@`-._ / \{ ^ } \\ _/ `~\ '-._ /'. } \} .-. |>:< '-.__/ '._,} \_/ / ()) | >:< `'---. ____'-.|(`"` \ >:< \\_\\_\ | ; \ \\-{}-\/ \ \ '._\\' /) '. /( `-._ _____ _ _____ __.'\ \ / \ / \ / \ \ \ jgs _.'/^\'._.'/^\'._.'/^\'.__) \ ,==' `---` '---' '---' ) `"""""""""""""""""""""""""""""""`

3 3

remove generate_submit pref?
by corvid＠lavabit.com Dec. 29, 2008

Dec. 29, 2008

Any objections to getting rid of it? dillorc: # Some forms lack a submit button, and dillo can generate a custom one # internally. Unfortunately there's no guarantee for it to work. :( # (my experience is that forms that lack a submit rely on Javascript) #generate_submit=NO

3 2

experimental patch: image error status as alt text
by corvid＠lavabit.com Dec. 28, 2008

Dec. 28, 2008

You know how for image redirections and 404s, nothing at all happens? User's mind: "I didn't get the image. Dillo must be broken." (or the address can't resolve, or content-type doesn't match...) So I tried making something recently that shows, e.g., [404] as the alt text. In this form it's probably wrong in a design sense because cache probably isn't allowed to call image, but maybe it'll prompt some discussion... (and maybe it'd be better to pull the status out of the header whenever needed rather than adding more junk to the cache entry.)

2 2

gmail access
by furaisanjin＠gmail.com Dec. 23, 2008

Dec. 23, 2008

Hi all. Now I figure out the way to access gmail but I realize that isn't sophisticated. Anyway what I have modified dillo after all is add "force reload link" feature. This is the step to access gmail 1. Goto gmail.com and login in. 2. You will see meta redirect page so just force reload the link on meta redirect link. However you won't go anywhere yet. 3. Goto mail.google.com/mail, then you find link to simple HTML page. If some of you are interested the patch, I will post. Regards, furaisanjin

1 1

Re: Dillo-dev Digest, Vol 40, Issue 22
by daniel.victoria＠gmail.com Dec. 23, 2008

Dec. 23, 2008

Regarding Gmail access... I'm certanly interested in a patch Thanks Daniel On Tue, Dec 23, 2008 at 9:00 AM, <dillo-dev-request(a)dillo.org> wrote: > Send Dillo-dev mailing list submissions to > dillo-dev(a)dillo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > or, via email, send a message with subject or body 'help' to > dillo-dev-request(a)dillo.org > > You can reach the person managing the list at > dillo-dev-owner(a)dillo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dillo-dev digest..." > > > Today's Topics: > > 1. gmail access (furaisanjin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Dec 2008 09:28:14 +0900 > From: furaisanjin <furaisanjin(a)gmail.com> > Subject: [Dillo-dev] gmail access > To: Dillo-dev(a)dillo.org > Message-ID: > <144aa14b0812221628v71c176b2vf504b5bfe663e5b9(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all. > > Now I figure out the way to access gmail but I realize that isn't sophisticated. > > Anyway what I have modified dillo after all is add "force reload link" feature. > > This is the step to access gmail > 1. Goto gmail.com and login in. > 2. You will see meta redirect page so just force reload the link on > meta redirect link. However you won't go anywhere yet. > 3. Goto mail.google.com/mail, then you find link to simple HTML page. > > If some of you are interested the patch, I will post. > > Regards, > furaisanjin > > > > ------------------------------ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > End of Dillo-dev Digest, Vol 40, Issue 22 > ***************************************** >

1 0

a little ad blocker
by corvid＠lavabit.com Dec. 22, 2008

Dec. 22, 2008

If you would like one just to play with, well then: http://www.dillo.org/test/adblocker.patch (Blocking * pretty much suffices for me, so I might as well put it there as-is before I become dangerously bored with it.)

1 0

HTTP/1.1 side effect
by jcid＠dillo.org Dec. 21, 2008

Dec. 21, 2008

Hi, @corvid: while debugging the CSS loading patch, I noticed that sometimes dillo doesn't get the close after transfer event. This is needed to trigger the CSS parser with a full sheet. For instance, go to http://localhost:631/ (CUPS interface), and the progress bar will not get inactive after the page is got. Now, if you switch http.c to HTTP/1.0 queries, it will work as expected. Is there something missing, or a way to hook this? -- Cheers Jorge.-

2 1

[patch]: Basic Authentication
by onepoint＠starurchin.org Dec. 21, 2008

Dec. 21, 2008

OK, here it is. Please comment. Some observations: When the cache parses the HTTP header we just attach any authentication headers to the cache entry. Nothing else happens until we process the clients. Just before iterating over the clients we check if all the data is in. If it is then we do any necessary authentication. Opening the authentication dialog runs the FLTK event loop, which means that incoming data can call the cache again, triggering CCC warnings. We work around it by deferring the dialog to a timeout so that the cache finishes iterating over the clients before the dialog appears. This is annoying but I don't see a better way at the moment. The authentication dialog does not know which browser window opened the URL so it can't call a_Nav_reload(). Instead I implemented a_Nav_reload_url(). There's an interesting case when the server demands authentication for a realm that we have already authenticated ourselves to. It could be that we didn't send authentication because we didn't know the path was in the realm, or it could be that the authentication we sent was wrong. This requires the code to deduce what it did last time it saw this URL and rely on what it will do the next time. It works, but it feels fragile to me. I would prefer the URL to explicitly record authentication attempts so that the code doesn't have to second-guess itself. Thoughts? I implemented a full token-value list parser as per the RFC. Maybe this is overkill for Basic authentication, but it will be necessary for Digest authentication. Yes, it has gotos; I began by setting flags but decided that gotos were actually cleaner. Maybe it should be rewritten in state-machine style? If the user opens several pages in a realm in a very short time then it is conceivable that multiple authentication dialogs for the same realm could pop up (just like the https DPI sometimes does with certificate dialogs). I don't address this at the moment because I think it won't be a problem in practice. If it needs fixing then we will have to monitor the list of currently open dialogs to avoid duplicates. Regards, Jeremy Henty

4 8

[patch]: Basic Authentication
by onepoint＠starurchin.org Dec. 21, 2008

Dec. 21, 2008

Next iteration: one bugfix. * In Auth_parse_auth_basic(), fix the test for the "realm" token. Jeremy Henty

3 3

patch: error pages from file dpi
by corvid＠lavabit.com Dec. 21, 2008

Dec. 21, 2008

What do you think of sending little HTTP error pages for file not found and so on? I always find it a little jarring when nothing happens and I have to look down at the status bar for the error.

3 2

Mercurial repository
by jcid＠dillo.org Dec. 21, 2008

Dec. 21, 2008

Hi, The source code repository page was updated to Mercurial. Please send me the patches as advised there, and please add a one-liner entry in the ChangeLog file. That way it'kll be easier for me and proper credits will appear in both. -- Cheers Jorge.-

1 0

Re: CSS loading, part 1
by Johannes.Hofmann＠gmx.de Dec. 19, 2008

Dec. 19, 2008

Hi Jorge, On Fri, Dec 19, 2008 at 03:37:28PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > The attached patch does better than the current way, it has > more consistency betweeen what's shown the first time and after > back and forward (at least with my test set). > > Please test it and apply to the css-proto tree. Thanks! Pushed to css-prototpe. > > I don't know what's to be done when multiple stylesheets are > specified, like in this site: http://www.lacuarta.cl. Are they > all supposed to be loaded? If that's the case, I'd like to load > them all and after that, make a single repush instead of one per > arrival. Yes, all stylesheets with a matching media type have to be loaded. I noticed a regression on http://src.opensolaris.org/source/ Maybe it's because now only one stylesheet is loaded? I agree that having just a single repush is probabely better. I don't yet fully understand the new logic and the difference to corvid's approach. Are the style changes in css.cc and css.hh intentional? Generally it would be good to keep whitespace only changes in separate commits. That simplifies reviewing and the search for faulty changesets. BTW. "hg bisect" is a fanatastic tool for that! (similar stuff exists for git too of course). > > If that scheme is implemented, then it'd be simple to extend > the code to parse this case: > > <style type="text/css" media="all"> > @import url('/style.css'); > </style> > > > BTW, it's a very nice feeling to see CSS working. Yes it's fun! Cheers, Johannes

2 1