- Dillo-dev - lists.mailman3.com

New website dillo-browser.org

by Rodrigo Arias

Hi, I just wanted to announce that we now have a new website: https://dillo-browser.org/ As well as a new git web frontend (cgit) that works well from Dillo (after some CSS fixes), so we can link to a given commit or source file: https://git.dillo-browser.org/ I'm also working on migrating the issues away from GitHub, so we can host them ourselves. Same for the CI infrastructure. The server is located on EU soil and the costs are fully covered by the donations to the project. Thanks to all donors that made it possible! I hope we can manage to keep it working for some more years, but I still plan to make some backups in other forges so we don't end up with the same single point of failure problem of the old server. Best, Rodrigo.

Sept. 27, 2025

Re: [PATCH] Open a new tab by middle clicking on tab close button

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > For now I think we can safely add this patch (attached also): > > https://github.com/dillo-browser/dillo/pull/427.patch > > It opens the home and bookmark pages in a new tab if middle-clicked. > It is not the same as opening a new blank tab, but it can probably > cover some of the cases where you open a new tab just to go to the > home page or bookmarks. > > The rationale is that we already open links in new tab when middle > clicking, and both Home and Book are like links, so I think it makes > sense. I have tested this patch and it gets the job done nicely, thank you! Regards, Alex

Aug. 5, 2025

Re: [PATCH] Open a new tab by middle clicking on tab close button

by Rodrigo Arias

Hi, For now I think we can safely add this patch (attached also): https://github.com/dillo-browser/dillo/pull/427.patch It opens the home and bookmark pages in a new tab if middle-clicked. It is not the same as opening a new blank tab, but it can probably cover some of the cases where you open a new tab just to go to the home page or bookmarks. The rationale is that we already open links in new tab when middle clicking, and both Home and Book are like links, so I think it makes sense. >This seems reasonable, but perhaps less discoverable (I didn't know >about that in Firefox until just now). In either case, I think it would >be nice to have a feature like 'always show tab bar', even if there is >only one tab open. Because in order to open a second tab, you would >need to use another means, since that element would initially not be >visible. Yeah, if we need to always show the tab bar then is not such a good idea. I'll need a bit of time to think about it. Best, Rodrigo

Aug. 4, 2025

Re: [PATCH] Open a new tab by middle clicking on tab close button

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >This patch enables the 'tab close' button to open a new tab when > >middle-clicked. This allows us to open a new tab with just one click > >instead of two. Of course it is possible to add a separate button for > >this, but to prevent clutter this might be a better solution. > > Thanks, but I don't like too much the idea of mixing closing and > opening a tab in the same button (not a very objective argument > either, I'm aware). I agree that adding a new button for opening a > new tab would clutter the UI. It seemed like the most straight-forward approach while using an existing element. This might be controversial, but what about changing the 'close tab' button to be just for opening a new tab? The close tab button is redundant, because we can just right-click (or middle-click) the tab to close it, so it's not really needed. > I was thinking in clicking the empty space after the tab to open a > new one. If there is no empty space, you cannot use this shortcut, so > we passively encourage you to close some tabs to always leave some > space. On Firefox this is done by double clicking. This seems reasonable, but perhaps less discoverable (I didn't know about that in Firefox until just now). In either case, I think it would be nice to have a feature like 'always show tab bar', even if there is only one tab open. Because in order to open a second tab, you would need to use another means, since that element would initially not be visible. > In any case, I seem to always use Ctrl+T for new tabs. Sure, but by that logic we could just do away with all of the buttons, since everything can be done by keyboard. I personally feel that we should strive for maximum accessibility, which includes mouse-centric workflows. Regards, Alex

Aug. 4, 2025

Re: [PATCH] Open a new tab by middle clicking on tab close button

by Rodrigo Arias

Hi Alex, On Wed, Jul 30, 2025 at 12:39:01PM +0000, a1ex(a)dismail.de wrote: >Hi, > >This patch enables the 'tab close' button to open a new tab when >middle-clicked. This allows us to open a new tab with just one click >instead of two. Of course it is possible to add a separate button for >this, but to prevent clutter this might be a better solution. Thanks, but I don't like too much the idea of mixing closing and opening a tab in the same button (not a very objective argument either, I'm aware). I agree that adding a new button for opening a new tab would clutter the UI. I was thinking in clicking the empty space after the tab to open a new one. If there is no empty space, you cannot use this shortcut, so we passively encourage you to close some tabs to always leave some space. On Firefox this is done by double clicking. In any case, I seem to always use Ctrl+T for new tabs. Best, Rodrigo.

Aug. 3, 2025

[PATCH] Open a new tab by middle clicking on tab close button

by a1ex＠dismail.de

Hi, This patch enables the 'tab close' button to open a new tab when middle-clicked. This allows us to open a new tab with just one click instead of two. Of course it is possible to add a separate button for this, but to prevent clutter this might be a better solution. Regards, Alex diff -upr a/src/uicmd.cc b/src/uicmd.cc --- a/src/uicmd.cc Sat Jul 26 21:03:50 2025 +++ b/src/uicmd.cc Wed Jul 30 12:23:52 2025 @@ -223,6 +223,9 @@ static void close_tab_btn_cb (Fl_Widget *, void *cb_da if (b == FL_LEFT_MOUSE) { a_UIcmd_close_bw(a_UIcmd_get_bw_by_widget(tabs->wizard()->value())); } + if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_open_url_nt(a_UIcmd_get_bw_by_widget(tabs->wizard()->value()), NULL, 1); + } } int CustTabs::handle(int e)

July 30, 2025

[PATCH] Use contrasting color for widget selections

by a1ex＠dismail.de

Hi, Here is a cleaned up version of my previous patch. I have been testing it quite a bit and for me it is working OK with both dark and light backgrounds. Just to recap the issue: Dillo currently hard-codes the color black to be used as the widget selection color (checkmarks, radio buttons, etc). When using a dark background, these selections appear to be invisible. With this patch, we ensure that the selction is visible by contrasing the selection color against the background. Any feedback welcome. Regards, Alex --- a/dw/fltkui.cc Sun Apr 27 18:56:44 2025 +++ b/dw/fltkui.cc Thu May 22 15:02:20 2025 @@ -1171,8 +1171,11 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_W core::style::Style *style) { FltkResource::setWidgetStyle(widget, style); - - widget->selection_color(FL_BLACK); + FltkColor *bg = (FltkColor*)style->backgroundColor; + int normal_bg = bg->colors[FltkColor::SHADING_NORMAL]; + int style_fg = ((FltkColor*)style->color)->colors[FltkColor::SHADING_NORMAL]; + Fl_Color fg = fl_contrast(style_fg, normal_bg); + widget->selection_color(fg); }

May 22, 2025

Re: Question regarding styling input checkbox element

by a1ex＠dismail.de

<a1ex(a)dismail.de> wrote: > Here is a working patch which I believe fixes it so that it uses the > foreground color: Sorry, I hit send too fast! It doesn't actually use the CSS foreground color, but creates a contrasting color based on the background. Maybe not ideal, but probably better than the current behavior.

May 21, 2025

Re: Question regarding styling input checkbox element

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > For some reason is always hardcoded to be black. Here is making it > always red: Thanks, looks great now! > See commit fa967f233fe6da82a98aaf3e2149d7aa5e1516cc for context, but > not sure why is not just inheriting the CSS foreground color. Here is a working patch which I believe fixes it so that it uses the foreground color: diff -upr a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc Sun Apr 27 18:56:44 2025 +++ b/dw/fltkui.cc Wed May 21 14:01:08 2025 @@ -1171,8 +1171,12 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_W core::style::Style *style) { FltkResource::setWidgetStyle(widget, style); - - widget->selection_color(FL_BLACK); + FltkColor *bg = (FltkColor*)style->backgroundColor; + int normal_bg = bg->colors[FltkColor::SHADING_NORMAL]; + int style_fg = ((FltkColor*)style->color)->colors + [FltkColor::SHADING_NORMAL]; + Fl_Color fg = fl_contrast(style_fg, normal_bg); + widget->selection_color(fg); } Regards, Alex

May 21, 2025

Re: Question regarding styling input checkbox element

by Kevin Koster

a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: > When using a dark css theme (I like to use a black background), putting > a checkmark in a checkbox is invisible (black). I tried messing around > with style.css with various configurations for input, but it seems > impossible to make the checkmark anything other than black. > > It's not a huge issue, but when editing bookmarks it becomes a little > annoying. I've got visible checkboxes on a black background with this style.css in Dillo 3.2.0: * {color: #00f400} html {background-color: gray !important} body, div, span, nav, p, a, form, h1, h2, h3, h4, h5, h6, ul, ol, li, table, tr, td {background-color: black} img, map {background-color: gray !important} :link {text-decoration: none !important; color: #00f5e8 !important} :visited {text-decoration: none !important; color: #a020f0 !important} That style does make the bookmarks page look pretty odd with its CSS enabled, but it's intended to avoid dark-on-black content on some websites.

May 20, 2025

Re: Question regarding styling input checkbox element

by Rodrigo Arias

Hi, On Tue, May 20, 2025 at 01:33:43PM +0000, a1ex(a)dismail.de wrote: >Hi, > >When using a dark css theme (I like to use a black background), putting >a checkmark in a checkbox is invisible (black). I tried messing around >with style.css with various configurations for input, but it seems >impossible to make the checkmark anything other than black. > >It's not a huge issue, but when editing bookmarks it becomes a little >annoying. > >Any suggestions, or is this just a limitation of the css implementation? For some reason is always hardcoded to be black. Here is making it always red: diff --git a/dw/fltkui.cc b/dw/fltkui.cc index db7c94e2..2d3882d2 100644 --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -1172,7 +1172,7 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_Widget *widget, { FltkResource::setWidgetStyle(widget, style); - widget->selection_color(FL_BLACK); + widget->selection_color(FL_RED); } See commit fa967f233fe6da82a98aaf3e2149d7aa5e1516cc for context, but not sure why is not just inheriting the CSS foreground color. Best, Rodrigo.

May 20, 2025

Question regarding styling input checkbox element

by a1ex＠dismail.de

Hi, When using a dark css theme (I like to use a black background), putting a checkmark in a checkbox is invisible (black). I tried messing around with style.css with various configurations for input, but it seems impossible to make the checkmark anything other than black. It's not a huge issue, but when editing bookmarks it becomes a little annoying. Any suggestions, or is this just a limitation of the css implementation? Thanks, Alex

May 20, 2025

Re: [PATCH] Revert "Use right button to close tabs by default"

by Plasma (David Paul)

On Wed, 30 Apr 2025 22:52:57 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Wed, Apr 30, 2025 at 03:31:21PM -0500, Plasma (David Paul) wrote: > >This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. > >--- > > > >Notes: > > This change addresses two issues: > > > > 1. This restores the ability to close a tab by middle-clicking on > > it. This matches long-supported behaviour of other browsers. > > Since when do we follow what other browsers do? Ok, maybe that wasn't the best way to phrase that. It's not just browsers that support closing a tab by middle-clicking; it is also the standard behaviour in both my IRC client and my graphical text editor (in addition to my other browsers). Dillo having a different default is disorienting in a similar manner (though, admittedly, not to the same severity) as driving a vehicle and discovering that the functions of the pedals are flipped. > > 2. Right-clicking a tab is now no longer a destructive action. > > It is common user expectation that right-clicking may produce a > > contextual menu. This expectation should not result in a lost tab. > > Not interested in this patch, not all systems have 3 mouse button, > specially old netbooks. If you prefer to use the middle button change > the option in dillorc. Alas. -- Plasma

May 1, 2025

Re: [PATCH] Revert "Use right button to close tabs by default"

by Rodrigo Arias

Hi, On Wed, Apr 30, 2025 at 03:31:21PM -0500, Plasma (David Paul) wrote: >This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. >--- > >Notes: > This change addresses two issues: > > 1. This restores the ability to close a tab by middle-clicking on >it. This matches long-supported behaviour of other browsers. Since when do we follow what other browsers do? > 2. Right-clicking a tab is now no longer a destructive action. It is > common user expectation that right-clicking may produce a >contextual menu. This expectation should not result in a lost tab. Not interested in this patch, not all systems have 3 mouse button, specially old netbooks. If you prefer to use the middle button change the option in dillorc. Rodrigo.

April 30, 2025

[PATCH] Revert "Use right button to close tabs by default"

by Plasma (David Paul)

This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. --- Notes: This change addresses two issues: 1. This restores the ability to close a tab by middle-clicking on it. This matches long-supported behaviour of other browsers. 2. Right-clicking a tab is now no longer a destructive action. It is common user expectation that right-clicking may produce a contextual menu. This expectation should not result in a lost tab. dillorc | 2 +- src/prefs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dillorc b/dillorc index dbe36f53..a3d22adc 100644 --- a/dillorc +++ b/dillorc @@ -424,7 +424,7 @@ ui_tab_bg_color=#b7beb7 # A mouse's middle click over a tab closes the Tab. # With mousewheel mouses, right click feels way better (set to YES). -#right_click_closes_tab=YES +#right_click_closes_tab=NO # Scroll over tabs (using the mouse wheel) to switch among tabs. # If set to NO, the page will be scrolled instead. diff --git a/src/prefs.c b/src/prefs.c index a57c792c..09b693a2 100644 --- a/src/prefs.c +++ b/src/prefs.c @@ -81,7 +81,7 @@ void a_Prefs_init(void) prefs.load_stylesheets=TRUE; prefs.middle_click_drags_page = TRUE; prefs.middle_click_opens_new_tab = TRUE; - prefs.right_click_closes_tab = TRUE; + prefs.right_click_closes_tab = FALSE; prefs.scroll_switches_tabs = TRUE; prefs.scroll_switches_tabs_reverse = FALSE; prefs.no_proxy = dStrdup(PREFS_NO_PROXY); -- Plasma

April 30, 2025

Re: [PATCH v2] middle click on nav buttons to open in new tab

by Rodrigo Arias

Hi, On Wed, Apr 30, 2025 at 08:37:33PM +0200, Rodrigo Arias wrote: >https://github.com/dillo-browser/dillo/pull/387 > >When the tests pass we can merge it. Merged: To github.com:dillo-browser/dillo.git e6364911..19559f53 master -> master Best, Rodrigo.

April 30, 2025

Re: [PATCH v2] middle click on nav buttons to open in new tab

by Rodrigo Arias

Hi, On Wed, Apr 30, 2025 at 05:01:28PM +0000, a1ex(a)dismail.de wrote: >Hi, > >Here is an updated version of the patch which addresses most of >Rodrigos comments. Not sure how much more I can improve on it, but open >to suggestions. Thanks, it looks good. I reworded the documentation and moved it to the history section. See: https://github.com/dillo-browser/dillo/pull/387 When the tests pass we can merge it. Best, Rodrigo.

April 30, 2025

[PATCH v2] middle click on nav buttons to open in new tab

by a1ex＠dismail.de

Hi, Here is an updated version of the patch which addresses most of Rodrigos comments. Not sure how much more I can improve on it, but open to suggestions. Regards, Alex diff -upr a/doc/user_help.in.html b/doc/user_help.in.html --- a/doc/user_help.in.html Sun Apr 27 18:56:44 2025 +++ b/doc/user_help.in.html Wed Apr 30 16:47:28 2025 @@ -349,6 +349,9 @@ pressed while left-clicking a link. The same applies t form. A new tab can also be opened from the <code>File</code> menu or using the shortcut <code>Ctrl+T</code>. <p> +To open the previous page in a new tab, middle-click the back button. To open +the next page in a new tab, middle-click the forward button. +<p> Press <code>Shift</code> while opening a page in a new tab to focus the tab. If you want this behaviour to be the default, set the following option in the <a href="#dillorc">dillorc</a> configuration file: diff -upr a/src/nav.c b/src/nav.c --- a/src/nav.c Sun Apr 27 18:56:44 2025 +++ b/src/nav.c Wed Apr 30 16:49:55 2025 @@ -447,6 +447,19 @@ void a_Nav_back(BrowserWindow *bw) } /* + * Send the browser back to previous page in new tab + */ +void a_Nav_back_nt(BrowserWindow *bw) +{ + int idx = a_Nav_stack_ptr(bw); + + if (--idx >= 0){ + a_UIcmd_set_msg(bw, ""); + a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw, idx)), -1); + } +} + +/* * Send the browser to next page in the history list */ void a_Nav_forw(BrowserWindow *bw) @@ -457,6 +470,19 @@ void a_Nav_forw(BrowserWindow *bw) if (++idx < a_Nav_stack_size(bw)) { a_UIcmd_set_msg(bw, ""); Nav_open_url(bw, a_History_get_url(NAV_UIDX(bw,idx)), NULL, +1); + } +} + +/* + * Send the browser to next page in the history list in new tab + */ +void a_Nav_forw_nt(BrowserWindow *bw) +{ + int idx = a_Nav_stack_ptr(bw); + + if (++idx < a_Nav_stack_size(bw)) { + a_UIcmd_set_msg(bw, ""); + a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw, idx)), +1); } } diff -upr a/src/nav.h b/src/nav.h --- a/src/nav.h Sun Apr 27 18:56:44 2025 +++ b/src/nav.h Wed Apr 30 16:49:55 2025 @@ -18,7 +18,9 @@ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url const DilloUrl *requester); void a_Nav_repush(BrowserWindow *bw); void a_Nav_back(BrowserWindow *bw); +void a_Nav_back_nt(BrowserWindow *bw); void a_Nav_forw(BrowserWindow *bw); +void a_Nav_forw_nt(BrowserWindow *bw); void a_Nav_home(BrowserWindow *bw); void a_Nav_reload(BrowserWindow *bw); void a_Nav_jump(BrowserWindow *bw, int offset, int new_bw); diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Sun Apr 27 18:56:44 2025 +++ b/src/ui.cc Wed Apr 30 16:49:55 2025 @@ -312,6 +312,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) case UI_BACK: if (b == FL_LEFT_MOUSE) { a_UIcmd_back(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_back_nt(a_UIcmd_get_bw_by_widget(wid)); } else if (b == FL_RIGHT_MOUSE) { a_UIcmd_back_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), wid->y() + wid->h()); @@ -320,6 +322,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) case UI_FORW: if (b == FL_LEFT_MOUSE) { a_UIcmd_forw(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_forw_nt(a_UIcmd_get_bw_by_widget(wid)); } else if (b == FL_RIGHT_MOUSE) { a_UIcmd_forw_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), wid->y() + wid->h()); diff -upr a/src/uicmd.cc b/src/uicmd.cc --- a/src/uicmd.cc Sun Apr 27 18:56:44 2025 +++ b/src/uicmd.cc Wed Apr 30 16:49:55 2025 @@ -868,6 +868,14 @@ void a_UIcmd_back(void *vbw) } /* + * Send the browser back to previous page in a new tab + */ +void a_UIcmd_back_nt(void *vbw) +{ + a_Nav_back_nt((BrowserWindow*)vbw); +} + +/* * Popup the navigation menu of the Back button */ void a_UIcmd_back_popup(void *vbw, int x, int y) @@ -881,6 +889,14 @@ void a_UIcmd_back_popup(void *vbw, int x, int y) void a_UIcmd_forw(void *vbw) { a_Nav_forw((BrowserWindow*)vbw); +} + +/* + * Send the browser to next page in the history list in new tab + */ +void a_UIcmd_forw_nt(void *vbw) +{ + a_Nav_forw_nt((BrowserWindow*)vbw); } /* diff -upr a/src/uicmd.hh b/src/uicmd.hh --- a/src/uicmd.hh Sun Apr 27 18:56:44 2025 +++ b/src/uicmd.hh Wed Apr 30 16:49:55 2025 @@ -29,8 +29,10 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUr void a_UIcmd_open_url_nw(BrowserWindow *bw, const DilloUrl *url); void a_UIcmd_open_url_nt(void *vbw, const DilloUrl *url, int focus); void a_UIcmd_back(void *vbw); +void a_UIcmd_back_nt(void *vbw); void a_UIcmd_back_popup(void *vbw, int x, int y); void a_UIcmd_forw(void *vbw); +void a_UIcmd_forw_nt(void *vbw); void a_UIcmd_forw_popup(void *vbw, int x, int y); void a_UIcmd_home(void *vbw); void a_UIcmd_zoom_in(void *vbw); diff -upr a/doc/user_help.in.html b/doc/user_help.in.html --- a/doc/user_help.in.html Sun Apr 27 18:56:44 2025 +++ b/doc/user_help.in.html Wed Apr 30 16:47:28 2025 @@ -349,6 +349,9 @@ pressed while left-clicking a link. The same applies t form. A new tab can also be opened from the <code>File</code> menu or using the shortcut <code>Ctrl+T</code>. <p> +To open the previous page in a new tab, middle-click the back button. To open +the next page in a new tab, middle-click the forward button. +<p> Press <code>Shift</code> while opening a page in a new tab to focus the tab. If you want this behaviour to be the default, set the following option in the <a href="#dillorc">dillorc</a> configuration file: diff -upr a/src/nav.c b/src/nav.c --- a/src/nav.c Sun Apr 27 18:56:44 2025 +++ b/src/nav.c Wed Apr 30 16:49:55 2025 @@ -447,6 +447,19 @@ void a_Nav_back(BrowserWindow *bw) } /* + * Send the browser back to previous page in new tab + */ +void a_Nav_back_nt(BrowserWindow *bw) +{ + int idx = a_Nav_stack_ptr(bw); + + if (--idx >= 0){ + a_UIcmd_set_msg(bw, ""); + a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw, idx)), -1); + } +} + +/* * Send the browser to next page in the history list */ void a_Nav_forw(BrowserWindow *bw) @@ -457,6 +470,19 @@ void a_Nav_forw(BrowserWindow *bw) if (++idx < a_Nav_stack_size(bw)) { a_UIcmd_set_msg(bw, ""); Nav_open_url(bw, a_History_get_url(NAV_UIDX(bw,idx)), NULL, +1); + } +} + +/* + * Send the browser to next page in the history list in new tab + */ +void a_Nav_forw_nt(BrowserWindow *bw) +{ + int idx = a_Nav_stack_ptr(bw); + + if (++idx < a_Nav_stack_size(bw)) { + a_UIcmd_set_msg(bw, ""); + a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw, idx)), +1); } } diff -upr a/src/nav.h b/src/nav.h --- a/src/nav.h Sun Apr 27 18:56:44 2025 +++ b/src/nav.h Wed Apr 30 16:49:55 2025 @@ -18,7 +18,9 @@ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url const DilloUrl *requester); void a_Nav_repush(BrowserWindow *bw); void a_Nav_back(BrowserWindow *bw); +void a_Nav_back_nt(BrowserWindow *bw); void a_Nav_forw(BrowserWindow *bw); +void a_Nav_forw_nt(BrowserWindow *bw); void a_Nav_home(BrowserWindow *bw); void a_Nav_reload(BrowserWindow *bw); void a_Nav_jump(BrowserWindow *bw, int offset, int new_bw); diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Sun Apr 27 18:56:44 2025 +++ b/src/ui.cc Wed Apr 30 16:49:55 2025 @@ -312,6 +312,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) case UI_BACK: if (b == FL_LEFT_MOUSE) { a_UIcmd_back(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_back_nt(a_UIcmd_get_bw_by_widget(wid)); } else if (b == FL_RIGHT_MOUSE) { a_UIcmd_back_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), wid->y() + wid->h()); @@ -320,6 +322,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) case UI_FORW: if (b == FL_LEFT_MOUSE) { a_UIcmd_forw(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_forw_nt(a_UIcmd_get_bw_by_widget(wid)); } else if (b == FL_RIGHT_MOUSE) { a_UIcmd_forw_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), wid->y() + wid->h()); diff -upr a/src/uicmd.cc b/src/uicmd.cc --- a/src/uicmd.cc Sun Apr 27 18:56:44 2025 +++ b/src/uicmd.cc Wed Apr 30 16:49:55 2025 @@ -868,6 +868,14 @@ void a_UIcmd_back(void *vbw) } /* + * Send the browser back to previous page in a new tab + */ +void a_UIcmd_back_nt(void *vbw) +{ + a_Nav_back_nt((BrowserWindow*)vbw); +} + +/* * Popup the navigation menu of the Back button */ void a_UIcmd_back_popup(void *vbw, int x, int y) @@ -881,6 +889,14 @@ void a_UIcmd_back_popup(void *vbw, int x, int y) void a_UIcmd_forw(void *vbw) { a_Nav_forw((BrowserWindow*)vbw); +} + +/* + * Send the browser to next page in the history list in new tab + */ +void a_UIcmd_forw_nt(void *vbw) +{ + a_Nav_forw_nt((BrowserWindow*)vbw); } /* diff -upr a/src/uicmd.hh b/src/uicmd.hh --- a/src/uicmd.hh Sun Apr 27 18:56:44 2025 +++ b/src/uicmd.hh Wed Apr 30 16:49:55 2025 @@ -29,8 +29,10 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUr void a_UIcmd_open_url_nw(BrowserWindow *bw, const DilloUrl *url); void a_UIcmd_open_url_nt(void *vbw, const DilloUrl *url, int focus); void a_UIcmd_back(void *vbw); +void a_UIcmd_back_nt(void *vbw); void a_UIcmd_back_popup(void *vbw, int x, int y); void a_UIcmd_forw(void *vbw); +void a_UIcmd_forw_nt(void *vbw); void a_UIcmd_forw_popup(void *vbw, int x, int y); void a_UIcmd_home(void *vbw); void a_UIcmd_zoom_in(void *vbw);

April 30, 2025

Re: [PATCH] Middle-click on back button to open prev. page in new tab

by Rodrigo Arias

Hi, >But, I think it's still useful to have, since now the action can be >performed with just 1 click, instead of 2. Also browsers like Firefox >offer the middle-click back feature like this, so it might be more >intuitive for some users. I think it makes sense for Dillo to behave in that way as well. However, the current patch needs some changes. See below: >diff -upr a/src/nav.c b/src/nav.c >--- a/src/nav.c Mon Apr 21 21:42:32 2025 >+++ b/src/nav.c Sun Apr 27 10:11:36 2025 >@@ -447,6 +447,20 @@ void a_Nav_back(BrowserWindow *bw) > } > > /* >+ * Send the browser back to previous page in new tab >+ */ >+void a_Nav_back_nt(BrowserWindow *bw) >+{ >+ int idx = a_Nav_stack_ptr(bw); >+ >+ a_Nav_cancel_expect(bw); I think you don't want to a_Nav_cancel_expect(), as this will make the current tab stop loading. >+ if (--idx >= 0){ >+ a_UIcmd_set_msg(bw, ""); >+ a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw,idx)), -1); ^add space The problem with this approach is that the newly opened tab lacks the history of the previous tab. The same problem happens with the current mechanism by opening the history menu and middle clicking an item, but it would be nice to keep it if not too hard. This new behavior needs to be added to doc/user_help.in.html as well, as otherwise it will be hard to guess. >+ } >+} >+ >+/* > * Send the browser to next page in the history list > */ > void a_Nav_forw(BrowserWindow *bw) >diff -upr a/src/nav.h b/src/nav.h >--- a/src/nav.h Mon Apr 21 21:42:32 2025 >+++ b/src/nav.h Sun Apr 27 10:12:00 2025 >@@ -18,6 +18,7 @@ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url > const DilloUrl *requester); > void a_Nav_repush(BrowserWindow *bw); > void a_Nav_back(BrowserWindow *bw); >+void a_Nav_back_nt(BrowserWindow *bw); > void a_Nav_forw(BrowserWindow *bw); We probably should add another one for the forward button too, right? > void a_Nav_home(BrowserWindow *bw); > void a_Nav_reload(BrowserWindow *bw); >diff -upr a/src/ui.cc b/src/ui.cc >--- a/src/ui.cc Mon Apr 21 21:42:32 2025 >+++ b/src/ui.cc Sun Apr 27 10:13:45 2025 >@@ -312,6 +312,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) > case UI_BACK: > if (b == FL_LEFT_MOUSE) { > a_UIcmd_back(a_UIcmd_get_bw_by_widget(wid)); >+ } else if (b == FL_MIDDLE_MOUSE) { >+ a_UIcmd_back_nt(a_UIcmd_get_bw_by_widget(wid)); > } else if (b == FL_RIGHT_MOUSE) { > a_UIcmd_back_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), > wid->y() + wid->h()); >diff -upr a/src/uicmd.cc b/src/uicmd.cc >--- a/src/uicmd.cc Mon Apr 21 21:42:32 2025 >+++ b/src/uicmd.cc Sun Apr 27 10:12:30 2025 >@@ -868,6 +868,14 @@ void a_UIcmd_back(void *vbw) > } > > /* >+ * Send the browser back to previous page in a new tab >+ */ >+void a_UIcmd_back_nt(void *vbw) >+{ >+ a_Nav_back_nt((BrowserWindow*)vbw); >+} >+ >+/* > * Popup the navigation menu of the Back button > */ > void a_UIcmd_back_popup(void *vbw, int x, int y) >diff -upr a/src/uicmd.hh b/src/uicmd.hh >--- a/src/uicmd.hh Mon Apr 21 21:42:32 2025 >+++ b/src/uicmd.hh Sun Apr 27 10:12:51 2025 >@@ -29,6 +29,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUr > void a_UIcmd_open_url_nw(BrowserWindow *bw, const DilloUrl *url); > void a_UIcmd_open_url_nt(void *vbw, const DilloUrl *url, int focus); > void a_UIcmd_back(void *vbw); >+void a_UIcmd_back_nt(void *vbw); > void a_UIcmd_back_popup(void *vbw, int x, int y); > void a_UIcmd_forw(void *vbw); > void a_UIcmd_forw_popup(void *vbw, int x, int y); >

April 28, 2025

Re: [PATCH] Middle-click on back button to open prev. page in new tab

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Keep in mind that you can right-click the back or forward buttons to > open a list of pages, and middle click any to open them in new tabs. > Not sure if this already fits your needs: > > https://dillo-browser.github.io/user_help.html#history Lol, this is true! I seem to have a real knack for "fixing" non-existent problems :) But, I think it's still useful to have, since now the action can be performed with just 1 click, instead of 2. Also browsers like Firefox offer the middle-click back feature like this, so it might be more intuitive for some users. Regards, Alex

April 27, 2025

Re: [PATCH] Middle-click on back button to open prev. page in new tab

by Rodrigo Arias

Hi Alex, On Sun, Apr 27, 2025 at 10:23:37AM +0200, a1ex(a)dismail.de wrote: >Hi list, > >Hope you are all doing well! > >I have a small feature idea: > >Sometimes I want to go back to the previous page, but also keep the >current page open. > >Obviously I can go back and then open the last page in a new tab, but >that can be annoying having to find and click on the link again. Keep in mind that you can right-click the back or forward buttons to open a list of pages, and middle click any to open them in new tabs. Not sure if this already fits your needs: https://dillo-browser.github.io/user_help.html#history Best, Rodrigo.

April 27, 2025

[PATCH] Middle-click on back button to open prev. page in new tab

by a1ex＠dismail.de

Hi list, Hope you are all doing well! I have a small feature idea: Sometimes I want to go back to the previous page, but also keep the current page open. Obviously I can go back and then open the last page in a new tab, but that can be annoying having to find and click on the link again. One solution is to make middle-clicking on the back button open the previous page in a new tab. Attached is a working proof-of-concept patch. Any feedback would be welcome! Regards, Alex diff -upr a/src/nav.c b/src/nav.c --- a/src/nav.c Mon Apr 21 21:42:32 2025 +++ b/src/nav.c Sun Apr 27 10:11:36 2025 @@ -447,6 +447,20 @@ void a_Nav_back(BrowserWindow *bw) } /* + * Send the browser back to previous page in new tab + */ +void a_Nav_back_nt(BrowserWindow *bw) +{ + int idx = a_Nav_stack_ptr(bw); + + a_Nav_cancel_expect(bw); + if (--idx >= 0){ + a_UIcmd_set_msg(bw, ""); + a_UIcmd_open_url_nt(bw, a_History_get_url(NAV_UIDX(bw,idx)), -1); + } +} + +/* * Send the browser to next page in the history list */ void a_Nav_forw(BrowserWindow *bw) diff -upr a/src/nav.h b/src/nav.h --- a/src/nav.h Mon Apr 21 21:42:32 2025 +++ b/src/nav.h Sun Apr 27 10:12:00 2025 @@ -18,6 +18,7 @@ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url const DilloUrl *requester); void a_Nav_repush(BrowserWindow *bw); void a_Nav_back(BrowserWindow *bw); +void a_Nav_back_nt(BrowserWindow *bw); void a_Nav_forw(BrowserWindow *bw); void a_Nav_home(BrowserWindow *bw); void a_Nav_reload(BrowserWindow *bw); diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Mon Apr 21 21:42:32 2025 +++ b/src/ui.cc Sun Apr 27 10:13:45 2025 @@ -312,6 +312,8 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) case UI_BACK: if (b == FL_LEFT_MOUSE) { a_UIcmd_back(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_back_nt(a_UIcmd_get_bw_by_widget(wid)); } else if (b == FL_RIGHT_MOUSE) { a_UIcmd_back_popup(a_UIcmd_get_bw_by_widget(wid), wid->x(), wid->y() + wid->h()); diff -upr a/src/uicmd.cc b/src/uicmd.cc --- a/src/uicmd.cc Mon Apr 21 21:42:32 2025 +++ b/src/uicmd.cc Sun Apr 27 10:12:30 2025 @@ -868,6 +868,14 @@ void a_UIcmd_back(void *vbw) } /* + * Send the browser back to previous page in a new tab + */ +void a_UIcmd_back_nt(void *vbw) +{ + a_Nav_back_nt((BrowserWindow*)vbw); +} + +/* * Popup the navigation menu of the Back button */ void a_UIcmd_back_popup(void *vbw, int x, int y) diff -upr a/src/uicmd.hh b/src/uicmd.hh --- a/src/uicmd.hh Mon Apr 21 21:42:32 2025 +++ b/src/uicmd.hh Sun Apr 27 10:12:51 2025 @@ -29,6 +29,7 @@ void a_UIcmd_open_url(BrowserWindow *bw, const DilloUr void a_UIcmd_open_url_nw(BrowserWindow *bw, const DilloUrl *url); void a_UIcmd_open_url_nt(void *vbw, const DilloUrl *url, int focus); void a_UIcmd_back(void *vbw); +void a_UIcmd_back_nt(void *vbw); void a_UIcmd_back_popup(void *vbw, int x, int y); void a_UIcmd_forw(void *vbw); void a_UIcmd_forw_popup(void *vbw, int x, int y);

April 27, 2025

Re: Image Redirects on the Wayback Machine

by Rodrigo Arias

Hi, >Thanks, I've poked around there before but not yet invested the time to >study how it all fits together. I hadn't discovered the developer docs >the first time though (I assumed there was only the info that's in >doc/). Well, I'm still not sure if there are any docs covering the >network-related code... There are not many, but you can find some in devdoc/. I should add them somehow to the website as well. Essentially the cache keeps a list of entries for connections in progress. When data is received, the callback for that entry is called to forward the data. But when a redirect is received, currently Dillo navigates to the new URL, as if you typed it in the location bar. What we need to support first is to allow the cache to fetch the new URL instead of changing the root URL of the current document. I believe we can do this by adding a new entry to the cache with the new URL and copying the callback and other related data, or simply reusing the same entry while we update the URL. I took a look at the time but I wasn't able to come up with a quick solution so I didn't look further. I will eventually take a look at it, but feel free to poke with the cache code in the meanwhile. Best, Rodrigo.

March 25, 2025

Re: Image Redirects on the Wayback Machine

by Kevin Koster

On Tue, 25 Mar 2025 00:13:57 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >"If Dillo requests an image and receives a response containing a > > redirection (i.e., pointing to a different URL), the redirection is > > not followed. These have a strong tendency to be advertisements." > > https://dillo-browser.github.io/old/FAQ.html#q28 > > > >However it's a real pain since most of the good stuff on the Web > >seems to have gone offline. ~/.dillo/domainrc was added to solve > >similar problems with over-active blocking of images at different > >domains (next part of that FAQ answer). Could some sort of allow > >rule for image redirects be added in that too? Or is there an > >existing work-around for the Wayback Machine images that I > >haven't figured out? > > It is not implemented yet: > > https://github.com/dillo-browser/dillo/issues/304#issuecomment-2486646504 Oh right, I saw that but thought it must have been something else. In the past I believe it's been considered as intended behaviour rather than a bug (eg. in earlier mailing list discussions which I can't find now). Hence my suggestion of a domainrc type whitelist rather than an outright 'fix'. > See Cache_redirect() in src/cache.c if you want to take a look. Thanks, I've poked around there before but not yet invested the time to study how it all fits together. I hadn't discovered the developer docs the first time though (I assumed there was only the info that's in doc/). Well, I'm still not sure if there are any docs covering the network-related code...

March 25, 2025

Re: Image Redirects on the Wayback Machine

by Rodrigo Arias

Hi, On Tue, Mar 25, 2025 at 09:20:25AM +1100, Kevin Koster wrote: >I keep needing to open pages at the Wayback Machine in Links >(graphical mode) because Dillo won't load images there. I know this >is because a while ago they started using redirects on the image >links in their archived pages, and the old Dillo FAQ says: > >"If Dillo requests an image and receives a response containing a > redirection (i.e., pointing to a different URL), the redirection is > not followed. These have a strong tendency to be advertisements." > https://dillo-browser.github.io/old/FAQ.html#q28 > >However it's a real pain since most of the good stuff on the Web >seems to have gone offline. ~/.dillo/domainrc was added to solve >similar problems with over-active blocking of images at different >domains (next part of that FAQ answer). Could some sort of allow >rule for image redirects be added in that too? Or is there an >existing work-around for the Wayback Machine images that I >haven't figured out? It is not implemented yet: https://github.com/dillo-browser/dillo/issues/304#issuecomment-2486646504 See Cache_redirect() in src/cache.c if you want to take a look. Best, Rodrigo.

March 24, 2025

Image Redirects on the Wayback Machine

by Kevin Koster

I keep needing to open pages at the Wayback Machine in Links (graphical mode) because Dillo won't load images there. I know this is because a while ago they started using redirects on the image links in their archived pages, and the old Dillo FAQ says: "If Dillo requests an image and receives a response containing a redirection (i.e., pointing to a different URL), the redirection is not followed. These have a strong tendency to be advertisements." https://dillo-browser.github.io/old/FAQ.html#q28 However it's a real pain since most of the good stuff on the Web seems to have gone offline. ~/.dillo/domainrc was added to solve similar problems with over-active blocking of images at different domains (next part of that FAQ answer). Could some sort of allow rule for image redirects be added in that too? Or is there an existing work-around for the Wayback Machine images that I haven't figured out? Example: The image link at the top of this archived webpage: http://web.archive.org/web/20001009182503/http://www.abc.net.au/defaultlo.h… http://web.archive.org/web/20001009182503im_/http://www.abc.net.au/img/abcb… Redirects to: http://web.archive.org/web/20000822094140im_/http://www.abc.net.au/img/abcb… which isn't loaded unless opened on its own via the right-click menu in Dillo.

March 24, 2025

Re: FOSDEM 2025 video

by Rodrigo Arias

On Sun, Feb 09, 2025 at 01:07:32PM +0200, Schimon Jehudah wrote: >Congratulations! > >That was an interesting idea to present the slideshows via Dillo. > >What key bindings did you use to navigate? I used a custom patch to navigate to the next fragment (div). Still needs some polishing before I can merge it. Rodrigo.

Feb. 9, 2025

FOSDEM 2025 video

by Rodrigo Arias

Hi, I published a custom edit of the FOSDEM 2025 Dillo talk with the colors corrected and a black frame here: https://www.youtube.com/watch?v=sFJp8JDg8Yg It is also on the archive: https://archive.org/details/dillo-fosdem-2025 The official video was just published now: https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… Best, Rodrigo.

Feb. 9, 2025

Re: Typos Dillo

by Rodrigo Arias

On Tue, Feb 04, 2025 at 10:59:14PM +0100, Rodrigo Arias wrote: >Thanks, they look good. I will merge it with the corrections below >[...] Merged: https://github.com/dillo-browser/dillo/commit/6cd133d2f242d36bd48ddea44acd8… Best, Rodrigo.

Feb. 5, 2025

Re: Typos Dillo

by Rodrigo Arias

Hi, On Sat, Jan 18, 2025 at 05:48:09PM +0000, Gevel Tekens wrote: >I do not have a github account, so I am sending a patch as well as the >statements that enabled the patch. They have all been hand-checked. >This is what I hope is a low-effort improvement and ahead of the FOSDEM >2025 presentation. Thanks, they look good. I will merge it with the corrections below: >diff -ruN a/dw/table.cc b/dw/table.cc >--- a/dw/table.cc 2025-01-12 17:14:01.000000000 +0100 >+++ b/dw/table.cc 2025-01-18 18:46:05.481088753 +0100 >@@ -255,7 +255,7 @@ > // An alternative would be incremental resizing for tables; this > // approach resembles the behaviour before GROWS. > >- // TODO Does it still make sence to return -1 when forceValue is >+ // TODO Does it still make sense, since to return -1 when forceValue is Only s/sence/sense/ seems enough. >@@ -547,7 +547,7 @@ > * (which is used by DwTable!), and > * (ii) line1_offset is ignored (line1_offset_eff is set to 0), > * when line1_offset plus the width of the first word is >- * greater than the the line break witdh. >+ * greater than the the line break width. Also s/the the/the/ >diff -ruN a/lout/debug_rtfl.hh b/lout/debug_rtfl.hh >--- a/lout/debug_rtfl.hh 2025-01-12 17:14:01.000000000 +0100 >+++ b/lout/debug_rtfl.hh 2025-01-18 18:46:05.725088575 +0100 >@@ -42,7 +42,7 @@ > > // Prints an RTFL message to stdout. "fmt" contains simple format > // characters how to deal with the additional arguments (no "%" >-// preceeding, as in printf) or "q" (which additionally >+// preceding, proceeding, as in printf) or "q" (which additionally Just s/preceeding/preceding/ Best, Rodrigo.

Feb. 4, 2025

Re: Dillo 3.2.0 released

by Diego

Very thanks for all the work. Diego El sáb, 18 ene 2025 a las 15:22, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > > Hi, > > The 3.2.0 version is finally released. Check the release notes here: > > https://dillo-browser.github.io/release/3.2.0/ > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 21, 2025

Re: Goolag Requiring Javascript

by a1ex＠dismail.de

Please refrain from bringing political or religious commentary here, dillo-dev is not an appropriate venue for that. Schimon Jehudah <sch(a)fedora.email> wrote: > This is good news. > > I suppose, that it indicates that they are worried of something that > is currently happening. > > Here is an example case to realize that popularity decreases on US > based operations, and the various of issues that indicate how > desperate they are. > > https://rumble.com/v6antfd-tech-lobby-aipac-and-biden-behind-tiktok-ban.html > > So, I think that we should be glad about it and provide different > search services. > > Perhaps Dillo should have a built-in DHT-based search interface (such > as of Kad of eMule) that would communicate with instances such as > 4get, Marginalia, MetaGer, SearxNG, Wiby, YaCy etc. > > Would not that be fun? > > Would not that solve many issues that not only Dillo faces? > > Regards, > Schimon > > On Tue, 21 Jan 2025 08:00:58 +1100 > "Kevin Koster" <dillo(a)ombertech.com> wrote: > > > It's probably best to remove Google from the search engines in > > the default dillorc because it no longer works in browsers without > > Javascript support: > > https://www.osnews.com/story/141570/google-begins-requiring-javascript-for-… > > > > In Dillo Google now redirects me to a page saying: > > "Turn on JavaScript to keep searching" > > _______________________________________________ > > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 21, 2025

DHT based search engine

by Schimon Jehudah

Greeting! I suppose that people here know BBS, P2P, Kad, eD2k (eDonkey2000), Gnutella, G2, DC, ADC etc. Whlie I have wrote an email concerning to a search service provider, I have thought of the DHT technology which could make search engines built-in. > Perhaps Dillo should have a built-in DHT-based search interface (such > as of Kad of eMule) that would communicate with instances such as > 4get, Marginalia, MetaGer, SearxNG, Wiby, YaCy etc. What do you think of this idea? We can start by providing a plugin and later decide whether to make this a part of Dillo. I can write a plugin in Python, if you want me to. Kindly, Schimon

Jan. 21, 2025

Re: Goolag Requiring Javascript

by Schimon Jehudah

This is good news. I suppose, that it indicates that they are worried of something that is currently happening. Here is an example case to realize that popularity decreases on US based operations, and the various of issues that indicate how desperate they are. https://rumble.com/v6antfd-tech-lobby-aipac-and-biden-behind-tiktok-ban.html So, I think that we should be glad about it and provide different search services. Perhaps Dillo should have a built-in DHT-based search interface (such as of Kad of eMule) that would communicate with instances such as 4get, Marginalia, MetaGer, SearxNG, Wiby, YaCy etc. Would not that be fun? Would not that solve many issues that not only Dillo faces? Regards, Schimon On Tue, 21 Jan 2025 08:00:58 +1100 "Kevin Koster" <dillo(a)ombertech.com> wrote: > It's probably best to remove Google from the search engines in > the default dillorc because it no longer works in browsers without > Javascript support: > https://www.osnews.com/story/141570/google-begins-requiring-javascript-for-… > > In Dillo Google now redirects me to a page saying: > "Turn on JavaScript to keep searching" > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 21, 2025

Re: Google Requiring Javascript

by Kevin Koster

On Mon, 20 Jan 2025 22:49:41 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Tue, Jan 21, 2025 at 08:00:58AM +1100, Kevin Koster wrote: > >In Dillo Google now redirects me to a page saying: > >"Turn on JavaScript to keep searching" > > Still works if you mimic netsurf, w3m or elinks user agents That's surprising. > I still don't have much hope it will last long for those browsers. Certainly since their claimed motivation is "Enabling JavaScript allows us to better protect our services and users from bots and evolving forms of abuse and spam". It's hardly going to take long for bot writers to discover user-agent spoofing. > I would leave it for now, until it stops working with any UA. Fair enough. -- Kevin Koster <dillo(a)ombertech.com>

Jan. 20, 2025

Re: Google Requiring Javascript

by Rodrigo Arias

Hi, On Tue, Jan 21, 2025 at 08:00:58AM +1100, Kevin Koster wrote: >It's probably best to remove Google from the search engines in >the default dillorc because it no longer works in browsers without >Javascript support: >https://www.osnews.com/story/141570/google-begins-requiring-javascript-for-… > >In Dillo Google now redirects me to a page saying: >"Turn on JavaScript to keep searching" Still works if you mimic netsurf, w3m or elinks user agents, but yeah not ideal. See also: https://github.com/dillo-browser/dillo/issues/338 https://news.ycombinator.com/item?id=42719865 https://support.google.com/websearch/thread/318978583 I suspect they still "care" a bit about non-JS browsers, they just don't test Dillo and their stupid support system doesn't let me pass the message to the engineering team. I still don't have much hope it will last long for those browsers. I would leave it for now, until it stops working with any UA. Best, Rodrigo.

Jan. 20, 2025

Re: Typos Dillo

by Rodrigo Arias

Hi, On Sat, Jan 18, 2025 at 05:48:09PM +0000, Gevel Tekens wrote: >I do not have a github account, so I am sending a patch as well as the >statements that enabled the patch. They have all been hand-checked. >This is what I hope is a low-effort improvement and ahead of the FOSDEM >2025 presentation. Thanks! I'll merge it when I have a moment to review the changes. Best, Rodrigo.

Jan. 20, 2025

Google Requiring Javascript

by Kevin Koster

It's probably best to remove Google from the search engines in the default dillorc because it no longer works in browsers without Javascript support: https://www.osnews.com/story/141570/google-begins-requiring-javascript-for-… In Dillo Google now redirects me to a page saying: "Turn on JavaScript to keep searching"

Jan. 20, 2025

Re: Typos Dillo

by a1ex＠dismail.de

Gevel Tekens <geveltekens(a)gmail.com> wrote: > I do not have a github account, so I am sending a patch as well as the > statements that enabled the patch. They have all been hand-checked. > This is what I hope is a low-effort improvement and ahead of the > FOSDEM 2025 presentation. > > Best regards > > GT Patch looks good from here. One small correction: diff -ruN a/devdoc/lout.doc b/devdoc/lout.doc --- a/devdoc/lout.doc 2025-01-12 17:14:01.000000000 +0100 +++ b/devdoc/lout.doc 2025-01-18 18:46:05.689088602 +0100 @@ -61,7 +61,7 @@ <h2>Debugging</h2> In debug.hh, there are some some useful macros for debugging messages, -see the file for mor informations. +see the file for mor information. ^^

Jan. 18, 2025

Typos Dillo

by Gevel Tekens

I do not have a github account, so I am sending a patch as well as the statements that enabled the patch. They have all been hand-checked. This is what I hope is a low-effort improvement and ahead of the FOSDEM 2025 presentation. Best regards GT

Jan. 18, 2025

Dillo 3.2.0 released

by Rodrigo Arias

Hi, The 3.2.0 version is finally released. Check the release notes here: https://dillo-browser.github.io/release/3.2.0/ Best, Rodrigo.

Jan. 18, 2025

Dillo 3.2.0-rc1 released

by Rodrigo Arias

Hi, Here is the 3.2.0-rc1 candidate release: https://github.com/dillo-browser/dillo/releases/tag/v3.2.0-rc1 Direct links: https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… https://github.com/dillo-browser/dillo/releases/download/v3.2.0-rc1/dillo-3… Please test and report any issues. If there are no more problems, the 3.2.0 release will be out soon. I'll add some notes in the website when 3.2.0 is released, maybe with some before/after screenshots. Best, Rodrigo.

Jan. 12, 2025

Re: other cool neighbours

by Rodrigo Arias

Hi, On Mon, Jan 06, 2025 at 02:42:00PM +0042, yeti wrote: > Chawan - a web browser for your terminal > <https://sr.ht/~bptato/chawan/> Very cool, I think they have some nice ideas for how to implement multiple protocols and mime handlers. > I played a bit with it. Ok, ok, more a long than only a bit. ;-) > > The following snapshot was taken from Chawan running on an OpenBSD7 > pubnix I was connected to over SSH in XTerm on Debian: > > <https://web.archive.org/web/20250104110122if_/https://yeti.tilde.institute/…> > > The second one was shot via XTerm and SSH too, but this time the remote > was a headless Pi2 in my LAN: > > <https://web.archive.org/web/20250104152517if_/https://yeti.tilde.institute/…> > > Chawan seems to be the first browser in a terminal that does not butcher > my Org-Babel notes massively. Even without graphics via Sixels this > would have been a big leap for proofreading my own stuff over SSH or > Mosh if graphics aren't needed, but sure I won't complain about graphics > being supported too. \o/ If you want to bring remote HTML files to the machine where the screen is attached, you can use: - SSH local port forwarding + remote http an server like darkhttpd listening on localhost: % ssh -L 8080:localhost:8080 the.host darkhttpd /path/to/website & % dillo http://localhost:8080 - sshfs + file: % sshfs the.host:/path/to/website /mnt/web % dillo file:///mnt/web So you only need to transfer the HTML documents and images over SSH and moving around doesn't require a round-trip to the server. Best, Rodrigo.

Jan. 6, 2025

Re: other cool neighbours

by a1ex＠dismail.de

yeti <yeti(a)tilde.institute> wrote: > Chawan - a web browser for your terminal > <https://sr.ht/~bptato/chawan/> I've been watching this one for a while, it's looking like it could become one of the best terminal-based browsers. The author is making a lot of progress. It could never replace Dillo, but that's a completely different use-case. -Alex

Jan. 6, 2025

other cool neighbours

by yeti

Chawan - a web browser for your terminal <https://sr.ht/~bptato/chawan/> I played a bit with it. Ok, ok, more a long than only a bit. ;-) The following snapshot was taken from Chawan running on an OpenBSD7 pubnix I was connected to over SSH in XTerm on Debian: <https://web.archive.org/web/20250104110122if_/https://yeti.tilde.institute/…> The second one was shot via XTerm and SSH too, but this time the remote was a headless Pi2 in my LAN: <https://web.archive.org/web/20250104152517if_/https://yeti.tilde.institute/…> Chawan seems to be the first browser in a terminal that does not butcher my Org-Babel notes massively. Even without graphics via Sixels this would have been a big leap for proofreading my own stuff over SSH or Mosh if graphics aren't needed, but sure I won't complain about graphics being supported too. \o/ -- Trust me, I know what I'm doing...

Jan. 6, 2025

Re: breaking long words with css

by Rodrigo Arias

Hi Alex, On Mon, Jan 06, 2025 at 12:22:38PM +0100, a1ex(a)dismail.de wrote: > Hi list, > > I'm trying to figure out how to break super-long words so that they > wrap to my viewport width. > > So far I have tried various incantations of these in my style.css for > various elements with no luck: > > word-break: break-all; > word-wrap: break-word; > > Here is an example page with a very long word which I'm trying to wrap: > https://news.ycombinator.com/item?id=42609200 > > In the context of the parent thread, it breaks the wrapping of all the > other posts: > https://news.ycombinator.com/item?id=42599102 > > Am I making a dumb mistake, or is feature not implemented in Dillo? There is no support for word-break, word-wrap or overflow-wrap in Dillo (yet). Best, Rodrigo.

Jan. 6, 2025

breaking long words with css

by a1ex＠dismail.de

Hi list, I'm trying to figure out how to break super-long words so that they wrap to my viewport width. So far I have tried various incantations of these in my style.css for various elements with no luck: word-break: break-all; word-wrap: break-word; Here is an example page with a very long word which I'm trying to wrap: https://news.ycombinator.com/item?id=42609200 In the context of the parent thread, it breaks the wrapping of all the other posts: https://news.ycombinator.com/item?id=42599102 Am I making a dumb mistake, or is feature not implemented in Dillo? Thanks for any help, Alex

Jan. 6, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Thu, Jan 02, 2025 at 11:58:19AM +1100, Kevin Koster wrote: >> For all my tests User-Agent was: Dillo/3.1.0 >> >> I'm in Australia. Maybe CDNs are directing my requests to Web servers >> with different rules than others? > > Yeah, maybe there are some geo-fencing rules, although I was not > expecting it to be that way. There is also the possibility that > something is broken in Dillo or elsewhere. > > I also tested https://ebay.com.au/ and https://ebay.com/ with mbedtls > 2.28.9 and 3.6.1, and they are both blocked for me (from Spain). I > cannot reproduce what you are observing. > > In curl works for me, or in Dillo if I change the user agent to the one > curl uses. It also works if I set the user agent to "Dillo/3.1.0" in > curl as well as force it to use HTTP 1.1. > > Not sure what is going on. Could you send your http options? > > $ grep '^http' ~/.dillo/dillorc http_language="en-AU,en,en-US" http_strict_transport_security=NO http_referer=path

Jan. 2, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi Kevin, On Thu, Jan 02, 2025 at 11:58:19AM +1100, Kevin Koster wrote: > For all my tests User-Agent was: Dillo/3.1.0 > > I'm in Australia. Maybe CDNs are directing my requests to Web servers > with different rules than others? Yeah, maybe there are some geo-fencing rules, although I was not expecting it to be that way. There is also the possibility that something is broken in Dillo or elsewhere. I also tested https://ebay.com.au/ and https://ebay.com/ with mbedtls 2.28.9 and 3.6.1, and they are both blocked for me (from Spain). I cannot reproduce what you are observing. In curl works for me, or in Dillo if I change the user agent to the one curl uses. It also works if I set the user agent to "Dillo/3.1.0" in curl as well as force it to use HTTP 1.1. Not sure what is going on. Could you send your http options? $ grep '^http' ~/.dillo/dillorc Best, Rodrigo.

Jan. 2, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by a1ex＠dismail.de

Kevin Koster wrote: > I'm in Australia. Maybe CDNs are directing my requests to Web servers > with different rules than others? Yes, that seems to be the case: > Nav_open_url: new url='https://www.lowes.com/' > Dns_server [0]: www.lowes.com is 23.54.30.24 23.54.30.14 I get a completely different DNS result from Europe: Nav_open_url: new url='https://www.lowes.com' Dns_server [0]: www.lowes.com is 2.16.1.211 2.16.1.234 Which is an edgekey/akamaiedge cdn located in France, whereas yours is a is a different akamai cdn which appears to be located in Sydney.

Jan. 2, 2025