- Dillo-dev - lists.mailman3.com

SSL in the browser

by eocene＠gmx.com

I wrote: > 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... (Also the Tor + dpi issue that Johannes mentioned last year) Committed. I'm looking forward to seeing how it works for you...

May 9, 2015

Google broke recently with 3.0.4 causing repush loop

by eocene＠gmx.com

James wrote: > Here's a guess without justification: it's trying to get confirmation > that you accepted a cookie, and failing. I did make a quick attempt with accept_session in cookiesrc, and it didn't appear to make a difference... > The basis for my guess is that login to gmail is possible, but > requires more than five redirects, so I run a hacked up dillo 3.1, > with a dialog about whether to keep redirecting. How many redirects does it need? The only site that I tend to run into redirect problems with is nytimes.com (Not logging into any account; just looking at articles that people post links to...), and the last time I checked it was something like 12 redirects before it will give up and provide the page. And I wonder whether raising the redirect limit might be good, overall. Does gmail still need all of those redirects if you let it have a cookie?

May 9, 2015

Google broke recently with 3.0.4 causing repush loop

by eocene＠gmx.com

Dennis wrote: > 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. It looks like google is misbehaving. http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=whatever contains <noscript><meta content="0;url=/search?q=whatever&ie=UTF-8&oe=UTF-8&gbv=1&sei=sV5NVfbJMtfsoASOo4GQBw" http-equiv="refresh"><style>table,div,span,p{display:none}</style><div style="display:block">Please click <a href="/search?q=whatever&ie=UTF-8&oe=UTF-8&gbv=1&sei=sV5NVfbJMtfsoASOo4GQBw">here</a> if you are not redirected within a few seconds.</div></noscript> so we follow the refresh, and the new page has <noscript><meta content="0;url=/search?q=whatever&ie=UTF-8&gbv=1&sei=PV9NVej-Noj9oQSd-ICQDA" http-equiv="refresh"><style>table,div,span,p{display:none}</style><div style="display:block">Please click <a href="/search?q=whatever&ie=UTF-8&gbv=1&sei=PV9NVej-Noj9oQSd-ICQDA">here</a> if you are not redirected within a few seconds.</div></noscript> ...etc.... If I use a firefox user agent string, though, I am redirected from http to an https page which works and doesn't loop because...it puts the meta refresh down in the body instead of the head, so Dillo disallows it.

May 9, 2015

Google broke recently with 3.0.4 causing repush loop

by james.from.wellington＠gmail.com

Here's a guess without justification: it's trying to get confirmation that you accepted a cookie, and failing. The basis for my guess is that login to gmail is possible, but requires more than five redirects, so I run a hacked up dillo 3.1, with a dialog about whether to keep redirecting. On 09/05/2015, Dennis New <dennisn at dennisn.mooo.com> wrote: > 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. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

May 9, 2015

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