December 2014 - Dillo-dev - lists.mailman3.com

here's 3.0.4.1 RC1

by me＠v4hn.de

On Mon, Dec 08, 2014 at 01:11:38AM +0100, Sebastian Geerken wrote: > On Mon, Dec 08, 2014, v4hn wrote: > > Talking about bugs... I just found out this version segfaults over here > > if I enter any string containing a space character. For example entering > > "foo bar" into the adress line and hitting enter segfaults over here. > > Can anyone reproduce this? > > Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) > This bug occurs already in release 3.0.4. Yes, setting search_url makes the bug disappear. Thanks for investigating! v4hn

Dec. 8, 2014

here's 3.0.4.1 RC1

by sgeerken＠dillo.org

On Mon, Dec 08, 2014, v4hn wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > Talking about bugs... I just found out this version segfaults over here > if I enter any string containing a space character. For example entering > "foo bar" into the adress line and hitting enter segfaults over here. > Can anyone reproduce this? Yes, if and only if "search_url" is not defined. (I'm happy with DDG.) This bug occurs already in release 3.0.4. Segfault is in UIcmd_find_search_str, with these values: (gdb) p dList_length(prefs.search_urls) $1 = 2 (gdb) p (char*)dList_nth_data(prefs.search_urls, 0) $2 = 0x710f40 "http://duckduckgo.com/lite/?kp=-1&q=%s" (gdb) p (char*)dList_nth_data(prefs.search_urls, 1) $3 = 0x0 Sebastian

Dec. 8, 2014

here's 3.0.4.1 RC1

by higuita7＠yahoo.co.uk

Hi On Mon, 8 Dec 2014 00:28:08 +0100, v4hn <me at v4hn.de> wrote: > Talking about bugs... I just found out this version segfaults over here > if I enter any string containing a space character. For example entering > "foo bar" into the adress line and hitting enter segfaults over here. > Can anyone reproduce this? Works fine here, linux 64bit, fltk 1.3.3 higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Dec. 8, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > make sure that everything is all right, so: > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 Talking about bugs... I just found out this version segfaults over here if I enter any string containing a space character. For example entering "foo bar" into the adress line and hitting enter segfaults over here. Can anyone reproduce this? v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by me＠v4hn.de

On Sun, Dec 07, 2014 at 06:36:02PM +0100, Johannes Hofmann wrote: > Could you please grep for NET_SUPPORTING in your dwm sources? > In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and > this seems to cause ewmh_supported() to return 0 in my case. That flag doesn't exist over here in my code as well: $ grep -r _NET dwm.1:.B xprop -root -f _NET_WM_NAME 32a -set _NET_WM_NAME LG3D dwm.c: setfullscreen(c, (cme->data.l[0] == 1 /* _NET_WM_STATE_ADD dwm.c: || (cme->data.l[0] == 2 /* _NET_WM_STATE_TOGGL dwm.c: netatom[NetActiveWindow] = XInternAtom(dpy, "_NET_ACTIVE_WINDOW", False); dwm.c: netatom[NetSupported] = XInternAtom(dpy, "_NET_SUPPORTED", False); dwm.c: netatom[NetWMName] = XInternAtom(dpy, "_NET_WM_NAME", False); dwm.c: netatom[NetWMState] = XInternAtom(dpy, "_NET_WM_STATE", False); dwm.c: netatom[NetWMFullscreen] = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", Fals dwm.c: netatom[NetWMWindowType] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE", False); dwm.c: netatom[NetWMWindowTypeDialog] = XInternAtom(dpy, "_NET_WM_WINDOW_TYPE_DIALO dwm.c: netatom[NetClientList] = XInternAtom(dpy, "_NET_CLIENT_LIST", False); On Sun, Dec 07, 2014 at 09:23:40PM +0100, Johannes Hofmann wrote: > I have a fix that works on my system so far: > > diff -r 72f0e7ccccc9 src/uicmd.cc > --- a/src/uicmd.cc Thu Nov 27 19:20:33 2014 +0000 > +++ b/src/uicmd.cc Sun Dec 07 21:20:08 2014 +0100 > @@ -551,10 +551,10 @@ > win->box(FL_NO_BOX); > CustTabs *DilloTabs = new CustTabs(ww, wh, 16); > win->end(); > + win->resizable(DilloTabs->wizard()); > > int focus = 1; > new_bw = UIcmd_tab_new(DilloTabs, old_ui, focus); > - win->resizable(DilloTabs->wizard()); > win->show(); > > if (old_bw == NULL && prefs.xpos >= 0 && prefs.ypos >= 0) { That looks like a painful debugging experience... > Please give it a try and report back if it breaks anything. Didn't break anything over here. It still works just as great as it did before. :-) v4hn

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

Hi, I have a fix that works on my system so far: diff -r 72f0e7ccccc9 src/uicmd.cc --- a/src/uicmd.cc Thu Nov 27 19:20:33 2014 +0000 +++ b/src/uicmd.cc Sun Dec 07 21:20:08 2014 +0100 @@ -551,10 +551,10 @@ win->box(FL_NO_BOX); CustTabs *DilloTabs = new CustTabs(ww, wh, 16); win->end(); + win->resizable(DilloTabs->wizard()); int focus = 1; new_bw = UIcmd_tab_new(DilloTabs, old_ui, focus); - win->resizable(DilloTabs->wizard()); win->show(); if (old_bw == NULL && prefs.xpos >= 0 && prefs.ypos >= 0) { Please give it a try and report back if it breaks anything. Cheers, Johannes PS: The problem was that some code in UIcmd_tab_new() is triggering Fl_X::sendxjunk() and if at that moment no resizable is set, the window get's marked as fixed size. On Sun, Dec 07, 2014 at 06:36:02PM +0100, Johannes Hofmann wrote: > On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > > On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > > > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > > > and X11-forwarded to my DragonFly box. > > > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > > > output of xprop for the dillo window. I get: > > > > > > WM_STATE(WM_STATE): > > > window state: Normal > > > icon window: 0x0 > > > _NET_WM_ICON(CARDINAL) = > > > WM_HINTS(WM_HINTS): > > > Client accepts input or input focus: True > > > XdndAware(ATOM) = ATOM > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > program specified minimum size: 780 by 580 > > > program specified maximum size: 780 by 580 > > > window gravity: Static > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > For me it's: > > > > > $ xprop > > > WM_STATE(WM_STATE): > > > window state: Normal > > > icon window: 0x0 > > > _NET_WM_ICON(CARDINAL) = > > > WM_HINTS(WM_HINTS): > > > Client accepts input or input focus: True > > > XdndAware(ATOM) = ATOM > > > WM_CLASS(STRING) = "dillo", "Dillo" > > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > > program specified minimum size: 100 by 101 > > > window gravity: Static > > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > > > So yes, I see more realistic/useful size hints over here. > > > > In case this is relevant, I'm not actually running the latest master > > of dwm over here, but 7edc59631193813cf4d64030f8864de36b193cfc with custom patches. > > I didn't get around to update the patches yet. > > Could you please grep for NET_SUPPORTING in your dwm sources? > In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and > this seems to cause ewmh_supported() to return 0 in my case. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sun, Dec 07, 2014 at 04:08:30PM +0000, eocene wrote: > Johannes wrote: > > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > > make sure that everything is all right, so: > > > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > > > > shouldn't Jorge's dicache fixes also be included? > > At the time, I thought of keeping the set of changes exceedingly minimal > and exceedingly safe because it was something quick to respond to 1.3.3. Ok, sounds reasonable. > Now that this is taking a little more time, the line could be drawn > differently. Let's focus on fixing the remaining issue with 3.0.4.1 fist. Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by Johannes.Hofmann＠gmx.de

On Sat, Dec 06, 2014 at 01:22:06PM +0100, v4hn wrote: > On Sat, Dec 06, 2014 at 11:17:36AM +0100, Johannes Hofmann wrote: > > I get the same result with dillo-3.0.4.1 and fltk-1.3.3 compiled on Linux > > and X11-forwarded to my DragonFly box. > > Could someone with a working dillo-3.0.4.1 and fltk-1.3.3 please post the > > output of xprop for the dillo window. I get: > > > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x1, 0x13, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 780 by 580 > > program specified maximum size: 780 by 580 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > For me it's: > > > $ xprop > > WM_STATE(WM_STATE): > > window state: Normal > > icon window: 0x0 > > _NET_WM_ICON(CARDINAL) = > > WM_HINTS(WM_HINTS): > > Client accepts input or input focus: True > > XdndAware(ATOM) = ATOM > > WM_CLASS(STRING) = "dillo", "Dillo" > > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x0, 0x1, 0x1, 0x0, 0x0 > > WM_NORMAL_HINTS(WM_SIZE_HINTS): > > program specified minimum size: 100 by 101 > > window gravity: Static > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW > > WM_ICON_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_ICON_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > WM_NAME(STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > _NET_WM_NAME(UTF8_STRING) = "Dillo: Splash screen for dillo-3.0.4.1" > > So yes, I see more realistic/useful size hints over here. > > In case this is relevant, I'm not actually running the latest master > of dwm over here, but 7edc59631193813cf4d64030f8864de36b193cfc with custom patches. > I didn't get around to update the patches yet. Could you please grep for NET_SUPPORTING in your dwm sources? In current dwm tip _NET_SUPPORTING_WM_CHECK is no longer set and this seems to cause ewmh_supported() to return 0 in my case. Cheers, Johannes

Dec. 7, 2014

here's 3.0.4.1 RC1

by jcid＠dillo.org

On Sun, Dec 07, 2014 at 01:07:00PM +0100, Johannes Hofmann wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > shouldn't Jorge's dicache fixes also be included? I'd prefer not to include them this time, and issue just a compilation fix release for fltk-1.3.3 (which is not yet even in Debian's experimental), so we can focus on making dillo GROWS into "releaseable" state. ;) I'd also like to have the dwm-detected bug tackled before the release. It looks like a problem in fltk-1.3.3 (from Johannes' tests); we may need to contact the FLTK team at some point. -- Cheers Jorge.-

Dec. 7, 2014

here's 3.0.4.1 RC1

by eocene＠gmx.com

Johannes wrote: > On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > > make sure that everything is all right, so: > > > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 > > > > shouldn't Jorge's dicache fixes also be included? At the time, I thought of keeping the set of changes exceedingly minimal and exceedingly safe because it was something quick to respond to 1.3.3. Now that this is taking a little more time, the line could be drawn differently.

Dec. 7, 2014