- Dillo-dev - lists.mailman3.com

dillo2.x on Fedora 12
by itsme_410＠yahoo.com Jan. 19, 2010

Jan. 19, 2010

Hi, Any likelihood of getting some Fedora 12 dillo2 RPMS? Thanks for the great work!! Best, T

3 5

Cookies performance
by Johannes.Hofmann＠gmx.de Jan. 19, 2010

Jan. 19, 2010

Hi, I noticed that since the recent DPI update pages which use cookies load slower (e.g. fltk.org) Do others also see that? It could also be OS specific. Cheers, Johannes

3 25

some code for better cookie rejection
by corvid＠lavabit.com Jan. 16, 2010

Jan. 16, 2010

Yesterday I made a rough draft of some code to allow the use of the http://publicsuffix.org/list/ to determine which domains dillo shouldn't allow cookies to be set for: http://www.dillo.org/test/public_suffix.diff I just put it there for safekeeping for now, as I have no plans to clean it up and get it into dillo until after the next release, but it occurred to me that I should at least mention it's there for anyone who uses cookies and lives somewhere where the domain situation is complicated (e.g., Japan). A user would have to add a line to cookiesrc like public_suffix_file /path/to/list/file

1 0

web bug save?
by bblochl＠arcor.de Jan. 12, 2010

Jan. 12, 2010

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.ht… >> >> (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-stat… 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.ht… 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

4 15

HTML4 testpage containing all elements
by Johannes.Hofmann＠gmx.de Jan. 11, 2010

Jan. 11, 2010

Hi, does anyone have a test page containing all possible HTML4 element? Cheers, Johannes

2 1

want to test some experimental cookies code?
by corvid＠lavabit.com Jan. 10, 2010

Jan. 10, 2010

In recent days, I've been making a version of cookies dpi that follows the current cookies draft of the http state working group. I haven't tested it exhaustively yet, but if anyone who uses cookies wants to try it and watch the msgs and so on, let me know. As for how much validity or meaningfulness this draft has, let's see... - They've made the decision to describe the way things currently behave, having learned from the bitter experience of others who made RFC 2109 and RFC 2965*. In 2010, no one has any way to be King of Cookies. They write testcases and try all of the major browsers and decide what they want to write down in their spec when there are differences. - On their mailing list, from the user agents, they have an opera guy, the curl guy, and someone related to firefox, although I didn't take any notice of whether he has a position of authority in firefox or not. - Of course there will be changes. Smallish, I think. A cookie set without an explicit domain goes only to that domain. A cookie with a domain attribute is sent to that domain and any subdomain. A .domain attr cookie can go to domain. As for how to decide to reject cookies for, e.g., .co.uk, I don't think they're ever going to say too much. A cookie can be set for any path, regardless of the url path of the page setting it. Paths are matched when selecting cookies to return, though. Path-matching does work by slashes instead of simple prefixes. An http page can set a secure cookie (just like currently). An example of the little things that may change are that a cookie that is just VALUE instead of NAME=VALUE is currently allowed, but it's not decided for good yet. There are corner cases such as this that maybe they could make illegal without rendering themselves irrelevant. * To be precise, the main author of the RFCs has written that it was at least initially reasonable to think that what they were putting together in rfc 2109 would be adopted by user agents.

3 3

Doctree changes
by Johannes.Hofmann＠gmx.de Jan. 7, 2010

Jan. 7, 2010

Hi, I just committed a modification of the Doctree class which is used for CSS matching. Before it was just an interface that was implemented by StyleEngine. Now it is a real class that is used by StyleEngine. I hope the new origanization makes things a bit clearer. It also avoids virtual method calls in the performance critical CSS matching path. To me it seems that complex pages render a bit faster now, but I did not make any proper measurements. Cheers, Johannes

1 0

Query on interfacing IMX27 keyboard with Dillo browser.
by rmarathe11＠gmail.com Jan. 7, 2010

Jan. 7, 2010

Hello, I am using Dillo as a browser on IMX27 system. (working with latest CVS LTIB code). I wanted to interface imx27 Keyboard with the browser so that the UP/DOWN/etc. keys work on the browser pages. I have been using this with Touchscreen and I wanted to know if the Keyboard can be interfaced too. Presently, I saw that on any Linux installation with Dillo on it, only mouse works as mouse can be moved from one link to other link. But keyboard was not working. I would want to make the Keyboard UP/DOWN arrows take me up and down the links on a page in the Dillo browser. Is it possible to do this ? regards, Rajesh Marathe.

3 2

table/cursor oddity
by corvid＠lavabit.com Jan. 5, 2010

Jan. 5, 2010

A little bug that I just stumbled upon. <table border=1> <tr><td style="cursor:help">one<td style="cursor:wait">two<td>three <tr><td colspan=3>row </table> The style of the first td seems to be the style of the whole table. (I wasn't surprised that the text has the default cursor, since I know there's that weirdness with wordStyle and regular style. Speaking of which, is it spelled out anywhere what is going on with that exactly? I know there have been times when I've been in the area of the table code and some reason why it's necessary has become clear, but I don't think I've ever had the whole shape of the matter in my head.) Hmm. I just changed the first td to style="cursor:help; color:red", and it colored the first td correctly, and now the rest of the table shows the wait cursor. Interesting.

2 2

Query on Dillo browser supporting "frames"
by rmarathe＠i-rode.com Jan. 5, 2010

Jan. 5, 2010

Hi, Will Dillo2 browser support "Frames" in future ? IF yes, what is the time frame for that release ? regards, Rajesh Marathe.

2 1

Javascript
by iveqy＠iveqy.com Jan. 5, 2010

Jan. 5, 2010

Hi, I'm a big dillo fan and a fltk user. Dillo is the fastest browser I ever seens and I strongly like it (too bad fltk 1.3 isn't used but that I believe is to blame the fltk team for). Anyway, now that CSS is almost done, I wonder how the future for javascript support looks. The old discussions I found about this looks to be outdated with the CSS changes. I also found a patch to allow javascript in dillo, but that patch didn't seemed to use the dpi-interface. Would it be possible to use dpi to use the v8 enginge for dillo? -- Regards iveqy

1 0

patch: handle cookie time overflow
by corvid＠lavabit.com Jan. 2, 2010

Jan. 2, 2010

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.

2 2

patch: .domain cookies from/to domain
by corvid＠lavabit.com Jan. 2, 2010

Jan. 2, 2010

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!

3 7

[bug]: CSS - attack of the mega-images
by onepoint＠starurchin.org Jan. 1, 2010

Jan. 1, 2010

See http://blog.worldlabel.com/2009/inkscape-0-47-totally-solid-with-lots-of-ne… 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

2 1

table/cell width problem
by corvid＠lavabit.com Dec. 29, 2009

Dec. 29, 2009

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.

3 3

Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS
by rmarathe＠i-rode.com Dec. 28, 2009

Dec. 28, 2009

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.

2 1

secure cookies
by corvid＠lavabit.com Dec. 27, 2009

Dec. 27, 2009

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

1 0

are cookies supposed to be working nowadays?
by corvid＠lavabit.com Dec. 27, 2009

Dec. 27, 2009

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

1 0

[un]highlighting and drawing lines
by corvid＠lavabit.com Dec. 26, 2009

Dec. 26, 2009

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?

1 0

[oph-villedieu@orange.fr: dillo_2.1.1]
by jcid＠dillo.org Dec. 26, 2009

Dec. 26, 2009

Hi, I just received this email. The attached example shows the bug. Does anybody remember what we did with valign? ;) -- Cheers Jorge.-

3 5

web bug save?
by bblochl＠arcor.de Dec. 26, 2009

Dec. 26, 2009

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

4 3

dpi program names
by corvid＠lavabit.com Dec. 24, 2009

Dec. 24, 2009

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.

2 2

patch: no size 0 images
by corvid＠lavabit.com Dec. 22, 2009

Dec. 22, 2009

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

1 0

patch: vertical-align
by corvid＠lavabit.com Dec. 22, 2009

Dec. 22, 2009

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

1 1

new fltk snapshot
by corvid＠lavabit.com Dec. 18, 2009

Dec. 18, 2009

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

1 0

take_focus on a new tab
by furaisanjin＠gmail.com Dec. 17, 2009

Dec. 17, 2009

Hi all. I'm wondering if "BW2UI(new_bw)->tabs()->selected_child()->take_focus()" is really needed in a_UIcmd_open_url_nt. I usually hit space bar to scroll down but I can't do this when I open a new tab by clicking middle mouse button. The reason is that cursor stays on address bar so that I just add space at the end of url if I hit space bar. Regards, furaisanjin

6 27

display: inline
by Johannes.Hofmann＠gmx.de Dec. 13, 2009

Dec. 13, 2009

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 > > <form action=...> > > <input type=text name=... value="something to right-click on"> > > <div style="display:none"> > > <textarea name=...> > > text > > </textarea> > > </div> > > </form> > > 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: <html> <body> <ul> <li>foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ / \ li li AlignedTextblock AlignedTextblock | b whereas: <html> <body> <ul> <li style="display: inline">foo</li> <li>ba<b>r</b></li> </ul> </body> </html> results in: DOM-Tree: Widget-Tree: ========= ============ html | body Textblock | | ul Textblock / \ | li li AlignedTextblock | b Cheers, Johannes

3 4

Adding CSS properties and values
by tim.nieradzik＠gmx.de Dec. 11, 2009

Dec. 11, 2009

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

2 1

HTML parser bug
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

There is a bug in the HTML parser: Tags within quotes are interpreted: <input type="text" name="test" value="<p>asdf</p>" /> 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: <input type="text" name="test" value="<p>\"asdf\"</p>" /> --Tim

3 2

display: inline
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

Sorry, I forgot to attach the patch. :) --Tim

1 0

dpid not starting automatically
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

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

2 1

Misbehaving dw-demos
by tim.nieradzik＠gmx.de Dec. 5, 2009

Dec. 5, 2009

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

2 1

patch: anchors no longer words
by corvid＠lavabit.com Nov. 30, 2009

Nov. 30, 2009

A few days ago, I tried to make addParbreak() work properly when listitems have anchors in the beginning (that's why they often show breaks before their contents), but it was quite icky -- and required more extensive changes than I expected. So instead, here's what we get if we pull the anchors out of the Word list and store them separately. Less icky.

3 3

[patch]: trim the labels of the stylesheet menu
by onepoint＠starurchin.org Nov. 21, 2009

Nov. 21, 2009

While thinking about stylesheet issues I noticed a UI problem: the stylesheet menu uses URLs as the labels of the menu items. This is unfortunate because some sites have stylesheets with insanely long URLs. (Try Wikipedia if you don't believe me!) So I'm attaching a patch that trims long URLs in the menu. This is just a UI change - no functionality is affected. Here's a demonstration of the patch on the front page of Wikipedia: http://starurchin.org/dillo/stylesheet_menu/ Notes: Since the label is no longer always the same as the label the callback must find the URL elsewhere. We put it in the user_data() of the menu item. We just copy the pointer to the DilloUrl structure, so we are assuming it will never be free()-ed while the menu is up. If I'm wrong about this the patch will need to be revised. We get a nice cleanup for free: we loose the mysterious magic constant 5 in the callback. (Bonus points if you can see what that magic constant is! Double bonus points if you can see why the code still worked when I erroneously left it in!) Please comment, Jeremy Henty

2 3

EAGAIN loop in IO_read
by furaisanjin＠gmail.com Nov. 21, 2009

Nov. 21, 2009

Hi all. This might be FreeBSD specific issue but I have EAGAIN loop in IO_read. I don't know anything yet why this happens but at some point read function keeps returning EAGAIN in IO_read and nothing is read. Do you have any idea how to investigate this further? I think this happens after DPI big change. Regards, furaisanjin

4 26

Q: why do we defer loading linked stylesheets?
by onepoint＠starurchin.org Nov. 20, 2009

Nov. 20, 2009

Why do we defer loading the CSS stylesheets named in <link> elements until the <head> element is closed? In html.cc, Html_tag_close_head() has the comment "charset is already set, load remote stylesheets now", but I don't understand the significance of the charset. I am asking because I'd like to patch Dillo to add @import-ed stylesheets to the browser window popup menu, just as it already does for <link>-ed stylesheets. At the moment this causes all sorts of code branches (is the @import in a <link>-ed file or an embedded <style>, if the latter, is it in the <head> or not). It would be much simpler to just immediately load every style file at the same time as it is added to html->ccsUrls , but that would change the behaviour to load <link>-ed styles immediately instead of at the end of the <head> element. Would that break anything? Regards, Jeremy Henty

3 8

weird font
by jcid＠dillo.org Nov. 18, 2009

Nov. 18, 2009

Hi, On some sites I get weird fonts. Today I got to isolate the problem. See attached file. Here it displays like this: http://www.dillo.org/test/xmp2.png The embedded CSS says: pre { font-family: MS Courier New, Courier, monospace; } If I remove "MS Courier New", it works OK. Any clues? -- Cheers Jorge.-

4 8

Big changes in DPI framework and API
by jcid＠dillo.org Nov. 8, 2009

Nov. 8, 2009

Hi, Today the big work on DPI/DPIP was committed! The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago. There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less). One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now). Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain. Please test and enjoy. ...and remember to "dpidc stop" before "make install-strip". -- Cheers Jorge.-

4 15

Dillo package for Ubuntu 9.10
by Hole.destructor＠gmx.de Nov. 7, 2009

Nov. 7, 2009

Dear Dillo developers, could anyone be so kind and build a Dillo package (with ssl enabled) and a FLTK2 package for the new Ubuntu version 9.10 Karmic Koala? Many thanks in advance, Alexander Voigt

1 0

[patch]: fix the default <th> style to match <td>
by onepoint＠starurchin.org Nov. 7, 2009

Nov. 7, 2009

I had assumed that the <th> style would be the same as the <td> style but with bold and centering added, so I was surprised to see that it's not. The <td> style has some border styling and padding that the <th> style does not, which seems wrong to me. I'm attaching a patch that brings the <th> style in line with my expectations, plus a test file and before/after screenshots. Please comment! Regards, Jeremy Henty

2 1

Style sheet question (centering and list-style-type)
by furaisanjin＠gmail.com Nov. 5, 2009

Nov. 5, 2009

Hi all. I'm wondering how this web page will be rendered. <HTML> <HEAD> <style></style> <TITLE>test</TITLE> </HEAD> <BODY> <div id="menu"> <ul> <li><a href="http://xxx.xxx.xxx/1">first second</a> </ul> </div> </BODY> </HTML> Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin

2 2

Crashes at bizmakoto.jp
by furaisanjin＠gmail.com Nov. 4, 2009

Nov. 4, 2009

Hi. I don't try all pages but at least there are several pages where dillo keeps crashing. One example is http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace shows something like this. #0 0x28554687 in __vfprintf () from /lib/libc.so.6 #1 0x284e1fe0 in vsnprintf () from /lib/libc.so.6 #2 0x0807a16f in dStr_vsprintfa (ds=0x83cad40, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n", argp=0xbfbfe318 "$B!&(B216\017\b") at dlib.c:362 #3 0x08065f94 in DilloHtml::bugMessage (this=0x847f400, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n") at html.cc:144 #4 0x0806bed5 in Html_tag_cleanup_at_close (html=0x847f400, new_idx=8) at html.cc:1338 #5 0x0806ce4f in Html_write_raw (html=0x847f400, buf=0x861e000 "\n\n<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\n<html id=\"/bizid/articles/0911/02/news082.html\">\n<head>\n<meta http-equiv=\"Content-Type\" content"..., bufsize=59935, Eof=0) at html.cc:3514 #6 0x0806dca5 in DilloHtml::write (this=0x847f400, Buf=0x0, BufSize=59935, Eof=0) at html.cc:556 #7 0x0806ddbe in Html_callback (Op=0, Client=0x8502380) at html.cc:3673 #8 0x0805b862 in Cache_process_queue (entry=0x8562980) at cache.c:1173 #9 0x0805c41f in Cache_delayed_process_queue_callback () at cache.c:1237 #10 0x080cc874 in fltk::wait () #11 0x080cca19 in fltk::run () #12 0x0804f158 in main (argc=1, argv=0xbfbfe798) at dillo.cc:353 I set YES/NO on w3c_plus_heuristics in dillorc but it didn't help. It seems that new_tag contains something valid but tag looks corrupted or not-initialized. (gdb) p new_tag $1 = {name = 0x80f8ef7 "body", Flags = 30 '\036', EndTag = 79 'O', TagLevel = 1 '\001', open = 0x8069e9c <Html_tag_open_body>, close = 0x8067db0 <Html_tag_close_body>} (gdb) p tag $2 = {name = 0x79000000 <Error reading address 0x79000000: Bad address>, Flags = 16 '\020', EndTag = 0 '\0', TagLevel = 0 '\0', open = 0, close = 0x2f} Regards, furaisanjin

3 7

PATCH: don't force selection of first element in multi-select input.
by dtikhonov＠yahoo.com Nov. 4, 2009

Nov. 4, 2009

Hi all, Great job on dillo! Below is a patch that prevents the browser from selecting the first element of a multi-select input. Thanks, - Dmitri. --- a/src/form.cc Mon Nov 02 13:41:37 2009 -0300 +++ b/src/form.cc Tue Nov 03 12:57:02 2009 -0500 @@ -767,8 +767,8 @@ void Html_tag_close_select(DilloHtml *ht DilloHtmlInput *input = Html_get_current_input(html); DilloHtmlSelect *select = input->select; - // BUG(?): should not do this for MULTI selections - select->ensureSelection (); + if (DILLO_HTML_INPUT_SEL_LIST != input->type) + select->ensureSelection (); SelectionResource *res = (SelectionResource*)input->embed->getResource(); select->addOptionsTo (res);

2 2

Cleanups for Html_tag_cleanup_at_close()
by onepoint＠starurchin.org Nov. 2, 2009

Nov. 2, 2009

Congratulations on the big DPI reworking! Meanwhile I'd like to submit some cleanups for Html_tag_cleanup_at_close(), whose logic is currently pretty opaque. The first is a resubmit (it seems to have vanished into the ether when last posted). These should have no effect on behaviour, they just make it more clear what is going on. Regards, Jeremy Henty

2 2

arbitrary keysyms in keysrc
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

Jorge wrote: > On Sat, Oct 31, 2009 at 11:39:15PM +0000, corvid wrote: > > > > What would you think of allowing arbitrary keysyms > > to be specified in keysrc using their hex values? > > What's the gain? Being able to use a hex code from xev? > (to me it's an obscure representation, but easy to find OTOH) I finally got a newer computer, and it has some buttons that fltk has no idea about (e.g., a picture of a rectangle and arrow that X thinks of as XF86Next), and it would be nice to be able to use them.

1 0

patch: jpegs and cmyk color space
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

Here's one page that links to some CMYK jpgs and pretty much fits with what I've been able to learn: http://code.google.com/p/chromium/issues/detail?id=21659 Everything I find on the web about this shows roughly the same amount of uncertainty.

1 0

arbitrary keysyms in keysrc
by corvid＠lavabit.com Nov. 1, 2009

Nov. 1, 2009

What would you think of allowing arbitrary keysyms to be specified in keysrc using their hex values?

1 0

Latest whitespace handling patches
by jcid＠dillo.org Oct. 29, 2009

Oct. 29, 2009

Hi, The latest cleanups and whitespace handling patches have come like a fresh breeze removing unnecessary code. They're good for better code clarity. One of the few regressions I've noticed is extra underlining of links (the space before the first word's letter). As in: http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 BTW, I'm close to commiting the DPIP changes. Hopefully near this month's end. -- Cheers Jorge.-

2 5

Re: NULL for default tag close?
by jcid＠dillo.org Oct. 27, 2009

Oct. 27, 2009

On Tue, Oct 27, 2009 at 05:09:37PM +0000, corvid wrote: > Would it be all right if I changed the default_close()s to NULL? > I think it makes Tags[] easier to read, I'd prefer it as is for the same reason! :-) > and testing for NULL would > mean less time calling an empty function anyway... I'd be surprised if the gain is more than 0.1%. BTW, today in one part of the DPIP code I found that avoiding thousands of read() calls made no noticeable difference. With write() it was a different story though. Most probably gcc optimizes out empty functions too. -- Cheers Jorge.-

1 0

Re: link signal emission from layout?
by corvid＠lavabit.com Oct. 25, 2009

Oct. 25, 2009

Jorge wrote: > On Sat, Oct 24, 2009 at 03:48:55PM +0000, corvid wrote: > > I never liked all of the connectSignals() for all of the > > textblocks and images and whatever else in html.cc. > > Why not? So much signal connection for the listitems and the tablecells and everything, and all redundant, since it's all going back to the same receiver in html. > > Would you have any opinion about moving the > > (perhaps increasingly-inaccurately-named) > > link signal emission to layout? > > Could be. > > > I was just playing with the idea, and, at least after > > a moment's test :) , it seemed to be working. > > And, as a bonus, it lets me pop up menus when > > pressing button 3 below the bottom of page content. > > I miss this feature. Also being able to popup a menu over > a bare image would be a plus. Random thought: it would nice if there were a mechanism to change the size of images. > > (I left the event emitter alone for the moment, but I > > think the only thing using it right now is plain.cc. > > If so, it would be nice to rip that out in any case, > > even if plain doesn't have "links" exactly...) > > I don't know why it's currently done in html.cc, maybe it's > just grouping by required functionality, maybe not. If the new > approach is simpler and provides the same and more as you > pointed, id say: +1. It's simpler for src/, but the ickiness is preserved for dw/, since what was excised from Widget gets implanted into Layout. > BTW, please move this thread to dillo-dev.

1 0