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
Monday, 28 August 2023
Sunday, 27 August 2023
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
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
>
> 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
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
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
Monday, 14 August 2023
[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
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
Friday, 11 August 2023
[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
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
Subscribe to:
Comments (Atom)