Re: Hotlist window issue

On 28 Aug 2023 as I do recall,
Rob Kendrick wrote:

> On Sun, Aug 27, 2023 at 11:37:26PM +0100, Harriet Bazley wrote:
> > I've just noticed that the same thing applies to the global history
> > window - if I check that in WinEd, the history window in the Templates
> > file has *neither* 'Allow off screen' nor 'Keep on screen' flags set.
>
> Both of these use the "tree" template, whose source can be found here:
> http://git.netsurf-browser.org/netsurf.git/tree/frontends/riscos/templates/en#n2605

Thanks for the pointer - I've spent a lot of time fiddling around with
the settings of those two flags in !NetSurf.Resources.en.Templates.tree,
and so far as I can tell the only setting that can prevent the window
from resizing itself off the bottom of the screen is to have 'Keep on
screen' (bit 13) ON and 'Allow off screen' (bit 6) OFF. Which is rather
more stringent than actually desirable, because it then makes it
impossible for any part of that window ever to be outside the screen
ever, which is *not* normal Wimp behaviour, but it's the only
combination of flags that appears to produce the desired result of
jumping up to the top of the screen to use the maximum visible area when
the size is toggled.

I can only assume that the 'standard' RISC OS behaviour (as displayed by
NetSurf's main browser window for instance) of forcing the window
onscreen when the user requests a toggle to maximum size, but permitting
it to be dragged partially offscreen thereafter, requires some kind of
application redraw rather than being handled entirely by the WIMP?

--
Harriet Bazley == Loyaulte me lie ==

A poor workman blames his tools.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Hotlist window issue

On Sun, Aug 27, 2023 at 11:37:26PM +0100, Harriet Bazley wrote:
> I've just noticed that the same thing applies to the global history
> window - if I check that in WinEd, the history window in the Templates
> file has *neither* 'Allow off screen' nor 'Keep on screen' flags set.

Both of these use the "tree" template, whose source can be found here:
http://git.netsurf-browser.org/netsurf.git/tree/frontends/riscos/templates/en#n2605

(And similar in the other languages.)

B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Hotlist window issue

On 27 Aug 2023 as I do recall,

Christian Ludlam wrote:

>
> > On 27 Aug 2023, at 22:42, Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
> >
> > On 27 Aug 2023 as I do recall,
> > Frederick Bambrough wrote:
> >
> >> Is this a known bug?
> >>
> >> Hotlist ignores 'Allow windows off screen' configuration settings when
> >> 'off screen' is disallowed. It moves freely off screen in all directions
> >> except 'top' where it stops with the top edge of the title bar off screen.
> >>
> >> Other NetSurf windows do as expected.

[snip]

> > The hotlist simply expands downwards from its current position, which
> > causes the resize icon and bottom scroll arrow to disappear off the
> > bottom of the screen, which under RISC OS means that you *can't* then
> > resize it manually to make the bottom items accessible again….
> >
>
> I think both problems are controlled by bit 6 of the window flags - if you
> have a template editor you may be able to fix this.

I've just noticed that the same thing applies to the global history
window - if I check that in WinEd, the history window in the Templates
file has *neither* 'Allow off screen' nor 'Keep on screen' flags set.

These two are confusing:
https://www.riscosopen.org/forum/forums/11/topics/17817#posts-139923
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Hotlist window issue

> On 27 Aug 2023, at 22:42, Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>
> On 27 Aug 2023 as I do recall,
> Frederick Bambrough wrote:
>
>> Is this a known bug?
>>
>> Hotlist ignores 'Allow windows off screen' configuration settings when
>> 'off screen' is disallowed. It moves freely off screen in all directions
>> except 'top' where it stops with the top edge of the title bar off screen.
>>
>> Other NetSurf windows do as expected.
>>
> I reported an offscreen-hotlist-related window issue back in 2021. It
> has never been acknowledged, let alone confirmed or resolved (and it's
> still present, and as annoying as ever).
> https://bugs.netsurf-browser.org/mantis/view.php?id=2831
>
> Its is not normal RISC OS behaviour for the 'toggle window size' icon to
> expand the window *beyond the edge of the screen*, whatever the 'Allow
> windows off screen' configuration is, and indeed other NetSurf windows
> behave as expected - you can drag them manually so that portions are
> off-screen, but as soon as you toggle the size they expand to the
> largest possible size that will fit on the screen (moving to the top of
> the screen if necessary in order to fit in the maxmimum-size window) but
> no larger.
>
> The hotlist simply expands downwards from its current position, which
> causes the resize icon and bottom scroll arrow to disappear off the
> bottom of the screen, which under RISC OS means that you *can't* then
> resize it manually to make the bottom items accessible again….
>

I think both problems are controlled by bit 6 of the window flags - if you
have a template editor you may be able to fix this.

Christian

_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: Hotlist window issue

On 27 Aug 2023 as I do recall,
Frederick Bambrough wrote:

> Is this a known bug?
>
> Hotlist ignores 'Allow windows off screen' configuration settings when
> 'off screen' is disallowed. It moves freely off screen in all directions
> except 'top' where it stops with the top edge of the title bar off screen.
>
> Other NetSurf windows do as expected.
>
I reported an offscreen-hotlist-related window issue back in 2021. It
has never been acknowledged, let alone confirmed or resolved (and it's
still present, and as annoying as ever).
https://bugs.netsurf-browser.org/mantis/view.php?id=2831

Its is not normal RISC OS behaviour for the 'toggle window size' icon to
expand the window *beyond the edge of the screen*, whatever the 'Allow
windows off screen' configuration is, and indeed other NetSurf windows
behave as expected - you can drag them manually so that portions are
off-screen, but as soon as you toggle the size they expand to the
largest possible size that will fit on the screen (moving to the top of
the screen if necessary in order to fit in the maxmimum-size window) but
no larger.

The hotlist simply expands downwards from its current position, which
causes the resize icon and bottom scroll arrow to disappear off the
bottom of the screen, which under RISC OS means that you *can't* then
resize it manually to make the bottom items accessible again....


--
Harriet Bazley == Loyaulte me lie ==

The best way to keep your friends is not to give them away.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Hotlist window issue

Is this a known bug?

Hotlist ignores 'Allow windows off screen' configuration settings when
'off screen' is disallowed. It moves freely off screen in all directions
except 'top' where it stops with the top edge of the title bar off screen.

Other NetSurf windows do as expected.

RISC OS 5.29, RPi 4, NetSurf 3.11 (Dev CI #5442)
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

[PATCH] makefiles/Makefile.top: dependencies for PRE_ and POST_TARGETS

The PRE_TARGETS and POST_TARGETS are supposed to be built before and
after $(OBJECTS), respectively -- at least according to the comments
in Makefile.top:

# List of targets to run before building $(OBJECT)
PRE_TARGETS :=
# List of targets to run after building $(OBJECT)
POST_TARGETS :=

The default target however builds them at the same time as $(OUTPUT),

# Default target
all: $(PRE_TARGETS) $(OUTPUT) $(POST_TARGETS)

where $(OUTPUT) basically just builds $(OBJECTS):

$(OUTPUT): $(BUILDDIR)/stamp $(OBJECTS)
...

As a result, there is a race condition when $(OBJECTS) truly requires
$(PRE_TARGETS), because they may be built at the same time. The same
problem arises the other way around with $(POST_TARGETS). As a
demonstration, one can try to build the libsvgtiny shared library
directly (note: the details are platform-dependent),

$ BD=build-x86_64-pc-linux-gnu-x86_64-pc-linux-gnu-release-lib-shared
$ make COMPONENT_TYPE=lib-shared "${BD}/libsvgtiny.so.0.1.7"
COMPILE: src/svgtiny.c
...
src/svgtiny.c:24:10: fatal error: autogenerated_colors.c: No such file or directory
24 | #include "autogenerated_colors.c"
| ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

This is because $(PRE_TARGETS) is not satisfied. In practice, this
condition seems hard to hit unintentionally, but it can happen if you
are building in parallel and extemely unlucky. A user discovered it in
Gentoo bug 711200.

The fix simply adds the stated dependencies on $(OBJECTS) and
$(POST_TARGETS) to guarantee the correct order.
---
makefiles/Makefile.top | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/makefiles/Makefile.top b/makefiles/Makefile.top
index caac166..dafdfaa 100644
--- a/makefiles/Makefile.top
+++ b/makefiles/Makefile.top
@@ -176,6 +176,11 @@ OBJECTS := $(addprefix $(BUILDDIR)/,$(filter %.o, \
$(subst /,_,$(subst .cmhg,.o,$(SOURCES))) \
$(subst /,_,$(subst .s,.o,$(SOURCES)))))

+# Ensure that PRE_TARGETS are built before OBJECTS, and POST_TARGETS
+# after them.
+$(OBJECTS): $(PRE_TARGETS)
+$(POST_TARGETS): $(OBJECTS)
+
bin_for_test = $(addprefix $(BUILDDIR)/,$(firstword $(subst :, ,$(ITEM))))
TEST_BINARIES := $(foreach ITEM,$(TEST_ITEMS),$(bin_for_test))

--
2.41.0
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 0/2] libdom: fix two more libxml parser segfaults

The libsvgtiny test suite exposes two segfaults in libdom's libxml2
parser. The first I'm somewhat confident in: linking dom/xml nodes
can fail (or never happen), and if we encounter an unlinked node,
something is wrong. Reasonable enough.

The second was easy to fix, but I'm not as sure that the fix is
correct. There's a branch where we jump to parent->children if we
can't find an earlier element node, and in at least one case, there
are no such children. Should there be? Adding a NULL check avoids a
segfault, but maybe we should notice the problem sooner.

Michael Orlitzky (2):
bindings/xml/libxml_xmlparser.c: fix segfault due to unlinked parent
bindings/xml/libxml_xmlparser.c: fix segfault on malformed document

bindings/xml/libxml_xmlparser.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)

--
2.41.0
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 1/2] bindings/xml/libxml_xmlparser.c: fix segfault due to unlinked parent

The xml_parser_start_element_ns() function ultimately calls

xml_parser_add_node(parser, parent->_private, ...

when we encounter a new element-open tag, and xml_parser_add_node()
wants its second argument to be non-NULL. Specifically, foo->_private
should be the libdom counterpart to the libxml2 node foo, the
correspondence being maintained with xml_parser_link_nodes(). Yet
there are several error branches throughout the libxml2 bindings where
the call to xml_parser_link_nodes() is skipped; and moreover, the link
function can itself fail.

The libsvgtiny test suite contains several test cases that exhibit
that pathological behavior:

* test/ns-afl-svg/0341.svg
* test/ns-afl-svg/0846.svg
* test/ns-afl-svg/1105.svg
* test/ns-afl-svg/1358.svg
* test/ns-afl-svg/1571.svg
* test/ns-afl-svg/2026.svg
* test/ns-afl-svg/2040.svg
* test/ns-afl-svg/2209.svg
* test/ns-afl-svg/2210.svg
* test/ns-afl-svg/2529.svg
* test/ns-afl-svg/2607.svg

These all currently segfault (fail) the test suite when libdom was
built with WITH_LIBXML_BINDING=yes and WITH_EXPAT_BINDING=no. To
fix it, we look elsewhere in the libxml2 bindings, and see that
xml_parser_end_element_ns() already has a check for an unlinked
element,

/* If node wasn't linked, we can't do anything */
if (node->_private == NULL) {
parser->msg(DOM_MSG_WARNING, parser->mctx,
"Node '%s' not linked", node->name);
return;
}

Borrowing this for xml_parser_start_element_ns() and applying it to
the "parent" pointer avoids the issue, changing each segfault into a
svgtiny_LIBDOM_ERROR.
---
bindings/xml/libxml_xmlparser.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/bindings/xml/libxml_xmlparser.c b/bindings/xml/libxml_xmlparser.c
index d43c459..57f3f47 100644
--- a/bindings/xml/libxml_xmlparser.c
+++ b/bindings/xml/libxml_xmlparser.c
@@ -419,6 +419,13 @@ void xml_parser_start_element_ns(void *ctx, const xmlChar *localname,
parent = (xmlNodePtr) parser->xml_ctx->myDoc;
}

+ /* If parent isn't linked, we can't do anything */
+ if (parent->_private == NULL) {
+ parser->msg(DOM_MSG_WARNING, parser->mctx,
+ "Node '%s' not linked", parent->name);
+ return;
+ }
+
if (parent->type == XML_DOCUMENT_NODE ||
parent->type == XML_ELEMENT_NODE) {
/* Mirror in the DOM all children of the parent node
--
2.41.0
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 2/2] bindings/xml/libxml_xmlparser.c: fix segfault on malformed document

At the end of xml_parser_start_element_ns(), we try to iterate from
some previous node "n" up to the current one, adding elements to the
DOM one-at-a-time:

/* Now, mirror nodes in the DOM */
for (; n != parser->xml_ctx->node; n = n->next) {
xml_parser_add_node(parser, parent->_private, n);
}

In at least one case, test/ns-afl-svg/2495.svg from the libsvgtiny
test suite, we find ourselves in this situation when n is equal to
parent->children, but n->next is NULL. Thus we wind up passing NULL to
xml_parser_add_node(), and ultimately, segfaulting.

Checking for n != NULL in the loop avoids the crash, causing the
libsvgtiny test to return svgtiny_LIBDOM_ERROR instead.
---
bindings/xml/libxml_xmlparser.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/bindings/xml/libxml_xmlparser.c b/bindings/xml/libxml_xmlparser.c
index 57f3f47..13e4858 100644
--- a/bindings/xml/libxml_xmlparser.c
+++ b/bindings/xml/libxml_xmlparser.c
@@ -449,11 +449,16 @@ void xml_parser_start_element_ns(void *ctx, const xmlChar *localname,
n = n->next;
}

- /* Now, mirror nodes in the DOM */
- for (; n != parser->xml_ctx->node; n = n->next) {
+ /* Now, mirror nodes in the DOM. We check for n !=
+ NULL because in pathological cases, we can have a
+ valid n == parent->children pointer from above
+ having n->next == NULL; we would never reach
+ parser->xml_ctx->node by iterating forward. */
+ while (n != NULL && n != parser->xml_ctx->node) {
xml_parser_add_node(parser,
(struct dom_node *) parent->_private,
n);
+ n = n->next;
}
}

--
2.41.0
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/1] libdom: handle empty document with libxml

On Tue, 8 Aug 2023 at 19:46, Michael Orlitzky <michael@orlitzky.com> wrote:
>
> Thanks. Unsurprisingly, it was PEBKAC. I was accidentally running "make
> test" with COMPONENT_TYPE=lib-shared.

No worries!

Thank you for all your patches! I reviewed them and they were all good.
I've pushed them.

Best regards,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/1] libdom: handle empty document with libxml

On Mon, 2023-08-07 at 20:42 +0100, Michael Drake wrote:
>
> You should just need to run `make test` with all the necessary
> dependencies installed.
>

Thanks. Unsurprisingly, it was PEBKAC. I was accidentally running "make
test" with COMPONENT_TYPE=lib-shared.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/1] libdom: handle empty document with libxml

On Sun, 6 Aug 2023 at 01:52, Michael Orlitzky <michael@orlitzky.com> wrote:

> I encountered a segfault while trying to parse an empty file with
> libsvgtiny that I traced back to libdom. It looks like a missing NULL
> check is to blame. I have yet to (figure out how to) run the libdom
> test suite however, so caveat emptor.

You should just need to run `make test` with all the necessary
dependencies installed.

You can see the list of deps installed here:
https://source.netsurf-browser.org/libdom.git/tree/.github/workflows/build.yaml#n30

Thanks for your patches. I'll try to review them over the next few days.

Best regards,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 1/4] README: update LIBXML -> LIBDOM

This constant svgtiny_LIBXML_ERROR was changed throughout the codebase
to svgtiny_LIBDOM_ERROR a long time ago, in 9275ab308, but the README
was missed because nobody reads the documentation :)
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 3c5095a..82a5df8 100644
--- a/README
+++ b/README
@@ -160,7 +160,7 @@ returned, but the diagram is still valid up to the point of the
error. The error is recorded in diagram->error_message and the line
that caused it in diagram->error_line.

-svgtiny_LIBXML_ERROR indicates that parsing the XML failed. The
+svgtiny_LIBDOM_ERROR indicates that parsing the XML failed. The
returned diagram will contain no shapes. svgtiny_NOT_SVG means that
the XML did not contain a top-level <svg> element.

--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 3/4] examples/svgtiny_display_x11.c: add missing stdlib.h include

This file uses malloc(), free(), and exit() -- all of which are
defined in stdlib.h. GCC seems unhappy about the situation, so we now
include it. This allows the file to be compiled once again.
---
examples/svgtiny_display_x11.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/examples/svgtiny_display_x11.c b/examples/svgtiny_display_x11.c
index c8bafd5..6758bef 100644
--- a/examples/svgtiny_display_x11.c
+++ b/examples/svgtiny_display_x11.c
@@ -23,6 +23,7 @@
#include <math.h>
#include <stdbool.h>
#include <stdio.h>
+#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 4/4] examples/svgtiny_display_x11.c: include the system copy of svgtiny.h

The header of this file includes instructions for how to build it:

Compile using:
gcc -g -W -Wall -o svgtiny_display_x11 svgtiny_display_x11.c \
`pkg-config --cflags --libs libsvgtiny cairo` -lX11

That pkg-config command will generate the flags to link against the
installed copy of libsvgtiny. The line,

#include "svgtiny.h"

on the other hand, attempts to use a local header. This commit changes
that line to,

#include <svgtiny.h>

which will use the corresponding system header from whatever include
directory pkg-config hands us for libsvgtiny.
---
examples/svgtiny_display_x11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/svgtiny_display_x11.c b/examples/svgtiny_display_x11.c
index 6758bef..463beb8 100644
--- a/examples/svgtiny_display_x11.c
+++ b/examples/svgtiny_display_x11.c
@@ -32,7 +32,7 @@
#include <X11/keysym.h>
#include <cairo.h>
#include <cairo-xlib.h>
-#include "svgtiny.h"
+#include <svgtiny.h>


struct svgtiny_diagram *diagram;
--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 0/4] fix the example program

A few miscellaneous changes that I needed to get the example program
working again.

Michael Orlitzky (4):
README: update LIBXML -> LIBDOM
examples/svgtiny_display_x11.c: update LIBXML -> LIBDOM
examples/svgtiny_display_x11.c: add missing stdlib.h include
examples/svgtiny_display_x11.c: include the system copy of svgtiny.h

README | 2 +-
examples/svgtiny_display_x11.c | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)

--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 0/1] libdom: handle empty document with libxml

I encountered a segfault while trying to parse an empty file with
libsvgtiny that I traced back to libdom. It looks like a missing NULL
check is to blame. I have yet to (figure out how to) run the libdom
test suite however, so caveat emptor.

Michael Orlitzky (1):
bindings/xml/libxml_xmlparser.c: handle an empty document

bindings/xml/libxml_xmlparser.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 1/1] bindings/xml/libxml_xmlparser.c: handle an empty document

The xml_parser_end_document() function tries to retrieve the XML node
using dom_node_get_user_data() after the parser has finished. It
checks the return value of that function, but not the true result (a
node pointer), which is itself passed in via a pointer. This goes
wrong when the returned pointer is NULL and unusable, because the
return value is always DOM_NO_ERR (meaning everything was OK).

This problem manifests as a segfault (null dereference) if you try to
parse an empty document using the libxml bindings. It is fixed by
adding a NULL check.
---
bindings/xml/libxml_xmlparser.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bindings/xml/libxml_xmlparser.c b/bindings/xml/libxml_xmlparser.c
index 02b8a34..d43c459 100644
--- a/bindings/xml/libxml_xmlparser.c
+++ b/bindings/xml/libxml_xmlparser.c
@@ -346,7 +346,11 @@ void xml_parser_end_document(void *ctx)
/* Get XML node */
err = dom_node_get_user_data((struct dom_node *) parser->doc,
parser->udkey, (void **) (void *) &node);
- if (err != DOM_NO_ERR) {
+
+ /* The return value from dom_node_get_user_data() is always
+ * DOM_NO_ERR, but the returned "node" will be NULL if no user
+ * data is found. */
+ if (err != DOM_NO_ERR || node == NULL) {
parser->msg(DOM_MSG_WARNING, parser->mctx,
"Failed finding XML node");
return;
--
2.39.3
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org