- Dillo-dev - lists.mailman3.com

font size / dpi

by eocene＠gmx.com

On a 125 dpi display, web pages tend to be tiny. For font_factor, dillorc claims "All font sizes are scaled by this value", but that's only true for html sizes and the css sizes like 'small' 'x-large' etc. [hmm...speaking of which, I see there's a bug in there for 'larger' and 'smaller' where we apply font_factor erroneously.] We should either change the claim or make it true. Also, I was refreshing my memory on the resolution-independent px discussion from January. Mostly it was about concern for the cost of scaling images, and I realize that we kind of have to deal with images or else everything doesn't fit together, but...it would be nice in some ways if we could at least scale font sizes by dpi (the css px ones and the assorted 14's that we have around in src/ ).

May 9, 2015

SSL in the browser

by eocene＠gmx.com

I had planned to wait until after 3.1 to integrate the ssl-in-browser code, but since 1) dillo hasn't been moving toward release lately and 2) Johannes tells me that the patch has been working well for him, I now plan to put it into dillo when I get a chance in coming days. Having it in dillo means that dillo can be a better internet citizen (http_max_conns, http_persistent_conns), there is certificate hostname checking borrowed from wget, server name indication (fewer certificate warnings), we can remember for the session that the user accepted the use of a questionable certificate instead of continuing to give warnings, we can check non-root-url certificates without endless warning popups...

May 8, 2015

Crash with ascii text scribbled across a data structure.

by james.from.wellington＠gmail.com

>From time to time, I get a most peculiar SEGV. Here's an example on fairly clean source up to c761c66 on a mac: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x00000001000064b7 in Fl_Widget::position (this=0x118148910, X=2003792928, Y=1869881479) at Fl_Widget.H:321 321 void position(int X,int Y) {resize(X,Y,w_,h_);} (gdb) bt #0 0x00000001000064b7 in Fl_Widget::position (this=0x118148910, X=2003792928, Y=1869881479) at Fl_Widget.H:321 #1 0x000000010008521a in dw::fltk::FltkViewport::updateCanvasWidgets (this=0x101208a10, dx=0, dy=-25) at fltkviewport.cc:502 #2 0x0000000100086492 in dw::fltk::FltkViewport::scrollTo (this=0x101208a10, x=0, y=347) at fltkviewport.cc:398 #3 0x0000000100084c10 in dw::fltk::FltkViewport::scroll (this=0x101208a10, dx=0, dy=-25) at fltkviewport.cc:413 #4 0x0000000100084c4a in dw::fltk::FltkViewport::vscrollbarChanged (this=0x101208a10) at fltkviewport.cc:156 #5 0x0000000100084c65 in dw::fltk::FltkViewport::vscrollbarCallback (vscrollbar=0x101208c90, viewportPtr=0x101208a10) at fltkviewport.cc:161 #6 0x0000000100100b13 in Fl_Widget::do_callback (this=0x101208c90, o=0x101208c90, arg=0x101208a10) at Fl_Widget.cxx:328 #7 0x000000010001a8ef in Fl_Widget::do_callback (this=0x101208c90) at Fl_Widget.H:840 #8 0x00000001001005c1 in Fl_Valuator::handle_drag (this=0x101208c90, v=347) at Fl_Valuator.cxx:95 #9 0x00000001000ec3bc in Fl_Scrollbar::handle (this=0x101208c90, event=19) at Fl_Scrollbar.cxx:142 #10 0x00000001000857d7 in dw::fltk::FltkViewport::handle (this=0x101208a10, event=19) at fltkviewport.cc:304 #11 0x00000001000ceb39 in send (o=0x101208a18, event=19) at Fl_Group.cxx:98 #12 0x00000001000cf338 in Fl_Group::handle (this=0x10053d760, event=19) at Fl_Group.cxx:254 #13 0x0000000100007aa2 in UI::handle (this=0x10053d760, event=19) at ui.cc:788 #14 0x00000001000ceb39 in send (o=0x10053d760, event=19) at Fl_Group.cxx:98 #15 0x00000001000cf338 in Fl_Group::handle (this=0x10053d6b0, event=19) at Fl_Group.cxx:254 #16 0x00000001000ceb39 in send (o=0x10053d6b0, event=19) at Fl_Group.cxx:98 #17 0x00000001000cf338 in Fl_Group::handle (this=0x10053cf60, event=19) at Fl_Group.cxx:254 #18 0x00000001000b7b94 in Fl_Window::handle (this=0x10053cf60, ev=19) at Fl.cxx:1643 #19 0x00000001000b67e0 in send (event=19, to=0x10053cf60, window=0x10053cf60) at Fl.cxx:1136 #20 0x00000001000b8ad1 in Fl::handle_ (e=19, window=0x10053cf60) at Fl.cxx:1444 #21 0x00000001000b8b7a in Fl::handle (e=19, window=0x10053cf60) at Fl.cxx:1216 #22 0x00000001000ab1b3 in cocoaMouseWheelHandler (theEvent=0x1181582b0) at Fl_cocoa.mm:943 #23 0x00000001000ab1e8 in -[FLView scrollWheel:] (self=0x101505a50, _cmd=0x7fff8965ff98, theEvent=0x1181582b0) at Fl_cocoa.mm:2250 #24 0x00007fff890580c7 in -[NSWindow sendEvent:] () #25 0x00007fff88f8cafa in -[NSApplication sendEvent:] () #26 0x00000001000aed74 in +[FLApplication sendEvent:] (self=0x1001b36d0, _cmd=0x7fff896552c0, theEvent=0x1181582b0) at Fl_cocoa.mm:1609 #27 0x00000001000ae989 in do_queued_events (time=1e+20) at Fl_cocoa.mm:749 #28 0x00000001000ae9bf in fl_wait (time=1e+20) at Fl_cocoa.mm:773 #29 0x00000001000aea86 in fl_mac_flush_and_wait (time_to_wait=1e+20) at Fl_cocoa.mm:792 #30 0x00000001000b9081 in Fl::wait (time_to_wait=1e+20) at Fl.cxx:528 #31 0x00000001000b910b in Fl::run () at Fl.cxx:589 #32 0x00000001000052a7 in main (argc=1, argv=0x7fff5fbff280) at dillo.cc:589 (gdb) print (char *)this $6 = 0x118148910 "lore ipsum the text out of the editor window in the email.\n\nMore lorem ibsum.\n\nRegards,\nJames." 0x118148910 is correctly allocated to dw::flak::ui::FltkLabelButtonResource, according to Apple's debugging malloc. I can't find, in the debugging malloc, the allocation for storing the text in the text-box. The worst cases are that someone is scribbling malloc control structures, or someone is scribbling addresses in a dillo data structure. I've seen something essentially the same where the scribble contained a URL. I'm contemplating relinking with electric fence. Regards, James.

April 22, 2015

website colors (Re: Secure: yes, Though Features Missing; and Bugs)

by eocene＠gmx.com

I wrote: > Miroslav wrote: > > On Sat, Apr 04, 2015 at 05:24:46AM +0000, eocene wrote: > > > A couple of years ago, I experimented with a different color scheme, but > > > the other members of the core team weren't enthusiastic about it, so I > > > never made the change. Example: http://www.dillo.org/test/dillo2.html > > > > > Pls, pls. dillo devs, allow that color scheme. > > > > If that were the default, I wouldn't have so much difficulties. And > > surely others!, as I wrote. Why do large associations, businesses, > > others, never, almost never have unreadable pages?, never experiment > > with colors --such as, worth mentioning, some smaller, always only > > smaller entities, make pages in revert, white on black: which is almost > > never good, unless you want to exclude readers... > > > > Pls. dillo devs, allow that color scheme. > > Thank you! > > Well, that's 2 votes for it... And we're at zero votes against, here...

April 12, 2015

website colors (Re: Secure: yes, Though Features Missing; and Bugs)

by eocene＠gmx.com

Miroslav wrote: > On Sat, Apr 04, 2015 at 05:24:46AM +0000, eocene wrote: > > A couple of years ago, I experimented with a different color scheme, but > > the other members of the core team weren't enthusiastic about it, so I > > never made the change. Example: http://www.dillo.org/test/dillo2.html > > > Pls, pls. dillo devs, allow that color scheme. > > If that were the default, I wouldn't have so much difficulties. And > surely others!, as I wrote. Why do large associations, businesses, > others, never, almost never have unreadable pages?, never experiment > with colors --such as, worth mentioning, some smaller, always only > smaller entities, make pages in revert, white on black: which is almost > never good, unless you want to exclude readers... > > Pls. dillo devs, allow that color scheme. > Thank you! Well, that's 2 votes for it...

April 5, 2015

Documentation fixes: autolinking

by onepoint＠starurchin.org

Sebastian Geerken wrote: > Sorry for the late response. > > On Sa, Apr 04, 2015, Jeremy Henty wrote: > > > > I wrote: > > > > > Jorge Arellano Cid wrote: > > > > > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > > > > > Three small patches that fix autolinking errors in the documentation. > > > > > The first two escape the autolinking syntax in a few places where it > > > > > was not intended to be a link. The third fixes a few places where a > > > > > link was intended but the autolink syntax was not quite right. > > > > > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > > > > > Comments are welcome. > > > > > > > > > > If these are OK I can push them myself as I have write permission. > > > > > (It's actually easier for me to do it myself because Mercurial Queues > > > > > does not notice when the remote repository has a patch that is > > > > > identical to a patch in its queue and generates spurious errors.) > > > > > > > > +1. > > > > > > > > Just not sure about the last one. I don't know whether it > > > > changes the intended semantic for human readers. > > > > > > I think it actually corrects the semantics. An initial '::' means > > > resolve the name in the top namespace, not the current one, but the > > > class names used in the docs are relative to dw/lout. So I think the > > > patch does the right thing. > > > > Bump! Is it OK for me to push these or is more discussion needed? > > Haven't yet tested them, but they look OK; so push them if they don't > break anything. OK, it is done. > As for "::" vs. "\ref": I added "::" to have a reference at all. I'm > not sure about the exact rules, but Doxygen seems to regard anything > containing "::" as reference. > > If "\ref" works, it looks cleaner IMO. I agree. Regards, Jeremy Henty

April 4, 2015

Documentation fixes: autolinking

by sgeerken＠dillo.org

Sorry for the late response. On Sa, Apr 04, 2015, Jeremy Henty wrote: > > I wrote: > > > Jorge Arellano Cid wrote: > > > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > > > Three small patches that fix autolinking errors in the documentation. > > > > The first two escape the autolinking syntax in a few places where it > > > > was not intended to be a link. The third fixes a few places where a > > > > link was intended but the autolink syntax was not quite right. > > > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > > > Comments are welcome. > > > > > > > > If these are OK I can push them myself as I have write permission. > > > > (It's actually easier for me to do it myself because Mercurial Queues > > > > does not notice when the remote repository has a patch that is > > > > identical to a patch in its queue and generates spurious errors.) > > > > > > +1. > > > > > > Just not sure about the last one. I don't know whether it > > > changes the intended semantic for human readers. > > > > I think it actually corrects the semantics. An initial '::' means > > resolve the name in the top namespace, not the current one, but the > > class names used in the docs are relative to dw/lout. So I think the > > patch does the right thing. > > Bump! Is it OK for me to push these or is more discussion needed? Haven't yet tested them, but they look OK; so push them if they don't break anything. As for "::" vs. "\ref": I added "::" to have a reference at all. I'm not sure about the exact rules, but Doxygen seems to regard anything containing "::" as reference. If "\ref" works, it looks cleaner IMO. Sebastian

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

On Sat, Apr 04, 2015 at 05:24:46AM +0000, eocene wrote: > Miroslav wrote: > > But, since I started about it here, let me explain. Look here, how my > > dillo brings pages to me currently: > > https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 > > and currently, download and open the mkv files... (So people reading > > later, open the, hopefully, webm files. That's how it was, talking to > > you in the future.) > > I don't think XFT is enabled in your FLTK. That would explain why you > aren't getting DejaVu Sans and the rest... > > > ##################################################################### > > The Homepage is particularly too hard to read for, I guess at least a > > non-insignificant though small percentage (no, not less than a small > > percentage number, it's not insignificant!) of visitors. The background > > must be very light. As soon as it is too dark, the font is not easily > > readable. > > ##################################################################### > > A couple of years ago, I experimented with a different color scheme, but > the other members of the core team weren't enthusiastic about it, so I > never made the change. Example: http://www.dillo.org/test/dillo2.html > Pls, pls. dillo devs, allow that color scheme. If that were the default, I wouldn't have so much difficulties. And surely others!, as I wrote. Why do large associations, businesses, others, never, almost never have unreadable pages?, never experiment with colors --such as, worth mentioning, some smaller, always only smaller entities, make pages in revert, white on black: which is almost never good, unless you want to exclude readers... Pls. dillo devs, allow that color scheme. Thank you! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by eocene＠gmx.com

Miroslav wrote: > But, since I started about it here, let me explain. Look here, how my > dillo brings pages to me currently: > https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 > and currently, download and open the mkv files... (So people reading > later, open the, hopefully, webm files. That's how it was, talking to > you in the future.) I don't think XFT is enabled in your FLTK. That would explain why you aren't getting DejaVu Sans and the rest... > ##################################################################### > The Homepage is particularly too hard to read for, I guess at least a > non-insignificant though small percentage (no, not less than a small > percentage number, it's not insignificant!) of visitors. The background > must be very light. As soon as it is too dark, the font is not easily > readable. > ##################################################################### A couple of years ago, I experimented with a different color scheme, but the other members of the core team weren't enthusiastic about it, so I never made the change. Example: http://www.dillo.org/test/dillo2.html

April 4, 2015

patch: provide a redirection-blocked page

by eocene＠gmx.com

I was in the mood to make the use of domainrc more pleasant. Having to check the terminal for redirection-denied MSGs is no fun, and sometimes I imagine that I'm the only person who uses it due to its...limited friendliness. Patch attached.

April 4, 2015

Documentation fixes: autolinking

by onepoint＠starurchin.org

I wrote: > Jorge Arellano Cid wrote: > > > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > > > Three small patches that fix autolinking errors in the documentation. > > > The first two escape the autolinking syntax in a few places where it > > > was not intended to be a link. The third fixes a few places where a > > > link was intended but the autolink syntax was not quite right. > > > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > > > Comments are welcome. > > > > > > If these are OK I can push them myself as I have write permission. > > > (It's actually easier for me to do it myself because Mercurial Queues > > > does not notice when the remote repository has a patch that is > > > identical to a patch in its queue and generates spurious errors.) > > > > +1. > > > > Just not sure about the last one. I don't know whether it > > changes the intended semantic for human readers. > > I think it actually corrects the semantics. An initial '::' means > resolve the name in the top namespace, not the current one, but the > class names used in the docs are relative to dw/lout. So I think the > patch does the right thing. Bump! Is it OK for me to push these or is more discussion needed? Regards, Jeremy Henty

April 4, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

( I already wrote this entire message, and only then noticed eocene didn't send this to dillo-dev but only to me. But I now have to, All written. Can't correct that now. ) On Fri, Apr 03, 2015 at 08:14:36PM +0000, eocene wrote: > miroslav.rovis1 wrote: > > ukrainian at uabox ~ $ Domain: Default accept. > > By the way, if you're interested in making your browsing more secure, > you could modify your domainrc file not to have 'accept' as its default > rule. Let me first reply to this message. I really wish to start viewing dillo more comfortably first, so this will wait. But, since I started about it here, let me explain. Look here, how my dillo brings pages to me currently: https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 and currently, download and open the mkv files... (So people reading later, open the, hopefully, webm files. That's how it was, talking to you in the future.) Those mkv files will, hopefully, soon be replaced with the HTML5 compliant webm files. So if opened those, that's how it shows currently. I was only able to use dillo after reverting my 1024x768 capable old monitor, to 800x600, in another display in X (:1.0 in, say, ffmpeg command line), else, I would have gone blind from effort to read. And I still have difficulty reading some of the pages. ##################################################################### The Homepage is particularly too hard to read for, I guess at least a non-insignificant though small percentage (no, not less than a small percentage number, it's not insignificant!) of visitors. The background must be very light. As soon as it is too dark, the font is not easily readable. ##################################################################### I'm not at poor-accessibility eyesight yet, I don't have problems with most of pages. I really don't. Pls. take notice of this claim of mine and value the outlined paragraph with respect to that claim! I hope this will help dillo homepage become more readable. So, first I really need the fonts, and will follow your kind advice, eocene, on the fonts, as soon as I find more free time. domainrc is great thing to try to sort too, but the other issue is urgent. Pls allow more time for me to reply to your other mail (I got two mails of kind advice from eocene. Can't go online (the SourceForge archive) to see if my bad provider and bad regime filtered some emails out from dillo-dev. Busy elsewhere. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 3, 2015

Secure: yes, Though Features Missing; and Bugs

by eocene＠gmx.com

Miroslav wrote: > ukrainian at uabox /Cmn/mr $ fc-list : family | cut -d ',' -f 2 | sort | egrep 'DejaVu Sans|URW Chancery L|DejaVu Sans|DejaVu Sans Mono' > DejaVu Sans > DejaVu Sans Condensed > DejaVu Sans Light > DejaVu Sans Mono > URW Chancery L > ukrainian at uabox /Cmn/mr $ > ukrainian at uabox /Cmn/mr $ > > it's obvious that I got all the default fonts. > > And yet the fonts are not used by dillo for some reason. If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), remove the leading underscore in _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", to get MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", and recompile, what does dillo say when you run it?

April 3, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

( This message, if it arrives, will be placed almost correctly in the thread, thanks to Dennis having helped me previously, I have not received any of the messages from the list; it's the bad provider and regime. If this, or any later message of mine doesn't arrive to dillo-dev list, pls remember I promised I would post, what doesn't show publically at SourceForge, on Gentoo Forums, under: Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html around, or shortly after, the time that it would be expected at SourceForge. I apologize for this inconvenience. ) To show difficulties/buggish behavior/my lack of understanding (whatever the issue is, a bug or my ignorance), I'll start dillo from the command line: ukrainian at uabox ~ $ dillo & [2] 26348 ukrainian at uabox ~ $ Domain: Default accept. dillo_dns_init: Here we go! (threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Nav_open_url: new url='about:splash' And yet the fonts are there. I know I was able to find them. Have to remember how. Looking up: http://www.dillo.org/FAQ.html#q27 and pasting: Q: Why isn't Dillo3 finding the font that I set? fltk-1.3 is somewhat more restricted in its use of font names than fltk2 was. Please try the fc-list command as shown in the current dillorc configuration file to find the right form of the fontname to use. So, ukrainian at uabox ~ $ fc-list gives me too long list of fonts, I'll show it greeped for only DejaVu and URW, for brevity: ukrainian at uabox ~ $ fc-list | egrep 'URW|DejaVu' /usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold /usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic /usr/share/fonts/urw-fonts/p052004l.pfb: URW Palladio L:style=Bold /usr/share/fonts/urw-fonts/a010015l.pfb: URW Gothic L:style=Demi /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book /usr/share/fonts/urw-fonts/z003034l.pfb: URW Chancery L:style=Medium Italic /usr/share/fonts/urw-fonts/p052024l.pfb: URW Palladio L:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold /usr/share/fonts/urw-fonts/p052003l.pfb: URW Palladio L:style=Roman /usr/share/fonts/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/urw-fonts/p052023l.pfb: URW Palladio L:style=Italic /usr/share/fonts/urw-fonts/b018015l.pfb: URW Bookman L:style=Demi Bold /usr/share/fonts/urw-fonts/a010013l.pfb: URW Gothic L:style=Book /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic /usr/share/fonts/dejavu/DejaVuSerifCondensed-Bold.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold /usr/share/fonts/urw-fonts/b018012l.pfb: URW Bookman L:style=Light /usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed,Book /usr/share/fonts/urw-fonts/a010033l.pfb: URW Gothic L:style=Book Oblique /usr/share/fonts/urw-fonts/b018032l.pfb: URW Bookman L:style=Light Italic /usr/share/fonts/dejavu/DejaVuSerifCondensed-Italic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Italic,Italic /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book /usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf: DejaVu Sans,DejaVu Sans Light:style=ExtraLight /usr/share/fonts/urw-fonts/a010035l.pfb: URW Gothic L:style=Demi Oblique /usr/share/fonts/dejavu/DejaVuSansCondensed-BoldOblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold Oblique,Bold Oblique /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique /usr/share/fonts/urw-fonts/b018035l.pfb: URW Bookman L:style=Demi Bold Italic /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique In other words, the fonts that dillo complained it could not find, are there: If I look up in the ".dillo/dillorc #------------------------------------------------------------------------- # RENDERING SECTION #------------------------------------------------------------------------- # Default fonts: # # If FLTK has been configured with Xft enabled (the default), you can use # scalable fonts such as DejaVu or Liberation (try running # "fc-list : family | cut -d ',' -f 2 | sort"). #font_serif="DejaVu Serif" #font_sans_serif="DejaVu Sans" #font_cursive="URW Chancery L" #font_fantasy="DejaVu Sans" #font_monospace="DejaVu Sans Mono" # and run the suggested commands, except adding a little, to make shorter message/post, ukrainian at uabox /Cmn/mr $ fc-list : family | cut -d ',' -f 2 | sort | egrep 'DejaVu Sans|URW Chancery L|DejaVu Sans|DejaVu Sans Mono' DejaVu Sans DejaVu Sans Condensed DejaVu Sans Light DejaVu Sans Mono URW Chancery L ukrainian at uabox /Cmn/mr $ ukrainian at uabox /Cmn/mr $ it's obvious that I got all the default fonts. And yet the fonts are not used by dillo for some reason. For the current time, I think I exposed the issue. I don't have much idea what I am missing, or whether it this is actually a bug. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 3, 2015

unicode combining chars and PRE

by eocene＠gmx.com

Looking at http://doc.rust-lang.org/1.0.0-beta/book/more-strings.html#indexing-strings and I see that dillo doesn't like combining characters in PRE. Small example attached.

April 3, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

( I really got this message from Dennis, not from dillo, aah, what can you when the provider is bad... ) On Thu, Apr 02, 2015 at 10:51:13AM -0400, Dennis New wrote: > On Wed, 1 Apr 2015 22:35:13 +0200, miroslav.rovis1 at zg.ht.hr wrote: > > [...] > > The security of dillo is generally such that I can usually rest calmly > > when I browse with dillo. > > > > And so I can recommend dillo to anybody who has problems with > > censorship, and when censorship of an oppressive regime is revealed, > > usually some kind of intrusion attempts, and/or attacks, are made > > against the one who managed to reveal it. > > Agreed! It is incredibly valuable in this regard. It's minimalist > nature makes it far far more likely to be secure -- it presents a far > smaller "attack surface". (I think the lack of JavaScript support is a > feature, not a bug.) Yeah, except you need it often... (not everybody is FOSS oriented)... > > > [...] > > I've been having censorship and related issues for really quite a > > number of years, By this current stage in my necessity-imposed > > research about it, I'm just about always traffic capturing when > > online, and you can find real and undeniable clickjacking and other > > intrusions (and learn about the Chinese style censorship and more; > > Of course, the centralized state-controlled nature of the "normal > mainstream" internet makes this kind of censorship and hijacking > inevitable. If we realistically expect free speech we should be > migrating to censorship-proof darknets (like Tor or Freenet or I2P et > cetera) and perhaps decentralized hardware infrastructure like meshnets. I wish I was there already! Late adopter. What I have achieved: only through terribly extensive effort and time. > > [...] > > > Other then one thing. dillo, which I used, has a little problem with > > > cache, that can be easily circumvented, but the user needs to > > > remember to refresh the page, and I inadvertently lost a little > > > text... > > Yea that's happened to me a few times. Annoying. The input form will > use the originally filled field data, rather than the newer data, > unless the page is refreshed. Perhaps this is related to another > annoyance where, for example, after filling a form but incorrectly > guessing a captcha, there is no way to recover my original typed text. > (I've gotten into the habit of typing my posts in a separate text > editor to avoid this.) > > > [...] > > Zagreb, Croatia > > Cool city :). I see on http://dennisn.mooo.com/wiki/ you like some of our music. "Hladno pivo" are capable musicians, but ideologically I feel differently... Can't delve on this though. And I promised the other bug or similar that it were, of dillo. Not immediately. I'm slow. Pls. allow time. Cheers dear people! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 2, 2015

Secure: yes, Though Features Missing; and Bugs

by dennisn＠dennisn.mooo.com

On Wed, 1 Apr 2015 22:35:13 +0200, miroslav.rovis1 at zg.ht.hr wrote: > [...] > The security of dillo is generally such that I can usually rest calmly > when I browse with dillo. > > And so I can recommend dillo to anybody who has problems with > censorship, and when censorship of an oppressive regime is revealed, > usually some kind of intrusion attempts, and/or attacks, are made > against the one who managed to reveal it. Agreed! It is incredibly valuable in this regard. It's minimalist nature makes it far far more likely to be secure -- it presents a far smaller "attack surface". (I think the lack of JavaScript support is a feature, not a bug.) > [...] > I've been having censorship and related issues for really quite a > number of years, By this current stage in my necessity-imposed > research about it, I'm just about always traffic capturing when > online, and you can find real and undeniable clickjacking and other > intrusions (and learn about the Chinese style censorship and more; Of course, the centralized state-controlled nature of the "normal mainstream" internet makes this kind of censorship and hijacking inevitable. If we realistically expect free speech we should be migrating to censorship-proof darknets (like Tor or Freenet or I2P et cetera) and perhaps decentralized hardware infrastructure like meshnets. > [...] > > Other then one thing. dillo, which I used, has a little problem with > > cache, that can be easily circumvented, but the user needs to > > remember to refresh the page, and I inadvertently lost a little > > text... Yea that's happened to me a few times. Annoying. The input form will use the originally filled field data, rather than the newer data, unless the page is refreshed. Perhaps this is related to another annoyance where, for example, after filling a form but incorrectly guessing a captcha, there is no way to recover my original typed text. (I've gotten into the habit of typing my posts in a separate text editor to avoid this.) > [...] > Zagreb, Croatia Cool city :).

April 2, 2015

Secure: yes, Though Features Missing; and Bugs

by miroslav.rovis1＠zg.ht.hr

Hi! To me it is most important to avail myself of the security that dillo pretty much provides to me. What I can say, and recommend to anybody who has problems with `bulk collection' that they see in typical kind of actions deployed inside or on the way to, or on the way from, their machines... Sadly with `bulk collection' (previously known as `mass surveillance'; it comprises data harvesting and more) often go even worse kind of actions in privacy-repressive regimes: intrusions, even attacks... What I can say, is: I have so much fewer cases of the aforementioned issues when browsing with dillo, then I do when I have to, due to Javascript haven't yet been implemented in dillo, [than when I have to] use SchmoogleFox. So much fewer of those kind of problems! And yes, the Google, the Octopus of the Internet and the Surveillance Engine of the World, yes the Schmoog is sitting in the Firefox, in most of the regular users' machines who little depart from default configuration, and I don't think Mozilla harvesting itself can be easily disabled (you may remove direct Google harvesting/spying/other, but the Mozilla cloud is there, rest assured, for Google to use, fully!), and you can not, not that I know of an easy way --disprove me somebody!-- easily disable harvesting in Firefox... The security of dillo is generally such that I can usually rest calmly when I browse with dillo. And so I can recommend dillo to anybody who has problems with censorship, and when censorship of an oppressive regime is revealed, usually some kind of intrusion attempts, and/or attacks, are made against the one who managed to reveal it. To see more in depth about this claim of mine, read about dillo in the topics where I mention it on Gentoo Forums (just search for `dillo'): Updating and keeping your Gentoo non-poetterized https://forums.gentoo.org/viewtopic-t-1012022-start-0.html (currently three pages, dillo mentioned in 1st and 2nd. Before I close this first message, I'd like to show you this page where I demonstrated not just how the first Firefox harvest looks like on a Chinese style censorship deployed on dissenters in Croatia (that part is already posted: Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html#7715646 but that topic I plan to improve adn add more content to yet) You can see that while I'm not really a programmer, I dabble with some ideas. This is my proposal for a program: https://github.com/miroR/uncenz I've been having censorship and related issues for really quite a number of years, By this current stage in my necessity-imposed research about it, I'm just about always traffic capturing when online, and you can find real and undeniable clickjacking and other intrusions (and learn about the Chinese style censorship and more; but, WARNING, the presentation is not so well made, and is unfinished) at: Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion https://forums.gentoo.org/viewtopic-t-999436.html I believe that an objective reader, with a little time to read from my research there, can see that my praising of dillo is based on my sufficient understanding and experience. I really wish that you dillo developers may gather enough developer power to make dillo happen in the sooner rather than later future, much more capable than it already is. I can imagine what tremendous work creating and developing of a browser is! With that aim and wish in mind, I'd like to write and send another message about another buggish behavior in dillo. But in this message I can explain more about what I wrote on page 2nd of the topic already mentioned: Updating and keeping your Gentoo non-poetterized: https://forums.gentoo.org/viewtopic-t-1012022-start-25.html#7713858 > Other then one thing. dillo, which I used, has a little problem with > cache, that can be easily circumvented, but the user needs to remember > to refresh the page, and I inadvertently lost a little text... The above behavior occurs sometimes on my system, it occurs rather erratically, but rather often, when posting on Gentoo Forums. Not when posting a completely new post, but after editing an already existing post. It is easy to circumvent it, by simply, after having posted the previously edited post in question, refreshing the page which the post appears in. You can often see text literally changing upon refreshing it. The bug often occurs `in reverse', concerning posting. What I mean, is if you open a post for at least the third time --yes it must be a problem related to dillo caching; I understand so much even though I'm not a programmer, but just an advanced user-- so [if you open a post for the third time for editing], unless you refresh the editing texarea, in the same fashion: by clicking on the "Reload" button, you miight find yourself inadvertently to be editing the text that you posted the time before last, and not the immediately previous edit to this third edit of that text (even though the last text, the immediately previous, has, obviously, also been already committed, and should have been shown to you). The other bug, or is it my misconfiguration, or is it something else, I will try and write about in my next post. I sure will try and prepare the next message sson, and send it in a matter of hours or maximally a day or two. But if it does not arrive, the likelihood is that it is waiting for spies at my providers' to read it, and decide whether to send it on, or filter it out and not send it to dillo mailing list at all. Should the latter happen, pls. find that message at not much later time than maximally a day or two from now, in the topic Google - can not open any link - malware ?? https://forums.gentoo.org/viewtopic-t-912056-start-25.html surely, as a new post (which will, in that case, be yet to be written and posted there), and share the link with others on this list, please). (This note NOT related to dillo: Censorship is really a hard issue to overcome. Have a look at: Recover partly overwritten luks volume? https://forums.gentoo.org/viewtopic-t-1004014.html#7724054 --even though I praised dillo in that topic too-- nobody helped me there!) -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

April 1, 2015

Documentation fixes: autolinking

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > > > Three small patches that fix autolinking errors in the documentation. > > The first two escape the autolinking syntax in a few places where it > > was not intended to be a link. The third fixes a few places where a > > link was intended but the autolink syntax was not quite right. > > > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > > > Comments are welcome. > > > > If these are OK I can push them myself as I have write permission. > > (It's actually easier for me to do it myself because Mercurial Queues > > does not notice when the remote repository has a patch that is > > identical to a patch in its queue and generates spurious errors.) > > +1. > > Just not sure about the last one. I don't know whether it > changes the intended semantic for human readers. I think it actually corrects the semantics. An initial '::' means resolve the name in the top namespace, not the current one, but the class names used in the docs are relative to dw/lout. So I think the patch does the right thing. Regards, Jeremy Henty

March 21, 2015

Documentation fixes: autolinking

by jcid＠dillo.org

On Mon, Mar 16, 2015 at 03:28:43PM +0000, Jeremy Henty wrote: > > Three small patches that fix autolinking errors in the documentation. > The first two escape the autolinking syntax in a few places where it > was not intended to be a link. The third fixes a few places where a > link was intended but the autolink syntax was not quite right. > > http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html > http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html > http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html > > Comments are welcome. > > If these are OK I can push them myself as I have write permission. > (It's actually easier for me to do it myself because Mercurial Queues > does not notice when the remote repository has a patch that is > identical to a patch in its queue and generates spurious errors.) +1. Just not sure about the last one. I don't know whether it changes the intended semantic for human readers. -- Cheers Jorge.-

March 16, 2015

Documentation fixes: autolinking

by onepoint＠starurchin.org

Three small patches that fix autolinking errors in the documentation. The first two escape the autolinking syntax in a few places where it was not intended to be a link. The third fixes a few places where a link was intended but the autolink syntax was not quite right. http://starurchin.org/dillo/patch/doxygen-escape-hash-characters.html http://starurchin.org/dillo/patch/doxygen-escape-double-colons.html http://starurchin.org/dillo/patch/doxygen-fix-simple-name-refs.html Comments are welcome. If these are OK I can push them myself as I have write permission. (It's actually easier for me to do it myself because Mercurial Queues does not notice when the remote repository has a patch that is identical to a patch in its queue and generates spurious errors.) Regards, Jeremy Henty

March 16, 2015

Documentation fixes

by jcid＠dillo.org

On Thu, Mar 12, 2015 at 09:44:53PM +0100, Sebastian Geerken wrote: > On Mi, M?r 11, 2015, Jorge Arellano Cid wrote: > > On Wed, Mar 11, 2015 at 03:50:42PM +0000, Jeremy Henty wrote: > > > I have four documentation patches ready for review that came from > > > looking at the doxygen error output. The first is the upgrade to > > > Doxyfile, the other three are small fixes to errors that doxygen > > > happened to notice. I hope the extended descriptions will make > > > everything clear. > > > > > > http://starurchin.org/dillo/patch/doxygen-upgrade-config.html > > > http://starurchin.org/dillo/patch/doxygen-remove-unmatched-close-div.html > > > http://starurchin.org/dillo/patch/doxygen-typo-nsbp-entity.html > > > http://starurchin.org/dillo/patch/doxygen-escape-button-tag-angle-brackets.… > > > > > > There is more to do but I'd like to clear these out of the way first. > > > > > > All comments are welcome. > > > > Thank you vey much Jeremy! > > > > +1 > > > > I'd apply them now but am unsure only about the first. > > Let's see what Sebastian thinks of this bunch. > > I've committed and pushed them all. > > As for the first patch, this is a simple update. I'm running version > 1.8.1.2, but Jeremy's update with version 1.8.9.1, which adds some > more options, does not cause problems for me. Thanks Sebastian. That was the point, exactly. -- Cheers Jorge.-

March 12, 2015

Documentation fixes

by sgeerken＠dillo.org

On Mi, M?r 11, 2015, Jorge Arellano Cid wrote: > On Wed, Mar 11, 2015 at 03:50:42PM +0000, Jeremy Henty wrote: > > I have four documentation patches ready for review that came from > > looking at the doxygen error output. The first is the upgrade to > > Doxyfile, the other three are small fixes to errors that doxygen > > happened to notice. I hope the extended descriptions will make > > everything clear. > > > > http://starurchin.org/dillo/patch/doxygen-upgrade-config.html > > http://starurchin.org/dillo/patch/doxygen-remove-unmatched-close-div.html > > http://starurchin.org/dillo/patch/doxygen-typo-nsbp-entity.html > > http://starurchin.org/dillo/patch/doxygen-escape-button-tag-angle-brackets.… > > > > There is more to do but I'd like to clear these out of the way first. > > > > All comments are welcome. > > Thank you vey much Jeremy! > > +1 > > I'd apply them now but am unsure only about the first. > Let's see what Sebastian thinks of this bunch. I've committed and pushed them all. As for the first patch, this is a simple update. I'm running version 1.8.1.2, but Jeremy's update with version 1.8.9.1, which adds some more options, does not cause problems for me. Sebastian

March 12, 2015

Documentation fixes

by jcid＠dillo.org

On Wed, Mar 11, 2015 at 03:50:42PM +0000, Jeremy Henty wrote: > > I have four documentation patches ready for review that came from > looking at the doxygen error output. The first is the upgrade to > Doxyfile, the other three are small fixes to errors that doxygen > happened to notice. I hope the extended descriptions will make > everything clear. > > http://starurchin.org/dillo/patch/doxygen-upgrade-config.html > http://starurchin.org/dillo/patch/doxygen-remove-unmatched-close-div.html > http://starurchin.org/dillo/patch/doxygen-typo-nsbp-entity.html > http://starurchin.org/dillo/patch/doxygen-escape-button-tag-angle-brackets.… > > There is more to do but I'd like to clear these out of the way first. > > All comments are welcome. Thank you vey much Jeremy! +1 I'd apply them now but am unsure only about the first. Let's see what Sebastian thinks of this bunch. -- Cheers Jorge.-

March 11, 2015

Documentation fixes

by onepoint＠starurchin.org

I have four documentation patches ready for review that came from looking at the doxygen error output. The first is the upgrade to Doxyfile, the other three are small fixes to errors that doxygen happened to notice. I hope the extended descriptions will make everything clear. http://starurchin.org/dillo/patch/doxygen-upgrade-config.html http://starurchin.org/dillo/patch/doxygen-remove-unmatched-close-div.html http://starurchin.org/dillo/patch/doxygen-typo-nsbp-entity.html http://starurchin.org/dillo/patch/doxygen-escape-button-tag-angle-brackets.… There is more to do but I'd like to clear these out of the way first. All comments are welcome. Regards, Jeremy Henty

March 11, 2015

Problem with page positioning.

by james.from.wellington＠gmail.com

I kept thinking about this, and I think I have some unimplementable poetry for a correct behaviour, and some implementable prose that would do as a substitute. The poetry is: whatever the user is attending to: after the re-render, it should be in the same place on the screen. It's unimplementable because: - we don't know where in the rectangle the user is attending - different parts of the rectangle can move in different directions -- eg folding up navigation links into a side-bar - parts of the rectangle can be forced to move horizontally, in ways that we would not be able to cancel out with scrolling The prose is: however far the (top of the) page is displaced from the anchor position, after the re-render, the top of page should be displaced by the same amount from the new anchor position. Do people think that this prose is a reasonable version of correctness? Regards, James. On 28/02/2015, James C <james.from.wellington at gmail.com> wrote: > Peripheral to the original issue, preserving smooth behavour of a form > across a re-render would be an interesting (possibly in a slightly > hair-pull way) problem. > > The content of fields, cursor position, and keystrokes received during > the re-render, would all have to be preserved. > > I'm not volunteering. > > Regards, > James. > > On 27/02/2015, John Found <johnfound at asm32.info> wrote: >> On Thu, 26 Feb 2015 22:34:45 +0100 >> Andreas Kemnade <andreas at kemnade.info> wrote: >> >>> So a blank screen is your preferred way to fill out forms or should I >>> rather wait some minutes before starting to work on the page? I do not >>> understand your logic. >> >> Waiting for the CSS prior to rendering the page, does not forbid >> switching >> CSS off, as you described. Both features can co-exists without any >> conflict. >> >> My logic is that if the CSS files loads so slow as you describe (I still >> think it is a very, very rare case that can not rule the whole design), >> it >> is not important whether the rendering will happen twice or once - the >> page >> still will be not usable at all and you will need to disable CSS in order >> to >> get some usability at all. Notice, that nothing changes for your >> mentioned >> site, but on the normal, fast web sites, the screen flicker will be >> removed >> at all. >> >> >> -- >> http://fresh.flatassembler.net >> http://asm32.info >> John Found <johnfound at asm32.info> >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

March 6, 2015

Dillo documentation delivered daily

by eocene＠gmx.com

Jeremy wrote: > My website is up again[1] Great! It's good to hear from you again... > and I have added a daily build of the Dillo > documentation (having noticed that the version on the Dillo site is > over a year old). > > HTML: http://starurchin.org/dillo/doc/html/index.html > tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz > > (Note that the tarball has moved from its old location.) Will update links. > Doxygen generates quite a few errors when building the docs. I would > like to fix them (if only to have less noise from my cron jobs). > Would the Dillo devs be interested in the patches? Even though I haven't been dealing with doxygen stuff myself, I would certainly presume so.

March 4, 2015

Dillo documentation delivered daily

by onepoint＠starurchin.org

My website is up again[1] and I have added a daily build of the Dillo documentation (having noticed that the version on the Dillo site is over a year old). HTML: http://starurchin.org/dillo/doc/html/index.html tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz (Note that the tarball has moved from its old location.) Doxygen generates quite a few errors when building the docs. I would like to fix them (if only to have less noise from my cron jobs). Would the Dillo devs be interested in the patches? Regards Jeremy Henty [1] Nginx spontaneously decided not to run until I tweaked its configuration. No idea why, but at least it is fixed.

March 4, 2015

a different lines->getRef() segfault

by james.from.wellington＠gmail.com

This page: http://www.3news.co.nz/nznews/fantasy-football-match-marks-christmas-truce-… reliably (under my conditions of delay) exercises the findLineIndexWhenAllocated assertion. On 22/01/2015, James C <james.from.wellington at gmail.com> wrote: > This, on commit 553bbaa, may be a dup or related. > > It was exercised by loading this: > http://www.inkcartridges.co.nz/brother-hl5350dn-laser-printer > > (On OSX 10.6.8, as is usual from me.) > > Regards, > James. > > =================== > > Assertion failed: (wasAllocated ()), function > findLineIndexWhenAllocated, file textblock.cc, line 1634. > > Program received signal SIGABRT, Aborted. > 0x00007fff82c490b6 in __kill () > (gdb) bt > #0 0x00007fff82c490b6 in __kill () > #1 0x00007fff82ce99f6 in abort () > #2 0x00007fff82cd69bc in __assert_rtn () > #3 0x00000001000647bc in dw::Textblock::findLineIndexWhenAllocated > (this=0x11dc7f200, y=0) at textblock.cc:1634 > #4 0x0000000100069a63 in dw::Textblock::draw (this=0x11dc7f200, > view=0x11dc7f7c0, area=0x7fff5fbfd3b0) at textblock.cc:1791 > #5 0x000000010008c4a9 in dw::core::Layout::draw (this=0x11dc7f9c0, > view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.cc:696 > #6 0x0000000100083ef1 in dw::core::Layout::expose (this=0x11dc7f9c0, > view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.hh:317 > #7 0x0000000100083652 in dw::fltk::FltkViewBase::draw > (this=0x11dc7f7c0, rect=0x7fff5fbfd510, > type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 > #8 0x0000000100083843 in dw::fltk::FltkViewBase::draw > (this=0x11dc7f7c0) at fltkviewbase.cc:126 > #9 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #10 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x11dc7f7c8) > at Fl_Group.cxx:773 > #11 0x0000000100074334 in dw::fltk::ui::ComplexButton::draw > (this=0x11dc7f710) at fltkcomplexbutton.cc:53 > #12 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #13 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x11dc7f710) > at Fl_Group.cxx:773 > #14 0x0000000100081e25 in dw::fltk::FltkWidgetView::drawFltkWidget > (this=0x102230a60, widget=0x11dc7f710, area=0x7fff5fbfd730) at > fltkviewbase.cc:731 > #15 0x000000010007a553 in dw::fltk::ui::FltkResource::draw > (this=0x11dc7f640, view=0x102230a60, area=0x7fff5fbfd730) at > fltkui.cc:230 > #16 0x000000010007eedb in > dw::fltk::ui::FltkSpecificResource<dw::core::ui::ComplexButtonResource>::draw > (this=0x11dc7f5e0, view=0x102230a60, area=0x7fff5fbfd730) at > fltkui.cc:329 > #17 0x0000000100099da0 in dw::core::ui::Embed::draw (this=0x11dc7fcc0, > view=0x102230a60, area=0x7fff5fbfd730) at ui.cc:137 > #18 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc7ed10, > line=0x11dc7ddd0, view=0x102230a60, area=0x7fff5fbfd860) at > textblock.cc:1569 > #19 0x0000000100069abd in dw::Textblock::draw (this=0x11dc7ed10, > view=0x102230a60, area=0x7fff5fbfd860) at textblock.cc:1799 > #20 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca0f10, > line=0x11dc7f0b0, view=0x102230a60, area=0x7fff5fbfd990) at > textblock.cc:1569 > #21 0x0000000100069abd in dw::Textblock::draw (this=0x11dca0f10, > view=0x102230a60, area=0x7fff5fbfd990) at textblock.cc:1799 > #22 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc4d460, > line=0x11dca1730, view=0x102230a60, area=0x7fff5fbfda90) at > textblock.cc:1569 > #23 0x0000000100069abd in dw::Textblock::draw (this=0x11dc4d460, > view=0x102230a60, area=0x7fff5fbfda90) at textblock.cc:1799 > #24 0x0000000100061446 in dw::Table::draw (this=0x11dc183f0, > view=0x102230a60, area=0x7fff5fbfdb20) at table.cc:383 > #25 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc17fd0, > line=0x11dca90e0, view=0x102230a60, area=0x7fff5fbfdc50) at > textblock.cc:1569 > #26 0x0000000100069abd in dw::Textblock::draw (this=0x11dc17fd0, > view=0x102230a60, area=0x7fff5fbfdc50) at textblock.cc:1799 > #27 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc48cf0, > line=0x10059c490, view=0x102230a60, area=0x7fff5fbfdd80) at > textblock.cc:1569 > #28 0x0000000100069abd in dw::Textblock::draw (this=0x11dc48cf0, > view=0x102230a60, area=0x7fff5fbfdd80) at textblock.cc:1799 > #29 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca8410, > line=0x10243a560, view=0x102230a60, area=0x7fff5fbfdeb0) at > textblock.cc:1569 > #30 0x0000000100069abd in dw::Textblock::draw (this=0x11dca8410, > view=0x102230a60, area=0x7fff5fbfdeb0) at textblock.cc:1799 > #31 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca7c70, > line=0x11dca8030, view=0x102230a60, area=0x7fff5fbfdfe0) at > textblock.cc:1569 > #32 0x0000000100069abd in dw::Textblock::draw (this=0x11dca7c70, > view=0x102230a60, area=0x7fff5fbfdfe0) at textblock.cc:1799 > #33 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca5e70, > line=0x11dca7e60, view=0x102230a60, area=0x7fff5fbfe0e0) at > textblock.cc:1569 > #34 0x0000000100069abd in dw::Textblock::draw (this=0x11dca5e70, > view=0x102230a60, area=0x7fff5fbfe0e0) at textblock.cc:1799 > #35 0x0000000100061446 in dw::Table::draw (this=0x11dcf4460, > view=0x102230a60, area=0x7fff5fbfe170) at table.cc:383 > #36 0x0000000100069738 in dw::Textblock::drawLine (this=0x10235e1c0, > line=0x11dc64c30, view=0x102230a60, area=0x7fff5fbfe2c0) at > textblock.cc:1569 > #37 0x0000000100069abd in dw::Textblock::draw (this=0x10235e1c0, > view=0x102230a60, area=0x7fff5fbfe2c0) at textblock.cc:1799 > #38 0x000000010008c4a9 in dw::core::Layout::draw (this=0x1022a7170, > view=0x102230a60, area=0x7fff5fbfe3b0) at layout.cc:696 > #39 0x0000000100083ef1 in dw::core::Layout::expose (this=0x1022a7170, > view=0x102230a60, area=0x7fff5fbfe3b0) at layout.hh:317 > #40 0x0000000100083652 in dw::fltk::FltkViewBase::draw > (this=0x102230a60, rect=0x7fff5fbfe420, > type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 > #41 0x0000000100083843 in dw::fltk::FltkViewBase::draw > (this=0x102230a60) at fltkviewbase.cc:126 > #42 0x0000000100084d53 in dw::fltk::FltkViewport::draw_area > (data=0x102230a60, x=0, y=44, w=1185, h=636) at fltkviewport.cc:187 > #43 0x0000000100084f63 in dw::fltk::FltkViewport::draw > (this=0x102230a60) at fltkviewport.cc:213 > #44 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #45 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x102230a68) > at Fl_Group.cxx:773 > #46 0x00000001000bd631 in Fl_Group::draw_children (this=0x10225a6a0) > at Fl_Group.cxx:728 > #47 0x00000001000bc529 in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 > #48 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x10225a6a0) > at Fl_Group.cxx:773 > #49 0x00000001000bc529 in Fl_Group::draw_child (this=<value > temporarily unavailable, due to optimizations>, widget=@0x10053c4a0) > at Fl_Group.cxx:772 > #50 0x00000001000bd631 in Fl_Group::draw_children (this=0x10053d9f0) > at Fl_Group.cxx:728 > #51 0x00000001000ddc40 in Fl_Window::draw (this=0x10053d9f0) at > Fl_Window_shape.cxx:369 > #52 0x00000001000a862e in Fl_X::flush (this=0x1024119a0) at > Fl_cocoa.mm:2499 > #53 0x00000001000a8703 in -[FLView drawRect:] (self=0x102214ea0, > _cmd=<value temporarily unavailable, due to optimizations>, > rect={origin = {x = 0, y = 0}, size = {width = 1200, height = 700}}) > at Fl_cocoa.mm:2028 > #54 0x00007fff8901acc5 in -[NSView _drawRect:clip:] () > #55 0x00007fff89019938 in -[NSView > _recursiveDisplayAllDirtyWithLockFocus:visRect:] () > #56 0x00007fff8901800a in -[NSView > _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] > () > #57 0x00007fff890143de in -[NSView > _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] > () > #58 0x00007fff8918ee77 in -[NSView displayIfNeededIgnoringOpacity] () > #59 0x00000001000a8685 in Fl_X::flush (this=0x1024119a0) at > Fl_cocoa.mm:2509 > #60 0x00000001000aff1f in Fl_Widget::clear_damage () at > /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:762 > #61 0x00000001000aff1f in Fl::flush () at Fl.cxx:762 > #62 0x00000001000ad23c in fl_mac_flush_and_wait (time_to_wait=0) at > Fl_cocoa.mm:812 > #63 0x00000001000b0025 in Fl::run () at Fl.cxx:589 > #64 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at > dillo.cc:588 > (gdb) > > > On 20/01/2015, eocene <eocene at gmx.com> wrote: >> >> A new page was just coming in -- seems like the same sort of problem as >> last time. >> >> (gdb) bt >> #0 0xb77bb424 in __kernel_vsyscall () >> #1 0xb72f9661 in *__GI_raise (sig=6) >> at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 >> #2 0xb72fca92 in *__GI_abort () at abort.c:92 >> #3 0xb72f2878 in *__GI___assert_fail ( >> assertion=0x8151afe "i >= 0 && this->num - i > 0", >> file=0x8151aee "../lout/misc.hh", line=167, >> function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const >> [with T = dw::Textblock::Line]") at assert.c:81 >> #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( >> this=0x953b618, i=-1) at ../lout/misc.hh:167 >> #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, >> eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) >> at textblock.cc:1093 >> #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, >> event=0xbfbb8180) at textblock.cc:1008 >> #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, >> event=0xbfbb8180) at widget.cc:1027 >> #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, >> event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at >> layout.cc:1234 >> #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, >> type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, >> x=127, y=180, state=0, button=1) at layout.cc:1023 >> #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, >> view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) >> at layout.hh:345 >> #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, >> event=2) >> at fltkviewbase.cc:319 >> #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, >> event=2) >> at fltkviewport.cc:331 >> #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () >> #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () >> #15 0x080dff0e in Fl::handle(int, Fl_Window*) () >> #16 0x08107e9d in fl_handle(_XEvent const&) () >> #17 0x08107fbc in do_queued_events() () >> #18 0x0810822a in fl_wait(double) () >> #19 0x080e08af in Fl::wait(double) () >> #20 0x080e099d in Fl::run() () >> #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588 >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

March 2, 2015

what's currently broken in dillo

by james.from.wellington＠gmail.com

I'm not sure when it started, but I'm getting this: [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe [cookies dpi]: (pid 27897): Got DpiBye. [cookies dpi]: Cookies saved: 0. [cookies dpi]: cleanup [dpid]: terminated normally (0) with no obvious preamble. I'm running the hack-up that I sent to the list, with a new parser for dpidrc, which prevents it from timing out on the normal time-scale. Regards, James. On 15/02/2015, eocene <eocene at gmx.com> wrote: > > from my notes. I think all of this was mentioned on list: > > > --local ... reload turns off URL_SpamSafe, but there it is again upon > repush. > > >> I found that shift+arrows in the url bar is doing nothing instead >> of selecting the text. Ctrl+shift+arrows work fine. > > > dd search url not removed when dillorc has search urls. > > > background image oddities Jan 15 > > > jan 17 edge.org page > > > parbreak issue > > > another lines->getRef segfault > > > Jorge's slashdot hang > > > the interlaced gif on forum.thinkpads.com > > > feb 10 news.sciencemag.org hangs > > > As for speed, I'd spent enough time with dillo being pretty slow before > those optimizations were made in the past month or two that I've somewhat > lost my feel for how fast dillo is supposed to be... > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2015

Problem with page positioning.

by james.from.wellington＠gmail.com

Peripheral to the original issue, preserving smooth behavour of a form across a re-render would be an interesting (possibly in a slightly hair-pull way) problem. The content of fields, cursor position, and keystrokes received during the re-render, would all have to be preserved. I'm not volunteering. Regards, James. On 27/02/2015, John Found <johnfound at asm32.info> wrote: > On Thu, 26 Feb 2015 22:34:45 +0100 > Andreas Kemnade <andreas at kemnade.info> wrote: > >> So a blank screen is your preferred way to fill out forms or should I >> rather wait some minutes before starting to work on the page? I do not >> understand your logic. > > Waiting for the CSS prior to rendering the page, does not forbid switching > CSS off, as you described. Both features can co-exists without any > conflict. > > My logic is that if the CSS files loads so slow as you describe (I still > think it is a very, very rare case that can not rule the whole design), it > is not important whether the rendering will happen twice or once - the page > still will be not usable at all and you will need to disable CSS in order to > get some usability at all. Notice, that nothing changes for your mentioned > site, but on the normal, fast web sites, the screen flicker will be removed > at all. > > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 22:34:45 +0100 Andreas Kemnade <andreas at kemnade.info> wrote: > So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic. Waiting for the CSS prior to rendering the page, does not forbid switching CSS off, as you described. Both features can co-exists without any conflict. My logic is that if the CSS files loads so slow as you describe (I still think it is a very, very rare case that can not rule the whole design), it is not important whether the rendering will happen twice or once - the page still will be not usable at all and you will need to disable CSS in order to get some usability at all. Notice, that nothing changes for your mentioned site, but on the normal, fast web sites, the screen flicker will be removed at all. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015

Problem with page positioning.

by eocene＠gmx.com

Andreas wrote: > Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour? Here's the relevant thread: http://lists.dillo.org/pipermail/dillo-dev/2009-April/006310.html

Feb. 26, 2015

Problem with page positioning.

by andreas＠kemnade.info

Hi, On Thu, 26 Feb 2015 21:03:18 +0200 John Found <johnfound at asm32.info> wrote: > > well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. > > Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get Forms are disabled so that you cannot enter data when there is still css to load. So I have to disable CSS if I do not want to wait ages in theese cases. BTW: What was the reason for that behaviour? > loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering. So a blank screen is your preferred way to fill out forms or should I rather wait some minutes before starting to work on the page? I do not understand your logic. As you write in your other mail, some more intelligent solution might help, like wait 2 seconds and if css is not there, display what is displayable, so no flickering with good internet connection and no site problems. Greetings Andreas Kemnade

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 19:39:54 +0100 Andreas Kemnade <andreas at kemnade.info> wrote: > well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. Your logic is wrong here. If the current implementation is fine, you should not disable CSS, but you could work on these forms on the first rendered screen (without CSS) and to continue to work transparently when the page refreshes after the CSS get loaded. Your need to disable CSS proves exactly my theory: The first, fast, CSS-less rendering is useless at all and only provides screen flickering. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 15:09:15 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > Most probably remembering the scroll position for Back and Forward. Well, surprisingly not. I didn't tested extensively, but simply browsing several URLs and navigating forward/backward works fine and the page is positioned exactly where the page was left. > > Let's say you set the fail timeout to 30 seconds... Can you imagine it? > > Now if the page has let's say 7 stylesheets. Which compete with the main > page, and dozens of images for bandwith, add the "temporary unavailable" > answers, or simple fails that need a retry which some servers use to avoid bots > wasting BW, or peak usage hours, etc. Then, how many do we expect before > drawing? > > The point is: there're plenty of factors. > Well, yes there are plenty of factors. But IMHO, there are some arguments for the opposite: If the page is already received (at least partially) there is very big probability that the CSS files (if they are on the same web site) will be delivered successfully and approximately in the same time range. If this time is small enough, why not to wait a little in order to get better user experience (not flickering pages). There is some network performance limit, where rendering the page twice will be slower than waiting for the CSS files and rendering once. As long as with the time the network performance increases and with the Dillo supporting more and more HTML features, the rendering speed is expected to decrease, then this wait for the CSS files probably will be implemented one day. This way IMHO, some more complex logic (and probably some heuristics) could improve the overall performance. At least, this feature deserves dillorc option. :) > I'd like to look at it but currently work on a resize/redraw bugs fills > my time. > Take your time! You are doing great work in all cases. Best Regards. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015

Problem with page positioning.

by andreas＠kemnade.info

Hi, On Thu, 26 Feb 2015 18:53:54 +0200 John Found <johnfound at asm32.info> wrote: > On Thu, 26 Feb 2015 23:17:48 +1300 > James C <james.from.wellington at gmail.com> wrote: > > > If I was looking for a part of the code to blame, then my current pick is: > > "nav.c" line 303 > > and friends; possibly > > "nav.c" line 308 > > but I know that I don't have a taxonomy of all "repush"es, and how to > > determine that this is the one where that case should not apply :-) > > As I already said, my C/C++ skills are pretty low. But simply commenting out the lines 307 and 308 in "nav.c" and recompiling > I got the proper behaviour of the scrolling. > > The big question is what I have broke by this "solution"? :) > > Another question is why not to render the page only after the CSS files are received (or the receive failed)? Yes, it will slow down the first appearance of the page, but this first appearance is actually fairly useless for the most of the pages and only makes some flicker on the screen. > well, that depends on the situation and available bandwidth, In many cases I even disabled the css because I wanted to use some forms before css is loaded. I prefer the way it is now. Greetings Andreas Kemnade > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >

Feb. 26, 2015

Problem with page positioning.

by jcid＠dillo.org

On Thu, Feb 26, 2015 at 06:53:54PM +0200, John Found wrote: > On Thu, 26 Feb 2015 23:17:48 +1300 > James C <james.from.wellington at gmail.com> wrote: > > > If I was looking for a part of the code to blame, then my current pick is: > > "nav.c" line 303 > > and friends; possibly > > "nav.c" line 308 > > but I know that I don't have a taxonomy of all "repush"es, and how to > > determine that this is the one where that case should not apply :-) > > As I already said, my C/C++ skills are pretty low. But simply commenting out the lines 307 and 308 in "nav.c" and recompiling > I got the proper behaviour of the scrolling. > > The big question is what I have broke by this "solution"? :) Most probably remembering the scroll position for Back and Forward. Before CSS, there was only one scroll offset, now there may be many (as many as different stylesheets the page has. A ridiculously large number sometimes, I *must* add). > Another question is why not to render the page only after the CSS files are > received (or the receive failed)? Yes, it will slow down the first appearance > of the page, but this first appearance is actually fairly useless for the > most of the pages and only makes some flicker on the screen. Let's say you set the fail timeout to 30 seconds... Can you imagine it? Now if the page has let's say 7 stylesheets. Which compete with the main page, and dozens of images for bandwith, add the "temporary unavailable" answers, or simple fails that need a retry which some servers use to avoid bots wasting BW, or peak usage hours, etc. Then, how many do we expect before drawing? The point is: there're plenty of factors. Now, AFAIR, we've had a scroll-to-anchor-bug for a long time (another one which relates to a race condition while the canvas grows). This one looks simpler (may be the same though). I'd like to look at it but currently work on a resize/redraw bugs fills my time. -- Cheers Jorge.-

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

On Thu, 26 Feb 2015 23:17:48 +1300 James C <james.from.wellington at gmail.com> wrote: > If I was looking for a part of the code to blame, then my current pick is: > "nav.c" line 303 > and friends; possibly > "nav.c" line 308 > but I know that I don't have a taxonomy of all "repush"es, and how to > determine that this is the one where that case should not apply :-) As I already said, my C/C++ skills are pretty low. But simply commenting out the lines 307 and 308 in "nav.c" and recompiling I got the proper behaviour of the scrolling. The big question is what I have broke by this "solution"? :) Another question is why not to render the page only after the CSS files are received (or the receive failed)? Yes, it will slow down the first appearance of the page, but this first appearance is actually fairly useless for the most of the pages and only makes some flicker on the screen. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 26, 2015

Problem with page positioning.

by james.from.wellington＠gmail.com

Hi All, I can reproduce the reported behavior, with the reported test-case, with source up to change 986b7e7 I'm fairly sure that: - the page loads, and a scroll position is determined - the css loads, and the page is re-drawn -- wrongly, at the same scroll position, rather than at the scroll position that now matches the request I'm fairly sure that FRAGMENT is the part of the URL that contains a request to scroll to an anchor. If I was looking for a part of the code to blame, then my current pick is: "nav.c" line 303 and friends; possibly "nav.c" line 308 but I know that I don't have a taxonomy of all "repush"es, and how to determine that this is the one where that case should not apply :-) Regards, James. On 26/02/2015, John Found <johnfound at asm32.info> wrote: > Hi all. It is my first post on this mailing list. > > I want to use Dillo as a HTML help browser for my program. I need it, > because it has faster startup time and this is very important > for a help system, where the user presses F1 and expects the help to open > instantly. (What is not the case with all other browsers). > > Anyway, the problem I have is that when starting Dillo with URL that > contains local anchor ID, it first positions properly, but short time later, > (when the CSS get loaded?) it repositions the page and the needed element > moves somewhere else, very far from the current page position. > > Example that can be tested: > http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDo… > > Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking > on "Reload" button, repositions the page to the proper position. > > Is this problem can be easily solved? > I can try to fix it by myself, but my C/C++ skills are very low and then I > will need some assistance. > > Best Regards and thanks for the great browser. > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

Hi all. It is my first post on this mailing list. I want to use Dillo as a HTML help browser for my program. I need it, because it has faster startup time and this is very important for a help system, where the user presses F1 and expects the help to open instantly. (What is not the case with all other browsers). Anyway, the problem I have is that when starting Dillo with URL that contains local anchor ID, it first positions properly, but short time later, (when the CSS get loaded?) it repositions the page and the needed element moves somewhere else, very far from the current page position. Example that can be tested: http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDo… Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking on "Reload" button, repositions the page to the proper position. Is this problem can be easily solved? I can try to fix it by myself, but my C/C++ skills are very low and then I will need some assistance. Best Regards and thanks for the great browser. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 25, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On So, Feb 15, 2015, eocene wrote: > As for speed, I'd spent enough time with dillo being pretty slow before > those optimizations were made in the past month or two that I've somewhat > lost my feel for how fast dillo is supposed to be... I sometimes use time(1) to compare 3.0.4 and 3.1-dev, and as far as I remember, the differences are not significant. Of course, except for show stoppers (hanging (really taking too much time), CPU hoggig etc.), which should be regarded as plain bugs. Sebastian

Feb. 16, 2015

what's currently broken in dillo

by eocene＠gmx.com

from my notes. I think all of this was mentioned on list: --local ... reload turns off URL_SpamSafe, but there it is again upon repush. > I found that shift+arrows in the url bar is doing nothing instead > of selecting the text. Ctrl+shift+arrows work fine. dd search url not removed when dillorc has search urls. background image oddities Jan 15 jan 17 edge.org page parbreak issue another lines->getRef segfault Jorge's slashdot hang the interlaced gif on forum.thinkpads.com feb 10 news.sciencemag.org hangs As for speed, I'd spent enough time with dillo being pretty slow before those optimizations were made in the past month or two that I've somewhat lost my feel for how fast dillo is supposed to be...

Feb. 15, 2015

outofflowmgr.cc:1527: Assertion `yReq >= 0' failed.

by eocene＠gmx.com

outofflowmgr.cc:1527: void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int): Assertion `yReq >= 0' failed. At http://darwinday.org/events/ #0 0xb775e424 in __kernel_vsyscall () #1 0xb7083661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7086a92 in *__GI_abort () at abort.c:92 #3 0xb707c878 in *__GI___assert_fail (assertion=0x8158124 "yReq >= 0", file=0x8158073 "outofflowmgr.cc", line=1527, function=0x81584a0 "void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int)") at assert.c:81 #4 0x080b8016 in dw::OutOfFlowMgr::tellFloatPosition (this=0x844f5b0, widget= 0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1527 #5 0x080b7fdd in dw::OutOfFlowMgr::tellPosition (this=0x844f5b0, widget=0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1516 #6 0x080aed85 in dw::Textblock::wrapWordInFlow (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:788 #7 0x080ae8c0 in dw::Textblock::wordWrap (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:606 #8 0x080b1842 in dw::Textblock::showMissingLines (this=0x844ed10) at textblock_linebreaking.cc:2113 #9 0x080a431d in dw::Textblock::sizeRequestImpl (this=0x844ed10, requisition=0xbfeaa950) at textblock.cc:342 #10 0x080dafc0 in dw::core::Widget::sizeRequest (this=0x844ed10, requisition=0xbfeaa950) at widget.cc:494 #11 0x080b71c7 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x844f5b0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #12 0x080b67ae in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x844f5b0, caller=0x844ed10) at outofflowmgr.cc:651 #13 0x080a4e6b in dw::Textblock::sizeAllocateImpl (this=0x844ed10, allocation=0xbfeaab00) at textblock.cc:759 #14 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x844ed10, allocation=0xbfeaab00) at widget.cc:993 #15 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468b58, allocation=0xbfeaabf0) at textblock.cc:744 #16 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468b58, allocation=0xbfeaabf0) at widget.cc:993 #17 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468278, allocation=0xbfeaace0) at textblock.cc:744 #18 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468278, allocation=0xbfeaace0) at widget.cc:993 #19 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x89c7ed8, allocation=0xbfeaadd0) at textblock.cc:744 #20 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x89c7ed8, allocation=0xbfeaadd0) at widget.cc:993 #21 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8a04228, allocation=0xbfeaaeb0) at textblock.cc:744 #22 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8a04228, #23 0x080d0230 in dw::core::Layout::resizeIdle (this=0x83a3688) at layout.cc:912 #24 0x080be150 in dw::fltk::FltkPlatform::generalIdle (this=0x83946e0) at fltkplatform.cc:630 #25 0x080be0d8 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x83946e0) at fltkplatform.cc:620 #26 0x08106e5c in call_idle() () #27 0x080e3eb5 in Fl::wait(double) () #28 0x080e3ff5 in Fl::run() () #29 0x08053b6f in main (argc=2, argv=0xbfeab0d4) at dillo.cc:590

Feb. 12, 2015

page that hangs

by eocene＠gmx.com

news.sciencemag.org Under gdb, breaking in and having a look at the backtrace always showed a series of rewrap()... (gdb) bt #0 0x08051680 in mcount at plt () #1 0x080b753f in lout::object::TypedPointer<dw::Textblock>::~TypedPointer ( this=0xbfffedf4, __in_chrg=<optimized out>) at ../lout/object.hh:115 #2 0x080b5b36 in dw::OutOfFlowMgr::getTextblock (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.cc:1956 #3 0x080b6aa1 in dw::OutOfFlowMgr::getAllocation (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.hh:252 #4 0x080b288c in dw::OutOfFlowMgr::Float::ComparePosition::compare ( this=0xbfffef7c, o1=0xbfffef28, o2=0x83eb728) at outofflowmgr.cc:233 #5 0x080db204 in lout::container::untyped::Vector::bsearch (this=0x82466c8, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at container.cc:239 #6 0x080b6d8b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x82466b0, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at ../lout/container.hh:451 #7 0x080b2cba in dw::OutOfFlowMgr::SortedFloatsVector::find (this=0x82466b0, textblock=0x862f5e0, y=61080, start=0, end=5) at outofflowmgr.cc:385 #8 0x080b2d73 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst ( this=0x82466b0, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:432 #9 0x080b6069 in dw::OutOfFlowMgr::getFloatHeight (this=0x825aa00, textblock=0x862f5e0, side=dw::OutOfFlowMgr::LEFT, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2143 #10 0x080b5fc5 in dw::OutOfFlowMgr::getLeftFloatHeight (this=0x825aa00, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2125 #11 0x080ae637 in dw::Textblock::calcBorders (this=0x862f5e0, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2058 #12 0x080ac011 in dw::Textblock::balanceBreakPosAndHeight (this=0x862f5e0, wordIndex=0, firstIndex=0, searchUntil=0xbffff168, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0xbffff16f, wrapAll=false, diffWords=0xbffff170, wordIndexEnd=0xbffff164, lastFloatPos=0xbffff158, regardBorder=true, height=0xbffff160, breakPos=0xbffff15c) at textblock_linebreaking.cc:910 #13 0x080abc03 in dw::Textblock::wrapWordInFlow (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:746 #14 0x080ab87c in dw::Textblock::wordWrap (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #15 0x080ae17c in dw::Textblock::rewrap (this=0x862f5e0) at textblock_linebreaking.cc:1891 #16 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f5e0, requisition=0x8635f80) at textblock.cc:341 #17 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f5e0, requisition=0x8635f80) at widget.cc:494 #18 0x080ae159 in dw::Textblock::rewrap (this=0x862f098) at textblock_linebreaking.cc:1889 #19 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f098, requisition=0x862f370) at textblock.cc:341 #20 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f098, requisition=0x862f370) at widget.cc:494 #21 0x080ae159 in dw::Textblock::rewrap (this=0x862ea18) at textblock_linebreaking.cc:1889 #22 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862ea18, requisition=0x862ee18) at textblock.cc:341 #23 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862ea18, requisition=0x862ee18) at widget.cc:494 #24 0x080ae159 in dw::Textblock::rewrap (this=0x862b748) at textblock_linebreaking.cc:1889 #25 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b748, requisition=0x862b9f8) at textblock.cc:341 #26 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b748, requisition=0x862b9f8) at widget.cc:494 #27 0x080ae159 in dw::Textblock::rewrap (this=0x862b0a0) at textblock_linebreaking.cc:1889 #28 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b0a0, requisition=0x862b478) at textblock.cc:341 #29 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b0a0, requisition=0x862b478) at widget.cc:494 #30 0x080ae159 in dw::Textblock::rewrap (this=0x835e868) at textblock_linebreaking.cc:1889 #31 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x835e868, requisition=0x855357c) at textblock.cc:341 #32 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x835e868, requisition=0x855357c) at widget.cc:494 #33 0x080ae159 in dw::Textblock::rewrap (this=0x82846b8) at textblock_linebreaking.cc:1889 #34 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x82846b8, requisition=0xbffff750) at textblock.cc:341 #35 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x82846b8, requisition=0xbffff750) at widget.cc:494 #36 0x080b4183 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x825aa00, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #37 0x080b376a in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x825aa00, caller=0x82846b8) at outofflowmgr.cc:651 #38 0x080a1e27 in dw::Textblock::sizeAllocateImpl (this=0x82846b8, allocation=0xbffff8f0) at textblock.cc:759 #39 0x080d8e4f in dw::core::Widget::sizeAllocate (this=0x82846b8, allocation=0xbffff8f0) at widget.cc:993 #40 0x080cd1ec in dw::core::Layout::resizeIdle (this=0x81f2940) at layout.cc:912 #41 0x080bb10c in dw::fltk::FltkPlatform::generalIdle (this=0x81e2d38) at fltkplatform.cc:630 #42 0x080bb094 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x81e2d38) at fltkplatform.cc:620 #43 0x08103e18 in call_idle() () #44 0x080e0e71 in Fl::wait(double) () #45 0x080e0fb1 in Fl::run() () #46 0x08052f7a in main (argc=1, argv=0xbffffb14) at dillo.cc:588

Feb. 10, 2015

Core-dump pasting from one form field into another

by Johannes.Hofmann＠gmx.de

Hi James, On Sun, Feb 01, 2015 at 04:06:01PM +1300, James C wrote: > Hello Johannes et al, > > Unless circumstances intervene, a future release of FLTK will support > DND on OSX without RTTI:: > https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxj… thanks that you brought up the topic on the FLTK list! > > I vote for leaving DND disabled until the FLTK people are ready to > make that release. sure. Regards, Johannes > > Regards, > James. > > On 23/01/2015, James C <james.from.wellington at gmail.com> wrote: > > Hello Johannes et al, > > > > I've logged this with the FLTK people. > > http://www.fltk.org/str.php?L3178 > > > > Regards, > > James. > > > > On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > >> Hi James, > >> > >> On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: > >>> Hi All, > >>> > >>> I think I've worked out what's going on with drag-and-drop. > >>> > >>> We're compiling with -fno-rtti and (some parts of) fltk do > >>> dynamic_cast, which needs rtti. The run-time handling for detecting > >>> the conflict is nonexistent/unforgiving. > >>> > >>> When I make the change below and rebuild, drag-and-drop starts working > >>> for > >>> me. > >> > >> Cool that you found the reason! > >> From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work > >> without rtti, but things might have changed of course. > >> It would be cool if you could bring up the topic on an fltk list to > >> see if it's intended like this. > >> > >> Cheers, > >> Johannes > >> > >> _______________________________________________ > >> Dillo-dev mailing list > >> Dillo-dev at dillo.org > >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >> > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Feb. 2, 2015

Core-dump pasting from one form field into another

by james.from.wellington＠gmail.com

Hello Johannes et al, Unless circumstances intervene, a future release of FLTK will support DND on OSX without RTTI:: https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxj… I vote for leaving DND disabled until the FLTK people are ready to make that release. Regards, James. On 23/01/2015, James C <james.from.wellington at gmail.com> wrote: > Hello Johannes et al, > > I've logged this with the FLTK people. > http://www.fltk.org/str.php?L3178 > > Regards, > James. > > On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: >> Hi James, >> >> On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: >>> Hi All, >>> >>> I think I've worked out what's going on with drag-and-drop. >>> >>> We're compiling with -fno-rtti and (some parts of) fltk do >>> dynamic_cast, which needs rtti. The run-time handling for detecting >>> the conflict is nonexistent/unforgiving. >>> >>> When I make the change below and rebuild, drag-and-drop starts working >>> for >>> me. >> >> Cool that you found the reason! >> From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work >> without rtti, but things might have changed of course. >> It would be cool if you could bring up the topic on an fltk list to >> see if it's intended like this. >> >> Cheers, >> Johannes >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

Feb. 1, 2015

an interlaced gif doesn't finish drawing

by eocene＠gmx.com

I've consistently noticed that the image in the upper left corner of http://forum.thinkpads.com doesn't finish drawing initially. If I isolate the image or click to a second page, it'll show the whole thing properly.

Jan. 25, 2015

textarea placeholder [Re: form input placeholder text]

by eocene＠gmx.com

I wrote: > Everyone's getting into the habit of using the html5 > placeholder attributes on form inputs to tell users > what the inputs are for, decreasing usability for the > rest of us, so I implemented it for INPUT text/password. > (It's also legal on TEXTAREA.) Here's the code for textarea. I don't expect to commit this one as quickly, since textarea placeholder doesn't seem to be used as commonly. http://www.dillo.org/test/textarea_placeholder.diff

Jan. 24, 2015

Core-dump pasting from one form field into another

by james.from.wellington＠gmail.com

Hello Johannes et al, I've logged this with the FLTK people. http://www.fltk.org/str.php?L3178 Regards, James. On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > Hi James, > > On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: >> Hi All, >> >> I think I've worked out what's going on with drag-and-drop. >> >> We're compiling with -fno-rtti and (some parts of) fltk do >> dynamic_cast, which needs rtti. The run-time handling for detecting >> the conflict is nonexistent/unforgiving. >> >> When I make the change below and rebuild, drag-and-drop starts working for >> me. > > Cool that you found the reason! > From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work > without rtti, but things might have changed of course. > It would be cool if you could bring up the topic on an fltk list to > see if it's intended like this. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 23, 2015