- Dillo-dev - lists.mailman3.com

Google broke recently with 3.0.4 causing repush loop

by dennisn＠dennisn.mooo.com

This past week or so Google (main search site, image.google) broke for me -- Dillo (3.0.4) goes into an endless "repush" loop: Nav_open_url: new url='http://images.google.com/images?q=bra' Dns_server [0]: images.google.com is 96.127.250.44 96.127.250.42 96.127.250.38 96.127.250.34 96.127.250.30 96.127.250.29 96.127.250.27 96.127.250.23 96.127.250.19 96.127.250.15 96.127.250.59 96.127.250.57 96.127.250.53 96.127.250.49 96.127.250.45 2607:f8b0:4006:80f::200e Connecting to 96.127.250.44 Nav_open_url: new url='http://images.google.com/search?q=bra&tbm=isch' Connecting to 96.127.250.44 >>>> a_Nav_repush <<<< Nav_open_url: new url='http://images.google.com/search?q=bra&tbm=isch' a_Nav_expect_done: repush! Nav_open_url: new url='http://images.google.com/search?q=bra&ie=UTF-8&tbm=isch&gbv=1&sei=zkNNVd6sI…' Connecting to 96.127.250.44 >>>> a_Nav_repush <<<< Nav_open_url: new url='http://images.google.com/search?q=bra&ie=UTF-8&tbm=isch&gbv=1&sei=zkNNVd6sI…' a_Nav_expect_done: repush! Nav_open_url: new url='http://images.google.com/search?q=bra&ie=UTF-8&tbm=isch&gbv=1&sei=zkNNVYTpK…' Connecting to 96.127.250.44 >>>> a_Nav_repush <<<< ... and so on, extermely quickly, which then results in Google temporarily blocking me since Dillo is behaving like a DDOS attacker :s. Any idea what's causing these repush'es? I'm pretty sure nothing changed on my end. Other browsers work for me (eg. Links, Uzbl). Changing the User Agent had no effect.

May 9, 2015

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 13, 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