- Dillo-dev - lists.mailman3.com

Underscores not drawn in pre with background color
by michael.baeuerle＠stz-e.de Aug. 15, 2016

Aug. 15, 2016

Nick Warne wrote: > On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > > On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > > > > On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > > Mono" have the same problem. It is probably because of the > > > > > characters height - the next row of text overwrites the > > > > > previous. The question is whether this is because of Dillo or > > > > > because of FLTK. > > > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > > > This looks like a bug in the font: > > > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > > > (you need to scroll down a bit). > > > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > > later. > > > > > > OK, I get the same issue. But if you change the font size, thus: > > > > > > <pre style="background-color: white; > > > font-size:105%;">softpoint_with_block() { > > > > > > the underscores are visible. > > > > Huh! Strangely the underscores become visible with font size set to > > 95% too! Only 100% renders them invisible? > > OK, turning off 'use embedded CSS' makes them visible too. > > CSS parsing error? Please check whether the problem is related to this FLTK STR I created some days ago: <http://www.fltk.org/str.php?L3321>

2 1

Good news in dillo's rendering!
by jcid＠dillo.org Aug. 4, 2016

Aug. 4, 2016

Hi there, Here go some good news. Originally I was to send this internally to the core devs, but as we've benefitted from the feedback of active users in the list, and their experiences with the patches (before/afterwards), on the sites they usually browse, it looks like a good idea to do it again. Since June 6, when this thread [1] was started by Sebastian, I've been investigating/working in problems related to it. This led to some extensive rendering tests that catched a laundry list of problems with our current tip (#4643 today). This is a list with brief explanations, taken from the testing data tables I've gathered so far: Problems: 1: overwrites text with images. 2: crops images (aspect ratio). 3: different layout. 4: overwrites text with text float. 5: overwrites text with text. 6: CPU HOG with: tmp.num.html, tmp.num.small.html 7: Missing page sections (sometimes works for the same page). 8: Small images cut in two sometimes ("ESP", "CRO", ...) 9: Wrong aspect ratio for images (text line height) 10: Page drawn with offset (but browser thinks other section is on screen). There're test cases for each one, and most of them were taken and reduced from real pages. Having reduced test cases is good, reduced and isolated tests is better, but the good news is that I have a couple of patches that solve all of them! I'm not saying dillo will be error-free hereafter, but that the root of a whole family of problems has been found and fixed, and this will make future testing much simpler. GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. This is a very powerful and flexible concept whose design allows floats, layers (and absolutes in the future, and more). It has proven very fast so far, even without optimizations. Well the patches are two simple but deep changes in the way markSizeChange() and queueResize() interact. The patch idea is close to graph coverage recursions (with pruning), applied to the widget tree. I'd like to commit it, upload the test suite I'm using, and show the testing data tables I've gathered so everyone can check it with their use cases and report on it. @Sebastian: May I, or would you prefer to review them before? (the patches are the "middle ground" you mentioned. Solve the dw hog problems at dw level, not in the parser, and reuse code you've already seen. A couple of days should be enough to review) @Sebastian: Problem #10 is not related to GROWS2, but a three year old bug discovered during the tests. So let's get it done first. How to reproduce it: Go to [2], wait a bit for most images to load, then use "find text" to find the "re-re" string, scroll a bit downwards to find the image and center it. Go back then forward; no image! But dillo thinks it *is* there so move the cursor to the center of the page and you'll see the hand cursor, wait for the tooltip and drag it a bit downwards to the right. Dillo will repaint from the image data. Bisect shows the bug was introduced by #2863. Attached is a simple concept patch for it. Please review/fix/commit, as I don't know the updated invariants of resize idle. [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html [2] http://tinyurl.com/huvf6pn -- Cheers Jorge.-

2 4

Successful build on OS X
by gears_of_war__＠hotmail.com Aug. 4, 2016

Aug. 4, 2016

Dillo builds an runs on mac os x 10.5.8 (ppc32) with fltk-1.3.3. It runs great!

1 0

ImageMagick for SVG and other image types?
by jgaffney＠lawrenceville.org July 20, 2016

July 20, 2016

At this point Dillo supports the display of GIF, PNG, and JPG, but SVG is used heavily by sites like, for example, Wikipedia. Has the Magick++ library in ImageMagick been considered for supporting these other image formats? The FLTK people seem enthusiastic about the Imago library in spite of its alpha state of development; librsvg, which looks, at least to my untutored eye, like it requires a fair amount of voodoo to use, is apparently no longer actively supported and would at any rate only provide SVG support; but ImageMagick is pretty standard with Linux distributions, and the Magick++ interface makes conversions from any format to PNG for the purposes of display extremely easy. In src/misc.c, at the end of the image part of the else-if ladder in a_Misc_get_content_type_from_data(), one could add another "rung" that uses Data and Size to create a Magick::Blob, and from this a Magick::Image, then use Magick::Image.write() to write this to another Magick::Blob of type PNG, and then replace Data and Size with those of the resulting Magick::Blob. A try-catch block would catch the cases where Data is not an image. Altogether this sort of "cheat" would require very few lines of code to implement. And the Magick++-config utility could supply the needed -D..., -I..., -l... flags to the configure script. I'm not suggesting this is an ideal long-term solution, but in the interim would at least allow the display of other image types. The most recent mention of this on the mailing list seems to be Jorge's indication on 22 April 2016 that No, there's no SVG image support in dillo yet. It should not be hard to implement though, but it needs an effort similar to GIF or PNG or JPEG code. Patch welcomed! ;) But surely someone has thought of ImageMagick before. Are there objections to using it? And if so, maybe a flag could be set by the configure script to conditionally compile this in for those who want it? (If this is pursued, the configure script should probably also check that the version of ImageMagick is recent enough to have been patched against that serious exploit in just this sort of conversion code.) A test program shows that the invocation of ImageMagick and conversions really are as simple as the steps outlined above. But I would be happy to make an attempt at a patch, if you don't mind this being undertaken by an amateur.

1 1

cppcheck on Dillo source
by nick＠linicks.net July 17, 2016

July 17, 2016

Hi all, While waiting for the Tour De France to start on TV, I ran cppcheck on Dillo source for something to do - a few errors were picked up! I have compacted the findings (with two comments from me)and attached it as a plain text file. Keep up the great work guys and thanks! Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

3 6

Problem related to generated content
by sgeerken＠dillo.org July 10, 2016

July 10, 2016

Hi! I've come upon an interesting problem. Consider this HTML (stripped down from a real world example): <head> <style> .fc:after { content: ""; display: block; clear: both; } </style> </head> <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="background:#404040; color:#ffffff">footer</div> </body> Firefox (and probably other browsers) renders black text "main" on white background above white text "footer" on dark gray background. Dillo 3.0.5 does the same, for the simple reason that it does not support floats. Dillo 3.1-dev, however, renders black text "main" and white text "footer" side by side on dark gray background, because "main" is within a float. (Which is, of course, difficult to read.) The reason why Firefox renders this as it does: the definition within <style> generates something like a block element before the text containing "footer", with "clear: both" as CSS attributes; something like: <body> <div class="fc"> <div style="float: left">main</div> </div> <div style="clear:both"></div> <div style="background:#404040; color:#ffffff">footer</div> </body> Aside from the fact that dillo has still problems with this ("footer" is too much to the right; I'll investigate this independently), this shows that dillo's limited capabilities regarding generated content, together with floats, causes some unpleasing rendering errors, which are furthermore laborious to analyse (and thus not so simple to be ignored). Has someone a feasible idea to deal with this? Sebastian

1 1

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 9, 2016

July 9, 2016

First, a huge thanks to all the Dillo team for their efforts: I just switched from 3.0.5 to the current snapshot to try out the mbedtls changes, and I am wowed not only by this, but by all the improvements in rendering, etc. Great work! A few suggestions, all very minor, that might be added to the back of the development queue: In the current snapshot, the navigation bar has changed, and the URL field does not seem to be taking into account font_factor -- with the result that the window is smaller than the font height. You can test this by setting, e.g., font_factor=2.0 in your dillorc (most dramatically for a tiny panel with small icons). The issue seems to be with this factor not being taken into account when bh and lh are set in make_panel() in ui.cc. As far as I can see, one can use the context menu to download individual images on a page, or use the panel to toggle image loading. But if one wants not to download images in general, but to download all the images for some one page (e.g., a weather forecast page), then one has to toggle downloading of images on and then off again. Maybe a command could be added to KeysCommand_t in keys.hh, bound by default to something like Ctrl-i in keys.cc, with a corresponding call to a_Html_load_images() in handle() in ui.cc? To make the switch to the current snapshot, I had, sadly, to terminate an instance of 3.0.5 that had been running continuously for 90 days without any issues. But to get that much up time it was necessary to add a little code so that SIGUSR1 would call a_Dns_freeall() and a_Dns_init(), otherwise (unless I am missing something) Dillo will persist in using the cached lookup indefinitely and not detect when the IP address has changed. So maybe some sort of key binding could be added that would flush the cache when needed? Thanks again for all your hard work!

4 5

patches #4634 and #4635
by jcid＠dillo.org July 9, 2016

July 9, 2016

Hi corvid, Some comments: ----------------- Patch #4635: rm IO flags, as they are never used Yes, those linger from a time when shutdown() was used for handling sockets in dillo. Not necessary now since we use read() write() close(). ------------------ Patch #4634: freeing http socket, close FD that's being connected Why did you do this? (i.e. Is there a specific bug?). Beware the FD is closed inside IO.c (OpEnd|OpAbort). If you close it in Http_socket_free(), you are opening race conditions on file descriptors, and coding outside the design. Http_socket_free() is used with the CCC chains, that's why it doesn't close the FD, IO will do it by means of CCC; avoiding race conditions. I haven't tested the code yet, but I'd be amazed if resources don't stop to load at random. For instance, Http_socket_reuse(int Skey) would be activating and reporting success on a socket that's just been closed. Please review all the related patches and be more careful before committing. PD: IIRC I used lsof to check for FD leaks long ago. -- Cheers Jorge.-

1 0

an experiment using mbed TLS
by eocene＠gmx.com July 8, 2016

July 8, 2016

I wanted to see what it would take to use mbed tls with dillo. I put a copy of the diff at http://www.dillo.org/test/mbedtls.diff and I mention it here in case someone should want that one day. That said, it looks like netsurf uses curl, and curl can use any tls library you care to mention. And I'm pretty sure netsurf does javascript.

5 17

URL field / Loading page images / Refreshing DNS cache
by jgaffney＠lawrenceville.org July 8, 2016

July 8, 2016

Jorge Arellano Cid <jcid at dillo.org> writes: [...] >> As far as I can see, one can use the context menu to download >> individual images on a page, or use the panel to toggle image >> loading. But if one wants not to download images in general, but to >> download all the images for some one page (e.g., a weather forecast >> page), then one has to toggle downloading of images on and then off >> again. Maybe a command could be added to KeysCommand_t in keys.hh, >> bound by default to something like Ctrl-i in keys.cc, with a >> corresponding call to a_Html_load_images() in handle() in ui.cc? > > This is interesting. > >> To make the switch to the current snapshot, I had, sadly, to terminate >> an instance of 3.0.5 that had been running continuously for 90 days >> without any issues. > > Wow, it's good to know it can last that long. > > What you describe here is very interesting, in a way I've > come to suspect most users don't have the slightest clue. > > I mean, everyone of us (as dillo users) have *different* use cases. > There's no way we can guess what other people are doing outside of > our awareness realm. > > Now, you're not only a casual user, but one that uses dillo *a lot*, > and appreciate it as an everyday tool. > > That being stated, we are very interested in knowing your use case, > and all the details of it. There's potentially a lot we can learn from it, > and also improve yours/and-the-generic user experience as a result of > this learning. > > So please elaborate on why you like to have it running for that long time, > what do you do with it, how you do it, what problem does it solve that other > tools don't, why is it your choice. What you'd wish it had. I had been using Firefox (and still do, for trusted sites that require javascript), but looked around for another browser when the option to turn off javascript was removed from the preferences dialog -- when javascript is so often the vulnerability behind exploits, I didn't want a browser hoisting in javascript from all over the Internet at its own discretion. (It is still possible to turn javascript off in Firefox if one starts from a script that invokes a prefs.js with a legacy `user_pref("javascript.enabled", false);', or from the internal about:config page, but:) Dillo was one of the few browsers without javascript, and when I checked it out, I found that I agreed very much with Dillo's stated philosophy. And it has been my principal browser ever since. In fact, along with an xterm and Emacs, it's one of the three apps always running on my machine. Things I like about Dillo: Dillo doesn't even include javascript. (I cringe a bit when there is talk on the list about the possibility of including it -- if it is included at some point, I hope that there will be a #define to exclude that code at compile time.) Dillo is small and fast, which is nice not only for general browsing, but when invoking it through, e.g., Emacs to open a link. Dillo let's me configure things the way I like, and when it doesn't do something I want, the code base is accessible enough that I can modify it to do so. (I had in fact already implemented the suggestions I made, but didn't share any patches because, even beyond being an amateur, my hacks tend to be on the ugly side -- the loading of images per page, for example, required adding #include "html.hh" to ui.cc, indicating that I am certainly violating some logic of organization and encapsulation.) Dillo isn't phoning home or doing anything else behind my back, and it let's me easily block ad and other such sites in domainrc. Dillo doesn't try to do all sorts of exotic things, or invoke external apps to do them, with all of the potential security risks. With other browsers, you have to do a lot of work to try to prevent this sort of automagical behavior, and even if it's possible, you aren't left feeling at all confident about having prevented it. Like you, I like that Dillo caches DNS lookups, but of course IP addresses change from time to time for legitimate reasons, so there does need to be a way to flush the cache. Johannes's patch is a good one, but I also still like the idea of using the cache until I need it to refresh. Of course, one could simply start a new instance of Dillo, but I also like that it caches pages in a way that allows me to open a link to a previously visited page off-line, without trying to reconnect and reload it. And -- possibly a unique personal idiosyncrasy -- I like to see links I have visited displayed as visited. Other than that, there really isn't any reason not to be firing up a fresh instance of Dillo whenever it is needed. And probably a lot of other virtues in Dillo that just aren't coming to mind right now. > Some things may be possible, others not, a few may be solved in different > ways, etc. Just learning about those key tasks, or improving a single one, > would be a big gain for all of us. > > Your feedback as a dillo power-user is not only welcomed, it's asked for! > > >> Thanks again for all your hard work! > > Ack! > > > @all: if you're a dillo power-user, let us know about it!

1 0