- Dillo-dev - lists.mailman3.com

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

>> I do get this message repeated many many times : >> >> Mar 1 17:55:52 dillo[4169] <Error>: CGContextSetShouldAntialias: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable. > > what Mac OS and FLTK version are you running and how did you install > FLTK. Also please set the environmental variable as suggested and > post the output. The you go. Mac OS 10.11.3 FLTK 1.1.3 installed through Macports Gandalf:.xinitrc.d yves$ export CG_CONTEXT_SHOW_BACKTRACE=yes Gandalf:.xinitrc.d yves$ dillo paths: Cannot open file '/Users/yves/.dillo/dillorc': No such file or directory paths: Using /opt/local/etc/dillo/dillorc paths: Cannot open file '/Users/yves/.dillo/keysrc': No such file or directory paths: Using /opt/local/etc/dillo/keysrc paths: Cannot open file '/Users/yves/.dillo/domainrc': No such file or directory paths: Using /opt/local/etc/dillo/domainrc 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' Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetTextPosition: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+11934> <_ZN8CustTabsC2EiiiPKc+33863> <_ZN8CustTabsC2EiiiPKc+42753> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+11934> <_ZN8CustTabsC2EiiiPKc+33863> <_ZN8CustTabsC2EiiiPKc+42753> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+11934> <_ZN8CustTabsC2EiiiPKc+33863> <_ZN8CustTabsC2EiiiPKc+42753> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetTextPosition: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetTextPosition: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetTextPosition: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> Mar 2 18:36:30 dillo[23010] <Error>: CGContextSetShouldAntialias: invalid context 0x0. Backtrace: <_Z15fl_text_extentsPKcRiS1_S1_S1_+80> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+1634> <_ZN2dw4fltk10FltkImgbuf11scaleBufferEPKhiiPhiiid+2707> <_ZN13CssStyleSheetC2Ev+16841> <_ZN13CssStyleSheetC2Ev+21235> <_ZN11DoctreeNodeD2Ev+13496> <_ZN11DoctreeNodeD2Ev+6209> <_ZN8CustTabsC2EiiiPKc+42885> <_ZN8CustTabsC2EiiiPKc+45551> <_ZL8do_timerP16__CFRunLoopTimerPv+42> <__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__+20> <__CFRunLoopDoTimer+1075> <__CFRunLoopDoTimers+298> <__CFRunLoopRun+1841> <CFRunLoopRunSpecific+296> <RunCurrentEventLoopInMode+235> <ReceiveNextEventCommon+184> <_BlockUntilNextEventMatchingListInModeWithFilter+71> <_DPSNextEvent+1067> <-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+454> <_Z7fl_waitd+150> <_Z21fl_mac_flush_and_waitd+155> <_ZN2Fl3runEv+19> <(null)+4361965094> <start+1> a_Dicache_cleanup: length = 0 Thanks yves

March 2, 2016

Double buffering flicker on window resize.

by johnfound＠asm32.info

On Wed, 2 Mar 2016 21:48:22 +0100 Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > > As buffered_drawing=2 uses Fl_Double_Window from FLTK which in turn > tries to use the Xorg DOUBLE-BUFFER extension, you might want to try > xdpyinfo | grep DOUBLE-BUFFER > to see if this extension is enabled on your system and either > disable or enable it in your xorg.conf to see if that makes a > difference. > DOUBLE-BUFFER extension is enabled and running on my system. I made some experiments disabling it in the config file and restarting X. Checked it's presence with "xdpyinfo | grep DOUBLE-BUFFER" and it was missing. Then the ugly flashing artifacts disappeared from Dillo and with buffered_drawing=2 the flickering still appears, visually similar to that of buffered_drawing=1, but much less intrusive. All tests are made by loading some page in the browser and then dragging the window edge in order to resize the window. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

March 2, 2016

Double buffering flicker on window resize.

by Johannes.Hofmann＠gmx.de

On Wed, Mar 02, 2016 at 06:41:21AM +0200, John Found wrote: > On Tue, 1 Mar 2016 22:54:34 +0100 > Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > > > with buffered_drawing=2 dillo uses the Fl_Double_Window class from > > FLTK, so the result should be similar to e.g. the test/fonts program > > from FLTK. Do you have it available and can test how that program > > feels when resizing on your system? > > In my setup I only get some light flickering at the scroll bars with > > buffered_drawing=2. Whereas I see heavy flickering with > > buffered_drawing=0. > > Do you see any difference between buffered_drawing=0 and > > buffered_drawing=2? > > > > Yes. These are different kind of flickering. On buffered_drawing=0 I see > how Dillo redraws the page content on the window surface. No artifacts, > only normal redraws one after another. On buffered_drawing=1 is > approximately the same but a little bit rarely. > > While on buffered_drawing=2, when the user resize the window, the whole window becomes > full of garbage - this is specific kind of garbage. It happens when you reuse some > memory previously used to store images with different sizes and then allocate it for > a new image and draw it on the screen as it is. A mess of graphical scanlines, > rectangles full of color, distorted images of different kind. > > Unfortunately, I can't get screenshot, because it is a dynamic effect. After stopping > resizing window, the last redraw is OK. As buffered_drawing=2 uses Fl_Double_Window from FLTK which in turn tries to use the Xorg DOUBLE-BUFFER extension, you might want to try xdpyinfo | grep DOUBLE-BUFFER to see if this extension is enabled on your system and either disable or enable it in your xorg.conf to see if that makes a difference.

March 2, 2016

Dill 3.0.5 breaks on Mac OS

by Johannes.Hofmann＠gmx.de

On Tue, Mar 01, 2016 at 05:57:41PM -0500, Yves de Champlain wrote: > Hi > > It does the trick indeed. good, I'll commit this change > > I do get this message repeated many many times : > > Mar 1 17:55:52 dillo[4169] <Error>: CGContextSetShouldAntialias: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable. what Mac OS and FLTK version are you running and how did you install FLTK. Also please set the environmental variable as suggested and post the output. Johannes > > Thanks > > yves > > > > > Le 28 f?vr. 2016 ? 04:17, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > > > could you please try with attached patch applied? > > > > Cheers, > > Johannes > > > > On Fri, Feb 26, 2016 at 08:58:36PM -0500, Yves de Champlain wrote: > >> Hi > >> > >> As I said in a subsequent mail, 3.0.4 does not work either anymore > >> > >> yves > >> > >> > >>> Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > >>> > >>> interesting. could you please try again if dillo-3.0.4 still works > >>> with your current setup? > >>> > >>> Cheers, > >>> Johannes > >>> > >>> On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: > >>>> I tried to send email about this very issue to this mailing list, but the > >>>> mail failed for some obscure reason. > >>>> > >>>> Thanks for bringing this up. > >>>> > >>>> Cheers > >>>> > >>>> - Martin - > >>>> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > >>>> > >>>>> Hi > >>>>> > >>>>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : > >>>>> > >>>>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > >>>>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > >>>>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > >>>>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > >>>>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > >>>>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > >>>>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > >>>>> xembed.cc > >>>>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > >>>>> mv -f .deps/image.Tpo .deps/image.Po > >>>>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > >>>>> mv -f .deps/form.Tpo .deps/form.Po > >>>>> mv -f .deps/findbar.Tpo .deps/findbar.Po > >>>>> mv -f .deps/menu.Tpo .deps/menu.Po > >>>>> In file included from xembed.cc:18: > >>>>> In file included from /opt/local/include/FL/x.H:43: > >>>>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > >>>>> not found > >>>>> # include "../src/Fl_Font.H" > >>>>> > >>>>> > >>>>> It seems that dillo is trying to use X but on Mac, but fltk is using > >>>>> quartz. > >>>>> > >>>>> The problem has been reported on many systems. > >>>>> > >>>>> Dillo 3.0.4 was working fine. > >>>>> > >>>>> Thanks > >>>>> > >>>>> yves > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> Dillo-dev mailing list > >>> Dillo-dev at dillo.org > >>> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >> > > > > > > <xembed_mac.diff>_______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

March 2, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call If this is indeed the same problem that apache, nginx, et al., are seeing, then the attached should suffice to fix it.

March 2, 2016

Double buffering flicker on window resize.

by johnfound＠asm32.info

On Tue, 1 Mar 2016 22:54:34 +0100 Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > with buffered_drawing=2 dillo uses the Fl_Double_Window class from > FLTK, so the result should be similar to e.g. the test/fonts program > from FLTK. Do you have it available and can test how that program > feels when resizing on your system? > In my setup I only get some light flickering at the scroll bars with > buffered_drawing=2. Whereas I see heavy flickering with > buffered_drawing=0. > Do you see any difference between buffered_drawing=0 and > buffered_drawing=2? > Yes. These are different kind of flickering. On buffered_drawing=0 I see how Dillo redraws the page content on the window surface. No artifacts, only normal redraws one after another. On buffered_drawing=1 is approximately the same but a little bit rarely. While on buffered_drawing=2, when the user resize the window, the whole window becomes full of garbage - this is specific kind of garbage. It happens when you reuse some memory previously used to store images with different sizes and then allocate it for a new image and draw it on the screen as it is. A mess of graphical scanlines, rectangles full of color, distorted images of different kind. Unfortunately, I can't get screenshot, because it is a dynamic effect. After stopping resizing window, the last redraw is OK. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

March 2, 2016

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

Hi It does the trick indeed. I do get this message repeated many many times : Mar 1 17:55:52 dillo[4169] <Error>: CGContextSetShouldAntialias: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable. Thanks yves > Le 28 f?vr. 2016 ? 04:17, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > could you please try with attached patch applied? > > Cheers, > Johannes > > On Fri, Feb 26, 2016 at 08:58:36PM -0500, Yves de Champlain wrote: >> Hi >> >> As I said in a subsequent mail, 3.0.4 does not work either anymore >> >> yves >> >> >>> Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : >>> >>> interesting. could you please try again if dillo-3.0.4 still works >>> with your current setup? >>> >>> Cheers, >>> Johannes >>> >>> On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: >>>> I tried to send email about this very issue to this mailing list, but the >>>> mail failed for some obscure reason. >>>> >>>> Thanks for bringing this up. >>>> >>>> Cheers >>>> >>>> - Martin - >>>> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: >>>> >>>>> Hi >>>>> >>>>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : >>>>> >>>>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. >>>>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' >>>>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include >>>>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include >>>>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE >>>>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti >>>>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o >>>>> xembed.cc >>>>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po >>>>> mv -f .deps/image.Tpo .deps/image.Po >>>>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po >>>>> mv -f .deps/form.Tpo .deps/form.Po >>>>> mv -f .deps/findbar.Tpo .deps/findbar.Po >>>>> mv -f .deps/menu.Tpo .deps/menu.Po >>>>> In file included from xembed.cc:18: >>>>> In file included from /opt/local/include/FL/x.H:43: >>>>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file >>>>> not found >>>>> # include "../src/Fl_Font.H" >>>>> >>>>> >>>>> It seems that dillo is trying to use X but on Mac, but fltk is using >>>>> quartz. >>>>> >>>>> The problem has been reported on many systems. >>>>> >>>>> Dillo 3.0.4 was working fine. >>>>> >>>>> Thanks >>>>> >>>>> yves >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> Dillo-dev mailing list >>> Dillo-dev at dillo.org >>> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> > > > <xembed_mac.diff>_______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

March 1, 2016

Double buffering flicker on window resize.

by Johannes.Hofmann＠gmx.de

Hi John, On Mon, Feb 29, 2016 at 09:16:03AM +0200, John Found wrote: > Hi, dillo developers! > > I observed another nasty bug in Dillo dev-3.1 > > Maybe it is known. If so, excuse my ignorance. :) > > When the option buffered_drawing=2 for double buffering and the browser window is resized > by the user, it seems that the back buffer is drawn on the screen too early after the reallocation and is full of garbage instead of the rendered page. > > This way, during the resizing, very heavy flicker appears, which IMHO is not good for double buffering drawing scheme. with buffered_drawing=2 dillo uses the Fl_Double_Window class from FLTK, so the result should be similar to e.g. the test/fonts program from FLTK. Do you have it available and can test how that program feels when resizing on your system? In my setup I only get some light flickering at the scroll bars with buffered_drawing=2. Whereas I see heavy flickering with buffered_drawing=0. Do you see any difference between buffered_drawing=0 and buffered_drawing=2? Cheers, Johannes

March 1, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Thu, Feb 25, 2016 at 09:19:22AM +0200, John Found wrote: > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call > At ssl_lib.c:2800 (Oops, I missed your reply!) Looking in the openssl source, that's just: int ssl_undefined_function(SSL *s) { SSLerr(SSL_F_SSL_UNDEFINED_FUNCTION, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED); return (0); } ...which is no surprise at all. I thought it might at least tell me which call was disliked.

March 1, 2016

New developer!

by jcid＠dillo.org

Hi there, I just wish to introduce you to Mr. Per Andersson, a senior developer with TCL/GTK/GCC/GDB backgrounds that's willing to help the project. @Per: if you want to introduce yourself to the list, here's a perfect spot. We've had some emails and he'll start working on debugging some problematic pages (I already sent him a though case), please try to answer any doubts or requests he may have during this period. TIA. -- Cheers Jorge.-

March 1, 2016

Double buffering flicker on window resize.

by johnfound＠asm32.info

Hi, dillo developers! I observed another nasty bug in Dillo dev-3.1 Maybe it is known. If so, excuse my ignorance. :) When the option buffered_drawing=2 for double buffering and the browser window is resized by the user, it seems that the back buffer is drawn on the screen too early after the reallocation and is full of garbage instead of the rendered page. This way, during the resizing, very heavy flicker appears, which IMHO is not good for double buffering drawing scheme. Best Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 29, 2016

Dill 3.0.5 breaks on Mac OS

by Johannes.Hofmann＠gmx.de

could you please try with attached patch applied? Cheers, Johannes On Fri, Feb 26, 2016 at 08:58:36PM -0500, Yves de Champlain wrote: > Hi > > As I said in a subsequent mail, 3.0.4 does not work either anymore > > yves > > > > Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > > > interesting. could you please try again if dillo-3.0.4 still works > > with your current setup? > > > > Cheers, > > Johannes > > > > On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: > >> I tried to send email about this very issue to this mailing list, but the > >> mail failed for some obscure reason. > >> > >> Thanks for bringing this up. > >> > >> Cheers > >> > >> - Martin - > >> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > >> > >>> Hi > >>> > >>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : > >>> > >>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > >>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > >>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > >>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > >>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > >>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > >>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > >>> xembed.cc > >>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > >>> mv -f .deps/image.Tpo .deps/image.Po > >>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > >>> mv -f .deps/form.Tpo .deps/form.Po > >>> mv -f .deps/findbar.Tpo .deps/findbar.Po > >>> mv -f .deps/menu.Tpo .deps/menu.Po > >>> In file included from xembed.cc:18: > >>> In file included from /opt/local/include/FL/x.H:43: > >>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > >>> not found > >>> # include "../src/Fl_Font.H" > >>> > >>> > >>> It seems that dillo is trying to use X but on Mac, but fltk is using > >>> quartz. > >>> > >>> The problem has been reported on many systems. > >>> > >>> Dillo 3.0.4 was working fine. > >>> > >>> Thanks > >>> > >>> yves > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 28, 2016

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

Hi As I said in a subsequent mail, 3.0.4 does not work either anymore yves > Le 26 f?vr. 2016 ? 06:00, Johannes Hofmann <Johannes.Hofmann at gmx.de> a ?crit : > > interesting. could you please try again if dillo-3.0.4 still works > with your current setup? > > Cheers, > Johannes > > On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: >> I tried to send email about this very issue to this mailing list, but the >> mail failed for some obscure reason. >> >> Thanks for bringing this up. >> >> Cheers >> >> - Martin - >> On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: >> >>> Hi >>> >>> When compiling dillo 3.0.5 on Mac OS 10.11, I get : >>> >>> /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. >>> -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' >>> -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include >>> -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include >>> -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE >>> -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti >>> -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o >>> xembed.cc >>> mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po >>> mv -f .deps/image.Tpo .deps/image.Po >>> mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po >>> mv -f .deps/form.Tpo .deps/form.Po >>> mv -f .deps/findbar.Tpo .deps/findbar.Po >>> mv -f .deps/menu.Tpo .deps/menu.Po >>> In file included from xembed.cc:18: >>> In file included from /opt/local/include/FL/x.H:43: >>> /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file >>> not found >>> # include "../src/Fl_Font.H" >>> >>> >>> It seems that dillo is trying to use X but on Mac, but fltk is using >>> quartz. >>> >>> The problem has been reported on many systems. >>> >>> Dillo 3.0.4 was working fine. >>> >>> Thanks >>> >>> yves >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Feb. 27, 2016

Solid rectangular placeholder for non-supported images

by jerome.borme＠gmail.com

Hello, I read a news flux where each news item comes with a small image. Dillo does not like the markup and replaces the image with a rectangular placeholder with a solid colour fill. This happens even when images loading is disabled (while other regular images are simply not displayed, but not replaced by a filled rectangle), and the colour fill seems to be randomly chosen at Dillo startup. I think this behaviour was not intentional. Right now the workaround is to not compile gif support. The placeholder is then replaced by the alt text, which I prefer to some brightly coloured rectangle. Version: Dillo 3.0.5 Page: http://www.lemonde.fr/actualite-en-continu/ Snippet: <img width="147" height="97" data-item-type="article" data-src="http://s2.lemde.fr/image/2016/02/26/147x97/4872606_7_843b_les-ministres-des…" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-lazyload="true" alt="Les ministres..." title="..." onload="lmd.pic(this);" onerror="lmd.pic(this);" class="lazy-retina"> Thanks, J?r?me

Feb. 26, 2016

Dill 3.0.5 breaks on Mac OS

by Johannes.Hofmann＠gmx.de

interesting. could you please try again if dillo-3.0.4 still works with your current setup? Cheers, Johannes On Fri, Feb 26, 2016 at 01:29:43PM +0300, Martin Atukunda wrote: > I tried to send email about this very issue to this mailing list, but the > mail failed for some obscure reason. > > Thanks for bringing this up. > > Cheers > > - Martin - > On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > > > Hi > > > > When compiling dillo 3.0.5 on Mac OS 10.11, I get : > > > > /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > > -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > > -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > > -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > > -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > > -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > > -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > > xembed.cc > > mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > > mv -f .deps/image.Tpo .deps/image.Po > > mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > > mv -f .deps/form.Tpo .deps/form.Po > > mv -f .deps/findbar.Tpo .deps/findbar.Po > > mv -f .deps/menu.Tpo .deps/menu.Po > > In file included from xembed.cc:18: > > In file included from /opt/local/include/FL/x.H:43: > > /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > > not found > > # include "../src/Fl_Font.H" > > > > > > It seems that dillo is trying to use X but on Mac, but fltk is using > > quartz. > > > > The problem has been reported on many systems. > > > > Dillo 3.0.4 was working fine. > > > > Thanks > > > > yves > > > > > > > > _______________________________________________ > > 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. 26, 2016

Dill 3.0.5 breaks on Mac OS

by matlads＠gmail.com

I tried to send email about this very issue to this mailing list, but the mail failed for some obscure reason. Thanks for bringing this up. Cheers - Martin - On 23 Feb 2016 23:12, "Yves de Champlain" <yesyves at gmail.com> wrote: > Hi > > When compiling dillo 3.0.5 on Mac OS 10.11, I get : > > /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. > -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' > -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include > -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include > -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE > -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti > -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o > xembed.cc > mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > mv -f .deps/image.Tpo .deps/image.Po > mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > mv -f .deps/form.Tpo .deps/form.Po > mv -f .deps/findbar.Tpo .deps/findbar.Po > mv -f .deps/menu.Tpo .deps/menu.Po > In file included from xembed.cc:18: > In file included from /opt/local/include/FL/x.H:43: > /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file > not found > # include "../src/Fl_Font.H" > > > It seems that dillo is trying to use X but on Mac, but fltk is using > quartz. > > The problem has been reported on many systems. > > Dillo 3.0.4 was working fine. > > Thanks > > yves > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 26, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Thu, Feb 25, 2016 at 08:49:20AM +0100, Andreas Kemnade wrote: > hmm, current dillo gives a lot of errors with valgrind with that site. > Maybe that is a point to look at. I'm not seeing them. They may be connected with: https://www.openssl.org/docs/faq.html#PROG14 14. Why does Valgrind complain about the use of uninitialized data? When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings.

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by andreas＠kemnade.info

Hi, On Wed, 2016-02-24 at 12:21 +0200, John Found wrote: > After this code inserted, the crash seems to be fixed. Mentioned MS site is loaded normally. > > Thanks! > hmm, current dillo gives a lot of errors with valgrind with that site. Maybe that is a point to look at. Regards, Andreas

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

Now it crashes again. The output messages are in the attached file. On Thu, 25 Feb 2016 05:21:06 +0000 eocene <eocene at gmx.com> wrote: > On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > > Oh, sorry. I was happy to have it work and forgot to report. :) > > Here is the dump from the error, down to the end: > > > > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call > > Ah, openssl makes so little effort toward anything. > I see that apache, nginx, etc. started to see lots of those messages with > openssl 1.0.2f, so I tried that version, and still no error messages for me. > (1.0.2f apparently becomes somewhat strict about shutdown during handshake, > whereas it seems earlier versions would just report success and not do > anything.) > > There is an ERR_get_error_line() function which might help. Diff attached. > The manpage didn't bother to go into any normal detail about the buffer it > wants for the filename argument, of course, but we'll see. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 25, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Wed, Feb 24, 2016 at 11:41:48PM +0200, John Found wrote: > Oh, sorry. I was happy to have it work and forgot to report. :) > Here is the dump from the error, down to the end: > > ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call Ah, openssl makes so little effort toward anything. I see that apache, nginx, etc. started to see lots of those messages with openssl 1.0.2f, so I tried that version, and still no error messages for me. (1.0.2f apparently becomes somewhat strict about shutdown during handshake, whereas it seems earlier versions would just report success and not do anything.) There is an ERR_get_error_line() function which might help. Diff attached. The manpage didn't bother to go into any normal detail about the buffer it wants for the filename argument, of course, but we'll see.

Feb. 25, 2016

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

Mmm I tried to build 3.0.4 and got the same error, but I?m sure it did work (a while ago) yves > Le 23 f?vr. 2016 ? 15:10, Yves de Champlain <yesyves at gmail.com> a ?crit : > > Hi > > When compiling dillo 3.0.5 on Mac OS 10.11, I get : > > /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o xembed.cc <http://xembed.cc/> > mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po > mv -f .deps/image.Tpo .deps/image.Po > mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po > mv -f .deps/form.Tpo .deps/form.Po > mv -f .deps/findbar.Tpo .deps/findbar.Po > mv -f .deps/menu.Tpo .deps/menu.Po > In file included from xembed.cc <http://xembed.cc/>:18: > In file included from /opt/local/include/FL/x.H:43: > /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file not found > # include "../src/Fl_Font.H" > > > It seems that dillo is trying to use X but on Mac, but fltk is using quartz. > > The problem has been reported on many systems. > > Dillo 3.0.4 was working fine. > > Thanks > > yves > >

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

On Wed, 24 Feb 2016 19:26:53 +0000 eocene <eocene at gmx.com> wrote: > On Wed, Feb 24, 2016 at 12:21:50PM +0200, John Found wrote: > > After this code inserted, the crash seems to be fixed. Mentioned MS site is loaded normally. > > What error did this code print out? > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev Oh, sorry. I was happy to have it work and forgot to report. :) Here is the dump from the error, down to the end: ** ERROR **: our TLS mystery error is: error:140C5042:SSL routines:ssl_undefined_function:called a function you should not call m.webtrends.com: TLSv1.2, cipher AES128-SHA sha256 2048-bit RSA: /C=US/ST=Oregon/L=Portland/O=WebTrends Inc./CN=m.webtrends.com sha256 2048-bit RSA: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K sha256 2048-bit RSA: /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2 root: /C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority a_Dicache_cleanup: length = 6 Best Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Wed, Feb 24, 2016 at 12:21:50PM +0200, John Found wrote: > After this code inserted, the crash seems to be fixed. Mentioned MS site is loaded normally. What error did this code print out?

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

After this code inserted, the crash seems to be fixed. Mentioned MS site is loaded normally. Thanks! On Wed, 24 Feb 2016 07:59:09 +0000 eocene <eocene at gmx.com> wrote: > On Tue, Feb 23, 2016 at 08:29:27PM +0200, John Found wrote: > > > > In short, Dillo crashes when I try to connect to the site of MS. It works ok on other > > https web sites, for example on https://google.com > > It doesn't want to trip the assert for me. What happens if you add something > like the following: > > diff -r 50d1c1aff6ae src/IO/tls.c > --- a/src/IO/tls.c Mon Jan 25 19:48:54 2016 +0100 > +++ b/src/IO/tls.c Tue Feb 23 23:08:06 2016 +0000 > @@ -1174,6 +1174,9 @@ > success = FALSE; > } > > + { int long e = ERR_get_error(); > + if (e) MSG_ERR("our TLS mystery error is: %s\n", ERR_error_string(e, NULL)); > + } > assert(!ERR_get_error()); > > if (success && !(ssl = SSL_new(ssl_context))) { > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by eocene＠gmx.com

On Tue, Feb 23, 2016 at 08:29:27PM +0200, John Found wrote: > > In short, Dillo crashes when I try to connect to the site of MS. It works ok on other > https web sites, for example on https://google.com It doesn't want to trip the assert for me. What happens if you add something like the following: diff -r 50d1c1aff6ae src/IO/tls.c --- a/src/IO/tls.c Mon Jan 25 19:48:54 2016 +0100 +++ b/src/IO/tls.c Tue Feb 23 23:08:06 2016 +0000 @@ -1174,6 +1174,9 @@ success = FALSE; } + { int long e = ERR_get_error(); + if (e) MSG_ERR("our TLS mystery error is: %s\n", ERR_error_string(e, NULL)); + } assert(!ERR_get_error()); if (success && !(ssl = SSL_new(ssl_context))) {

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by james.from.wellington＠gmail.com

Hello John, That's much earlier than the point where the fault becomes obvious. It's not completely clear that it's the same event. How would you feel about building openssl from source, with debug, in order for us to work out what it's complaining about? The other alternative, which I won't do instantly is: - find somewhere to stash some variables - finish the call to ERR_put_error - call ERR_get_error_line_data with the addresses of the stashed variables - print them and try to interpret the result The other other alternative is to find every place where an ERR_get_error* is called, and fix them so that they don't discard the output, but that's probably a big job. Regards, James. On 24/02/2016, John Found <johnfound at asm32.info> wrote: > On Wed, 24 Feb 2016 12:01:10 +1300 > James C <james.from.wellington at gmail.com> wrote: > >> Hello John, >> >> Thanks. >> >> On casual inspection, that seems very sad. It has failed, and seems >> to be trying to tell us that nothing is wrong. >> >> My next experiment is: >> gdb <the usual stuff> >> break ERR_put_error >> run >> bt 10 >> quit >> >> to try to prove, upstream, that there really was a complaint. > > Here is the output: > > gdb --args /usr/local/bin/dillo > "https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…" > GNU gdb (GDB) 7.10.1 > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-unknown-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/local/bin/dillo...done. > (gdb) break ERR_put_error > Function "ERR_put_error" not defined. > Make breakpoint pending on future shared library load? (y or [n]) y > Breakpoint 1 (ERR_put_error) pending. > (gdb) run > Starting program: /usr/local/bin/dillo > https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616\(v=vs.85\… > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > paths: Cannot open file '/home/johnfound/.dillo/keysrc': No such file or > directory > paths: Using /usr/local/etc/dillo/keysrc > paths: Cannot open file '/home/johnfound/.dillo/domainrc': No such file or > directory > paths: Using /usr/local/etc/dillo/domainrc > Domain: Default accept. > dillo_dns_init: Here we go! (threaded) > > Breakpoint 1, 0x00007ffff6ba9d90 in ERR_put_error () from > /usr/lib/libcrypto.so.1.0.0 > (gdb) bt 10 > #0 0x00007ffff6ba9d90 in ERR_put_error () from /usr/lib/libcrypto.so.1.0.0 > #1 0x00007ffff6be55c7 in PEM_read_bio () from /usr/lib/libcrypto.so.1.0.0 > #2 0x00007ffff6be38f6 in PEM_X509_INFO_read_bio () from > /usr/lib/libcrypto.so.1.0.0 > #3 0x00007ffff6bf5717 in X509_load_cert_crl_file () from > /usr/lib/libcrypto.so.1.0.0 > #4 0x00007ffff6bf583a in by_file_ctrl () from /usr/lib/libcrypto.so.1.0.0 > #5 0x000000000044684e in Tls_load_certificates () at tls.c:234 > #6 a_Tls_init () at tls.c:293 > #7 0x000000000040aadc in main (argc=2, argv=0x7fffffffe298) at > dillo.cc:481 > > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> >

Feb. 24, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

On Wed, 24 Feb 2016 12:01:10 +1300 James C <james.from.wellington at gmail.com> wrote: > Hello John, > > Thanks. > > On casual inspection, that seems very sad. It has failed, and seems > to be trying to tell us that nothing is wrong. > > My next experiment is: > gdb <the usual stuff> > break ERR_put_error > run > bt 10 > quit > > to try to prove, upstream, that there really was a complaint. Here is the output: gdb --args /usr/local/bin/dillo "https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…" GNU gdb (GDB) 7.10.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/bin/dillo...done. (gdb) break ERR_put_error Function "ERR_put_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (ERR_put_error) pending. (gdb) run Starting program: /usr/local/bin/dillo https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616\(v=vs.85\… [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". paths: Cannot open file '/home/johnfound/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/johnfound/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) Breakpoint 1, 0x00007ffff6ba9d90 in ERR_put_error () from /usr/lib/libcrypto.so.1.0.0 (gdb) bt 10 #0 0x00007ffff6ba9d90 in ERR_put_error () from /usr/lib/libcrypto.so.1.0.0 #1 0x00007ffff6be55c7 in PEM_read_bio () from /usr/lib/libcrypto.so.1.0.0 #2 0x00007ffff6be38f6 in PEM_X509_INFO_read_bio () from /usr/lib/libcrypto.so.1.0.0 #3 0x00007ffff6bf5717 in X509_load_cert_crl_file () from /usr/lib/libcrypto.so.1.0.0 #4 0x00007ffff6bf583a in by_file_ctrl () from /usr/lib/libcrypto.so.1.0.0 #5 0x000000000044684e in Tls_load_certificates () at tls.c:234 #6 a_Tls_init () at tls.c:293 #7 0x000000000040aadc in main (argc=2, argv=0x7fffffffe298) at dillo.cc:481 -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 23, 2016

Dillo crash on HTTPS connection (to MS web site)

by james.from.wellington＠gmail.com

Hello John, Thanks. On casual inspection, that seems very sad. It has failed, and seems to be trying to tell us that nothing is wrong. My next experiment is: gdb <the usual stuff> break ERR_put_error run bt 10 quit to try to prove, upstream, that there really was a complaint. Regards, James. On 24/02/2016, John Found <johnfound at asm32.info> wrote: > On Wed, 24 Feb 2016 10:34:00 +1300 > James C <james.from.wellington at gmail.com> wrote: > >> Hello John, >> >> I'm a bit better off, but not necessarily a lot. Unless someone takes >> this off me and instantly solves it, please presume that it's a long >> journey. >> >> I do not reproduce the problem. It may depend on the set of >> certificates on your machine, or something painful like that. >> >> I propose to attempt to give you a cookbook for driving gdb. You >> could try going >> which dillo > > Program received signal SIGABRT, Aborted. > 0x00007ffff5dfe3c8 in raise () from /usr/lib/libc.so.6 > (gdb) print ERR_peek_last_error() > $1 = 0 > (gdb) print /x ERR_peek_last_error() > $2 = 0x0 > (gdb) bt 10 > #0 0x00007ffff5dfe3c8 in raise () from /usr/lib/libc.so.6 > #1 0x00007ffff5dff84a in abort () from /usr/lib/libc.so.6 > #2 0x00007ffff5df72c7 in __assert_fail_base () from /usr/lib/libc.so.6 > #3 0x00007ffff5df7372 in __assert_fail () from /usr/lib/libc.so.6 > #4 0x0000000000447a01 in a_Tls_handshake (fd=7, url=0xb005f0) at > tls.c:1177 > #5 0x0000000000444e6b in Http_connect_tls (info=0xb00470) at http.c:512 > #6 Http_connect_socket (Info=0xb00470) at http.c:584 > #7 Http_connect_queued_sockets (srv=0xb00800) at http.c:275 > #8 0x0000000000445a6c in Http_get (Data1=0xaffa20, Info=0xb00470) > at http.c:742 > #9 a_Http_ccc (Op=<optimized out>, Branch=<optimized out>, > Dir=<optimized out>, Info=0xb00470, Data1=0xaffa20, Data2=0x0) > at http.c:833 > (More stack frames follow...) > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> >

Feb. 23, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

On Wed, 24 Feb 2016 10:34:00 +1300 James C <james.from.wellington at gmail.com> wrote: > Hello John, > > I'm a bit better off, but not necessarily a lot. Unless someone takes > this off me and instantly solves it, please presume that it's a long > journey. > > I do not reproduce the problem. It may depend on the set of > certificates on your machine, or something painful like that. > > I propose to attempt to give you a cookbook for driving gdb. You > could try going > which dillo Program received signal SIGABRT, Aborted. 0x00007ffff5dfe3c8 in raise () from /usr/lib/libc.so.6 (gdb) print ERR_peek_last_error() $1 = 0 (gdb) print /x ERR_peek_last_error() $2 = 0x0 (gdb) bt 10 #0 0x00007ffff5dfe3c8 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff5dff84a in abort () from /usr/lib/libc.so.6 #2 0x00007ffff5df72c7 in __assert_fail_base () from /usr/lib/libc.so.6 #3 0x00007ffff5df7372 in __assert_fail () from /usr/lib/libc.so.6 #4 0x0000000000447a01 in a_Tls_handshake (fd=7, url=0xb005f0) at tls.c:1177 #5 0x0000000000444e6b in Http_connect_tls (info=0xb00470) at http.c:512 #6 Http_connect_socket (Info=0xb00470) at http.c:584 #7 Http_connect_queued_sockets (srv=0xb00800) at http.c:275 #8 0x0000000000445a6c in Http_get (Data1=0xaffa20, Info=0xb00470) at http.c:742 #9 a_Http_ccc (Op=<optimized out>, Branch=<optimized out>, Dir=<optimized out>, Info=0xb00470, Data1=0xaffa20, Data2=0x0) at http.c:833 (More stack frames follow...) -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 23, 2016

Dillo crash on HTTPS connection (to MS web site)

by james.from.wellington＠gmail.com

Hello John, I'm a bit better off, but not necessarily a lot. Unless someone takes this off me and instantly solves it, please presume that it's a long journey. I do not reproduce the problem. It may depend on the set of certificates on your machine, or something painful like that. I propose to attempt to give you a cookbook for driving gdb. You could try going which dillo gdb <full path to dillo> <url that you had before> - should get a (gdb) prompt run - should give a message about your abourt - should get a (gdb) prompt print ERR_peek_last_error() - should show a number and a prompt print /x ERR_peek_last_error() - should show the same number in hex, and a prompt bt 10 - should get a stack trace quit - should get a shell prompt The numbers should be the same, modulo base, and may tell us something about the nature of the problem, after we do some decoding. Regards, James. On 24/02/2016, John Found <johnfound at asm32.info> wrote: > > I am not sure how to proceed, because my C/C++ programming skills are close > to zero. > But can make some debug effort if someone instructs me what to do. :) > > In short, Dillo crashes when I try to connect to the site of MS. It works ok > on other > https web sites, for example on https://google.com > > Dillo is compiled and run on 64bit ELF executable with SSL enabled. > > Here is what I have in the console: > > $dillo > "https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…" > ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" > value="(null)" > paths: Cannot open file '/home/johnfound/.dillo/keysrc': No such file or > directory > paths: Using /usr/local/etc/dillo/keysrc > paths: Cannot open file '/home/johnfound/.dillo/domainrc': No such file or > directory > paths: Using /usr/local/etc/dillo/domainrc > Domain: Default accept. > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > paths: Cannot open file '/home/johnfound/.dillo/hsts_preload': No such file > or directory > paths: Using /usr/local/etc/dillo/hsts_preload > ** WARNING **: preferred cursive font "URW Chancery L" not found. > Nav_open_url: new > url='https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…' > Dns_server [0]: msdn.microsoft.com is 157.56.148.19 > Connecting to 157.56.148.19:443 > msdn.microsoft.com: TLSv1.2, cipher DES-CBC3-SHA > sha256 2048-bit RSA: /CN=msdn.microsoft.com > sha256 4096-bit RSA: /C=US/ST=Washington/L=Redmond/O=Microsoft > Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2 > ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. > sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust > Root > root: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > NumPendingStyleSheets=1 > NumPendingStyleSheets=2 > Dns_server [1]: i-msdn.sec.s-msft.com is 2.16.221.31 > Dns_server [0]: assets.onestore.ms is 104.69.121.36 > Dns_server [0]: m.webtrends.com is 63.251.85.33 > i-msdn.sec.s-msft.com: TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384 > ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. > sha1 2048-bit RSA: /C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=STO > Operations/CN=*.sec.s-msft.com > ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. > sha1 2048-bit RSA: /C=NL/L=Amsterdam/O=Verizon Enterprise > Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA1 > ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. > sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust > Root > root: /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE > CyberTrust Global Root > assets.onestore.ms: TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384 > sha256 2048-bit RSA: /C=US/ST=WA/L=Redmond/O=Microsoft > Corporation/OU=Microsoft Corporation/CN=*.onestore.ms > sha256 4096-bit RSA: /C=US/ST=Washington/L=Redmond/O=Microsoft > Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2 > ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. > sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust > Root > root: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >>>>> a_Nav_repush <<<< > Reusing fd 8 for > https://assets.onestore.ms/cdnfiles/onestorerolling-1602-03000/shell/v3/ima… > Nav_open_url: new > url='https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…' > ABORT 1B > ABORT 1B > IO_write, closing with pending data not sent: "GET > /cdnfiles/onestorerolling-1602-03000/shell/v3/images/logo/microsoft.png > HTTP/1.1\x0D..." > a_Nav_expect_done: repush! > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > ** WARNING **: Ignoring unsafe author style that might reveal browsing > history > dillo: tls.c:1177: a_Tls_handshake: Assertion `!ERR_get_error()' failed. > Aborted (core dumped) > > > -- > 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. 23, 2016

Dill 3.0.5 breaks on Mac OS

by yesyves＠gmail.com

Hi When compiling dillo 3.0.5 on Mac OS 10.11, I get : /usr/bin/c++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/opt/local/etc/dillo/"' -DDILLO_DOCDIR='"/opt/local/share/doc/dillo/"' -I/opt/local/include -I/usr/local/include -I/opt/local/include/libpng16 -I/opt/local/include -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -pipe -Os -m64 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o xembed.cc mv -f .deps/dpiapi.Tpo .deps/dpiapi.Po mv -f .deps/image.Tpo .deps/image.Po mv -f .deps/imgbuf.Tpo .deps/imgbuf.Po mv -f .deps/form.Tpo .deps/form.Po mv -f .deps/findbar.Tpo .deps/findbar.Po mv -f .deps/menu.Tpo .deps/menu.Po In file included from xembed.cc:18: In file included from /opt/local/include/FL/x.H:43: /opt/local/include/FL/mac.H:104:12: fatal error: '../src/Fl_Font.H' file not found # include "../src/Fl_Font.H" It seems that dillo is trying to use X but on Mac, but fltk is using quartz. The problem has been reported on many systems. Dillo 3.0.4 was working fine. Thanks yves

Feb. 23, 2016

Dillo crash on HTTPS connection (to MS web site)

by johnfound＠asm32.info

I am not sure how to proceed, because my C/C++ programming skills are close to zero. But can make some debug effort if someone instructs me what to do. :) In short, Dillo crashes when I try to connect to the site of MS. It works ok on other https web sites, for example on https://google.com Dillo is compiled and run on 64bit ELF executable with SSL enabled. Here is what I have in the console: $dillo "https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…" ** ERROR **: prefsparser: Syntax error in dillorc: name="(null)" value="(null)" paths: Cannot open file '/home/johnfound/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/johnfound/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) Disabling cookies. paths: Cannot open file '/home/johnfound/.dillo/hsts_preload': No such file or directory paths: Using /usr/local/etc/dillo/hsts_preload ** WARNING **: preferred cursive font "URW Chancery L" not found. Nav_open_url: new url='https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…' Dns_server [0]: msdn.microsoft.com is 157.56.148.19 Connecting to 157.56.148.19:443 msdn.microsoft.com: TLSv1.2, cipher DES-CBC3-SHA sha256 2048-bit RSA: /CN=msdn.microsoft.com sha256 4096-bit RSA: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2 ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root root: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root NumPendingStyleSheets=1 NumPendingStyleSheets=2 Dns_server [1]: i-msdn.sec.s-msft.com is 2.16.221.31 Dns_server [0]: assets.onestore.ms is 104.69.121.36 Dns_server [0]: m.webtrends.com is 63.251.85.33 i-msdn.sec.s-msft.com: TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384 ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. sha1 2048-bit RSA: /C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=STO Operations/CN=*.sec.s-msft.com ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. sha1 2048-bit RSA: /C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA1 ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root root: /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root assets.onestore.ms: TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384 sha256 2048-bit RSA: /C=US/ST=WA/L=Redmond/O=Microsoft Corporation/OU=Microsoft Corporation/CN=*.onestore.ms sha256 4096-bit RSA: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT SSL SHA2 ** WARNING **: In 2015, browsers have begun to deprecate SHA1 certificates. sha1 2048-bit RSA: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root root: /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >>>> a_Nav_repush <<<< Reusing fd 8 for https://assets.onestore.ms/cdnfiles/onestorerolling-1602-03000/shell/v3/ima… Nav_open_url: new url='https://msdn.microsoft.com/en-us/library/windows/desktop/ms645616(v=vs.85).…' ABORT 1B ABORT 1B IO_write, closing with pending data not sent: "GET /cdnfiles/onestorerolling-1602-03000/shell/v3/images/logo/microsoft.png HTTP/1.1\x0D..." a_Nav_expect_done: repush! ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history ** WARNING **: Ignoring unsafe author style that might reveal browsing history dillo: tls.c:1177: a_Tls_handshake: Assertion `!ERR_get_error()' failed. Aborted (core dumped) -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 23, 2016

Problems with bookmarks.dpi

by johannes.hofmann＠gmx.de

On Mon, Jan 25, 2016 at 12:44:22AM +0100, Sebastian Geerken wrote: > On So, Jan 24, 2016, Johannes Hofmann wrote: > > there is probabely something in your bm.txt that the current code > > doesn't expect. > > I tried to make the bookmarks file parser a bit safer (see attached > > patch). Could you please try if it fixes your case? > > Thanks, it worked. First, the list was empty, but as soon as I > bookmarked another page, all links were displayed again. (I believe > the section line ":s0: ..." got damaged when editing the file > directly.) > > Do you want to commit it to hg.dillo.org? It this case, I'll simply > merge it into dillo_grows. I plan to commit it to the main repository tonight. > > Sebastian > > PS: Still one problem left: cookies.dpi hangs sometimes. > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 25, 2016

Problems with bookmarks.dpi

by sgeerken＠dillo.org

On So, Jan 24, 2016, Johannes Hofmann wrote: > there is probabely something in your bm.txt that the current code > doesn't expect. > I tried to make the bookmarks file parser a bit safer (see attached > patch). Could you please try if it fixes your case? Thanks, it worked. First, the list was empty, but as soon as I bookmarked another page, all links were displayed again. (I believe the section line ":s0: ..." got damaged when editing the file directly.) Do you want to commit it to hg.dillo.org? It this case, I'll simply merge it into dillo_grows. Sebastian PS: Still one problem left: cookies.dpi hangs sometimes.

Jan. 24, 2016

Problems with bookmarks.dpi

by Johannes.Hofmann＠gmx.de

Hi Sebastian, there is probabely something in your bm.txt that the current code doesn't expect. I tried to make the bookmarks file parser a bit safer (see attached patch). Could you please try if it fixes your case? Cheers, Johannes On Sat, Jan 23, 2016 at 03:08:31PM +0100, Sebastian Geerken wrote: > Hi! > > As I wrote in a previois post, bookmarks do not work. It seems that > bookmarks.dpi crashes: > > ---------------------------------------------------------------------- > $ gdb /usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi core > GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 > Copyright (C) 2014 Free Software Foundation, Inc. > [...] > Reading symbols from /usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi...done. > [New LWP 5661] > Core was generated by `/usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 Bms_load () at bookmarks.c:745 > 745 p = strchr(p, ' '); *p = 0; > (gdb) l > 740 if (buf[0] == 's') { > 741 /* get section, url and title */ > 742 section = strtol(buf + 1, NULL, 10); > 743 p = strchr(buf, ' '); *p = 0; > 744 url = ++p; > 745 p = strchr(p, ' '); *p = 0; > 746 title = ++p; > 747 p = strchr(p, '\n'); *p = 0; > 748 u_title = Unescape_html_str(title); > 749 Bms_add(section, url, u_title); > (gdb) p p > $1 = 0x1 <error: Cannot access memory at address 0x1> > (gdb) bt > #0 Bms_load () at bookmarks.c:745 > #1 Bms_cond_load () at bookmarks.c:792 > #2 Bmsrv_parse_token (Buf=0x1814280 "<cmd='open_url' url='dpi:/bm/' > '>", sh=0x1810200) at bookmarks.c:1605 > #3 main () at bookmarks.c:1746 > ---------------------------------------------------------------------- > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 24, 2016

Work on floats

by Johannes.Hofmann＠gmx.de

On Sat, Jan 23, 2016 at 02:45:31PM +0100, Sebastian Geerken wrote: > > On Sat, Jan 16, 2016 at 10:10:57PM +0100, Alexander Voigt wrote: > > > when I open my bookmarks site (dpi:/bm/) and move the mouse down over > > > some of my bookmark links, dillo crashes. I'm using commit > > > 4494:4f99dafc3e50. > > On Sa, Jan 16, 2016, Johannes Hofmann wrote: > > I can reproduce this with left mouse button pressed and moving > > around on bookmarks page. Here is my backtrace: > > > > 0x0000000800e07fc8 in kill () from /lib/libc.so.8 > > (gdb) bt > > #0 0x0000000800e07fc8 in kill () from /lib/libc.so.8 > > #1 0x0000000800868e89 in raise () from /usr/lib/libpthread.so.0 > > #2 0x0000000800e9b5f0 in abort () from /lib/libc.so.8 > > #3 0x00000000004276e3 in lout::misc::assertNotReached () at ../lout/misc.hh:38 > > #4 0x000000000044fde5 in dw::oof::OOFAwareWidget::getWidgetAtPointLevel ( > > this=<optimized out>, x=<optimized out>, y=<optimized out>, level=<optimized out>, > > context=<optimized out>) at oofawarewidget.cc:496 > > #5 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801051f00, x=548, > > y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 > > #6 0x0000000000460a3e in dw::Textblock::getWidgetAtPointLevel (this=0x801863d80, x=548, > > ---Type <return> to continue, or q <return> to quit--- > > , level=<optimized out>, context=0x7ffffffff000) at textblock.cc:2823 > > For strange reasons, bookmarks do not work for me (I'll start another > thread). However, most probably this bug has been just fixed. Please > test again. Cool, seems to be fixed! Johannes

Jan. 24, 2016

Dillo MS Windows Port

by rogerx.oss＠gmail.com

I spent some time last night examining the Dillo Windows port, as well as the DPLus version. The DPlus version has multiple patches for extra (likely not-needed?) features atop of the Windows port. So further limited my research to the Dillo Windows port to see what was only needed for Dillo to be functionally compiled on Windows platforms under Mingw. Performing a "diff -urN" on the Windows port against the vanilla Dillo-1.3.0, showed at the very end some stuff concerning socks.h/winsock2.h portability. There were other modifications, but not sure if those were really needed. Would appear they performed a lot of work, and it's sad to see the work just being ignored. Would be nice to see some basic portability for Windows integrated. However, basic and standardized work that is clean and can be integrated within the main Dillo tree. Would appear the DPlus version work went further with extra features, and can easily understand why they were likely not wanted within the main Dillo tree. -- Roger http://rogerx.freeshell.org/

Jan. 23, 2016

Problems with bookmarks.dpi

by sgeerken＠dillo.org

Hi! As I wrote in a previois post, bookmarks do not work. It seems that bookmarks.dpi crashes: ---------------------------------------------------------------------- $ gdb /usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. [...] Reading symbols from /usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi...done. [New LWP 5661] Core was generated by `/usr/local/lib/dillo/dpi/bookmarks/bookmarks.dpi'. Program terminated with signal SIGSEGV, Segmentation fault. #0 Bms_load () at bookmarks.c:745 745 p = strchr(p, ' '); *p = 0; (gdb) l 740 if (buf[0] == 's') { 741 /* get section, url and title */ 742 section = strtol(buf + 1, NULL, 10); 743 p = strchr(buf, ' '); *p = 0; 744 url = ++p; 745 p = strchr(p, ' '); *p = 0; 746 title = ++p; 747 p = strchr(p, '\n'); *p = 0; 748 u_title = Unescape_html_str(title); 749 Bms_add(section, url, u_title); (gdb) p p $1 = 0x1 <error: Cannot access memory at address 0x1> (gdb) bt #0 Bms_load () at bookmarks.c:745 #1 Bms_cond_load () at bookmarks.c:792 #2 Bmsrv_parse_token (Buf=0x1814280 "<cmd='open_url' url='dpi:/bm/' '>", sh=0x1810200) at bookmarks.c:1605 #3 main () at bookmarks.c:1746 ---------------------------------------------------------------------- Sebastian

Jan. 23, 2016

Work on floats

by sgeerken＠dillo.org

> On Sat, Jan 16, 2016 at 10:10:57PM +0100, Alexander Voigt wrote: > > when I open my bookmarks site (dpi:/bm/) and move the mouse down over > > some of my bookmark links, dillo crashes. I'm using commit > > 4494:4f99dafc3e50. On Sa, Jan 16, 2016, Johannes Hofmann wrote: > I can reproduce this with left mouse button pressed and moving > around on bookmarks page. Here is my backtrace: > > 0x0000000800e07fc8 in kill () from /lib/libc.so.8 > (gdb) bt > #0 0x0000000800e07fc8 in kill () from /lib/libc.so.8 > #1 0x0000000800868e89 in raise () from /usr/lib/libpthread.so.0 > #2 0x0000000800e9b5f0 in abort () from /lib/libc.so.8 > #3 0x00000000004276e3 in lout::misc::assertNotReached () at ../lout/misc.hh:38 > #4 0x000000000044fde5 in dw::oof::OOFAwareWidget::getWidgetAtPointLevel ( > this=<optimized out>, x=<optimized out>, y=<optimized out>, level=<optimized out>, > context=<optimized out>) at oofawarewidget.cc:496 > #5 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801051f00, x=548, > y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 > #6 0x0000000000460a3e in dw::Textblock::getWidgetAtPointLevel (this=0x801863d80, x=548, > ---Type <return> to continue, or q <return> to quit--- > , level=<optimized out>, context=0x7ffffffff000) at textblock.cc:2823 For strange reasons, bookmarks do not work for me (I'll start another thread). However, most probably this bug has been just fixed. Please test again. Sebastian

Jan. 23, 2016

Work on floats

by Johannes.Hofmann＠gmx.de

Hi, I can reproduce this with left mouse button pressed and moving around on bookmarks page. Here is my backtrace: 0x0000000800e07fc8 in kill () from /lib/libc.so.8 (gdb) bt #0 0x0000000800e07fc8 in kill () from /lib/libc.so.8 #1 0x0000000800868e89 in raise () from /usr/lib/libpthread.so.0 #2 0x0000000800e9b5f0 in abort () from /lib/libc.so.8 #3 0x00000000004276e3 in lout::misc::assertNotReached () at ../lout/misc.hh:38 #4 0x000000000044fde5 in dw::oof::OOFAwareWidget::getWidgetAtPointLevel ( this=<optimized out>, x=<optimized out>, y=<optimized out>, level=<optimized out>, context=<optimized out>) at oofawarewidget.cc:496 #5 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801051f00, x=548, y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 #6 0x0000000000460a3e in dw::Textblock::getWidgetAtPointLevel (this=0x801863d80, x=548, ---Type <return> to continue, or q <return> to quit--- , level=<optimized out>, context=0x7ffffffff000) at textblock.cc:2823 #7 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801863d80, x=548, y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 #8 0x0000000000456d9e in dw::Table::getWidgetAtPointLevel (this=0x801393720, x=6, y=7, level=<optimized out>, context=0x800e08148 <__sys_getpid+12>) at table.cc:440 #9 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801393720, x=548, y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 #10 0x0000000000460a3e in dw::Textblock::getWidgetAtPointLevel (this=0x801867a40, x=548, y=2569, level=<optimized out>, context=0x7ffffffff000) at textblock.cc:2823 #11 0x000000000044fc68 in dw::oof::OOFAwareWidget::getWidgetAtPoint (this=0x801867a40, x=548, y=2569, context=0x7ffffffff000) at oofawarewidget.cc:465 #12 0x000000000047b09e in dw::core::Layout::getWidgetAtPoint (this=0x8013106c0, x=548, y=2569) at layout.cc:1115 #13 0x000000000047ad2b in dw::core::Layout::processMouseEvent (this=0x8013106c0, event=0x7ffffffff0f8, type=dw::core::Layout::MOTION_NOTIFY) at layout.cc:1248 #14 0x000000000047af7c in dw::core::Layout::motionNotify (this=0x8013106c0, view=<optimized out>, x=548, y=2590, state=<optimized out>) at layout.cc:1056 #15 0x0000000000473b22 in dw::fltk::FltkViewBase::handle (this=<optimized out>, event=<optimized out>) at fltkviewbase.cc:338 #16 0x00000008006ff187 in send(int, Fl_Widget*, Fl_Window*) [clone .constprop.30] () from /usr/local/lib/libfltk.so.1.3 #17 0x0000000800700b14 in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.1.3 #18 0x0000000800758dbb in do_queued_events() () from /usr/local/lib/libfltk.so.1.3 #19 0x000000080075918a in fl_wait(double) () from /usr/local/lib/libfltk.so.1.3 #20 0x0000000800700796 in Fl::wait(double) () from /usr/local/lib/libfltk.so.1.3 #21 0x00000008007007fd in Fl::run() () from /usr/local/lib/libfltk.so.1.3 #22 0x000000000040c4d6 in main (argc=<optimized out>, argv=0x7ffffffff5e0) at dillo.cc:578 (gdb) Cheers, Johannes On Sat, Jan 16, 2016 at 10:10:57PM +0100, Alexander Voigt wrote: > Hi Sebastian, > > when I open my bookmarks site (dpi:/bm/) and move the mouse down over > some of my bookmark links, dillo crashes. I'm using commit > 4494:4f99dafc3e50. > > Best, > Alex > > On Sun, Jan 10, 2016 at 01:31:34PM +0100, Sebastian Geerken wrote: > > Hi! > > > > In the repository at <http://flpsed.org/hgweb/dillo_grows>, I've > > recently worked on a new approach for floats (run doxygen and read > > html/dw-size-request-pos.html if you are interested), which fixes many > > problems we have with the code at <http://hg.dillo.org/dillo>. > > > > The new version seems to work quite stable, at least much more stable > > than the version in the main repository. For this reason, I'd like to > > merge soon, and hopefully, we'll eventually have a release supporting > > floats. > > > > There are some more developments at > > <http://flpsed.org/hgweb/dillo_grows>, positioned elements and > > stacking contexts (needed for the former), but these have been > > deactivated; work will continue after floats are complete. > > > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 16, 2016

Work on floats

by Hole.destructor＠gmx.de

Hi Sebastian, when I open my bookmarks site (dpi:/bm/) and move the mouse down over some of my bookmark links, dillo crashes. I'm using commit 4494:4f99dafc3e50. Best, Alex On Sun, Jan 10, 2016 at 01:31:34PM +0100, Sebastian Geerken wrote: > Hi! > > In the repository at <http://flpsed.org/hgweb/dillo_grows>, I've > recently worked on a new approach for floats (run doxygen and read > html/dw-size-request-pos.html if you are interested), which fixes many > problems we have with the code at <http://hg.dillo.org/dillo>. > > The new version seems to work quite stable, at least much more stable > than the version in the main repository. For this reason, I'd like to > merge soon, and hopefully, we'll eventually have a release supporting > floats. > > There are some more developments at > <http://flpsed.org/hgweb/dillo_grows>, positioned elements and > stacking contexts (needed for the former), but these have been > deactivated; work will continue after floats are complete. > > Sebastian

Jan. 16, 2016

Work on floats

by sgeerken＠dillo.org

On Mi, Jan 13, 2016, Fredrik Gustafsson wrote: > Great to see progress on this! > > I tried it on a really "horrible" site, that usually gives my chrome > browser some performance issues. Unfortunately dillo freezes and no > images are loaded. > > The dillo version in debian (stable) does not freeze and the site works > well (although is ugly since floats is missing...). > > Try http://www.familjeliv.se Thanks for the feedback. I've tested http://www.familjeliv.se, which does not hang infinitely, but actually shows after some time (just under a minute on my machine). I'll examine the gprof output. Also, this version seems to crash quite often; I've both a gdb stacktrace and some valgrind warnings for further analysis. Sebastian

Jan. 16, 2016

Work on floats

by iveqy＠iveqy.com

On Sun, Jan 10, 2016 at 01:31:34PM +0100, Sebastian Geerken wrote: > Hi! > > In the repository at <http://flpsed.org/hgweb/dillo_grows>, I've > recently worked on a new approach for floats (run doxygen and read > html/dw-size-request-pos.html if you are interested), which fixes many > problems we have with the code at <http://hg.dillo.org/dillo>. > > The new version seems to work quite stable, at least much more stable > than the version in the main repository. For this reason, I'd like to > merge soon, and hopefully, we'll eventually have a release supporting > floats. > > There are some more developments at > <http://flpsed.org/hgweb/dillo_grows>, positioned elements and > stacking contexts (needed for the former), but these have been > deactivated; work will continue after floats are complete. > > Sebastian > Great to see progress on this! I tried it on a really "horrible" site, that usually gives my chrome browser some performance issues. Unfortunately dillo freezes and no images are loaded. The dillo version in debian (stable) does not freeze and the site works well (although is ugly since floats is missing...). Try http://www.familjeliv.se -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iveqy at iveqy.com website: http://www.iveqy.com

Jan. 13, 2016

Work on floats

by Johannes.Hofmann＠gmx.de

Hi Sebastian, cool, to see all the work on floats. I'm testing dillo_grows now and will report issues. Cheers, Johannes On Sun, Jan 10, 2016 at 01:31:34PM +0100, Sebastian Geerken wrote: > Hi! > > In the repository at <http://flpsed.org/hgweb/dillo_grows>, I've > recently worked on a new approach for floats (run doxygen and read > html/dw-size-request-pos.html if you are interested), which fixes many > problems we have with the code at <http://hg.dillo.org/dillo>. > > The new version seems to work quite stable, at least much more stable > than the version in the main repository. For this reason, I'd like to > merge soon, and hopefully, we'll eventually have a release supporting > floats. > > There are some more developments at > <http://flpsed.org/hgweb/dillo_grows>, positioned elements and > stacking contexts (needed for the former), but these have been > deactivated; work will continue after floats are complete. > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 13, 2016

Ctrl to open links in new tab or new window

by dennisn＠dennisn.mooo.com

Currently in dillorc there is "middle_click_opens_new_tab" which controls whether links that are middle clicked open in a new tab or a new window. How about allowing the ability to open it /the other way/ when that middle click is accompanied by, say, the CTRL button? (Instead of having to dig through the right-click menus to do this.) This can be trivially done by changing line 759 of html.cc (in dillo 3.0.5) to be something like: if (prefs.middle_click_opens_new_tab != (event->state == CONTROL_MASK))

Jan. 12, 2016

Work on floats

by sgeerken＠dillo.org

Hi! In the repository at <http://flpsed.org/hgweb/dillo_grows>, I've recently worked on a new approach for floats (run doxygen and read html/dw-size-request-pos.html if you are interested), which fixes many problems we have with the code at <http://hg.dillo.org/dillo>. The new version seems to work quite stable, at least much more stable than the version in the main repository. For this reason, I'd like to merge soon, and hopefully, we'll eventually have a release supporting floats. There are some more developments at <http://flpsed.org/hgweb/dillo_grows>, positioned elements and stacking contexts (needed for the former), but these have been deactivated; work will continue after floats are complete. Sebastian

Jan. 10, 2016

Increase Menu Font

by rogerx.oss＠gmail.com

> On Tue, Jan 05, 2016 at 02:32:54PM -0500, Roger wrote: >What hinders me from using Dillo more often, the menu font is quite relatively >small compared to my monitor/display DPI or monitor/display size. I have a >Dell U2713HM-IPS-LED Monitor, and usually find I have to increase the font size >on most web pages. > >However, the menu GUI font should be relatively easy to increase, including >when using DWM & DMenu here. However, increasing (or even decreasing) Dillo's >menu font size may require editing system (ie. /usr) GTKRC/QTRC file settings? > >Should this not be something exported from FLTK, with a variable set within the >dillorc file? Although there is a panel_size variable, the variable has always >been set to large here within even my 19 inch monitors, and still proving to >be still quite small compared to the size of the 19 inch monitors. Should note, there is no large option anymore for the panel_size dillorc variable. Only tiny, small & medium. Hacking the dillo source code, following gives me larger buttons when selecting the medium profile. --- ./dillo-3.0.5/src/ui.cc 2015-06-10 17:45:37.000000000 -0400 +++ ui.cc 2016-01-05 14:52:24.298175587 -0500 @@ -559,7 +559,7 @@ if (Small_Icons) bw = 42, bh = 36, mh = 0, lh = 22, lbl = 1; else - bw = 45, bh = 45, mh = 0, lh = 28, lbl = 1; + bw = 65, bh = 65, mh = 0, lh = 48, lbl = 1; } nh = bh, fh = 28; sh = 20; Although the buttons seem much larger, the font size still remains the same size. I may guess dillo is pulling the system font size (and maybe including font name and style), and using this size as it's local font size too? As such, I use a small font size for DWM's toolbars for obvious reasons. I tend to use different font sizes for all three; terminal, DWM desktop toolbars, and applications. I have DWM configured with Conky to display system information within the DWM toolbars, so the font has to be somewhat small to relay all information. Terminal uses the next larger size as I need to be able to read text or source code files, but still needs to be somewhat small to see whole files. And then applications, requiring the next larger font as the information within the application's toolbars are more well structured, allowing larger fonts, and to also mention requiring larger buttons so I can click the applications button's easier. On a side note, I'm stumped as to meanings of bw, bh, mh, lh, lbl. I can only guess; bold weight, bold hieght, medium hieght, ... Personally, I avoid two to three letter variable names, except for the obvious counters. As the inventor of programming languages stated, the langauge should be readable. ;-)

Jan. 5, 2016

Increase Menu Font

by rogerx.oss＠gmail.com

What hinders me from using Dillo more often, the menu font is quite relatively small compared to my monitor/display DPI or monitor/display size. I have a Dell U2713HM-IPS-LED Monitor, and usually find I have to increase the font size on most web pages. However, the menu GUI font should be relatively easy to increase, including when using DWM & DMenu here. However, increasing (or even decreasing) Dillo's menu font size may require editing system (ie. /usr) GTKRC/QTRC file settings? Should this not be something exported from FLTK, with a variable set within the dillorc file? Although there is a panel_size variable, the variable has always been set to large here within even my 19 inch monitors, and still proving to be still quite small compared to the size of the 19 inch monitors. -- Roger http://rogerx.freeshell.org/

Jan. 5, 2016

Enabling Javascript

by sgeerken＠dillo.org

On So, Nov 22, 2015, berenger.morel at neutralite.org wrote: > [...] > > PS: while I am here, is the top posting the common usage on this ml? I have > seen no hint about that, [...] There are no formal rules on posting style. :-) Sebastian

Nov. 23, 2015

Enabling Javascript

by berenger.morel＠neutralite.org

Ok, thanks for the information. PS: while I am here, is the top posting the common usage on this ml? I have seen no hint about that, and I might have several other questions related to dillo in near future. Le 22.11.2015 10:43, Johannes Hofmann a ?crit?: > Hello, > > there is currently no JS support available in dillo. There have been > some discussions about how scripting support could be added in the > future, but there is no code that could be enabled at the moment. > > Cheers, > Johannes > > On Sun, Nov 22, 2015 at 12:25:40AM +0100, > berenger.morel at neutralite.org wrote: >> Hello. >> >> First, sorry if this mailing list is not the good place to ask this, >> but it is the only way to contact dillo users that I have seen on >> the >> website (no IRC chan, forum, user mailing-list or.... only this dev >> ml). >> >> I am discovering dillo (at least a browser which does not eat all >> memory and take ages to start! Thanks for that guys.) and I have >> noticed >> that there might be a partial implementation of JS support ( it is >> yellow in http://www.dillo.org/Plans.html and there are bits of info >> there >> http://lists.dillo.org/pipermail/dillo-dev/2009-May/006434.html ). >> So, is this stuff in the current source tree, and if yes, how to >> enable >> it (compiling dillo won't be a problem if it is needed)? >> >> Thanks. >> >> _______________________________________________ >> 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

Nov. 22, 2015