[netsurf-dev] [PATCH] Fix comment typos

---
content/content_protected.h | 2 +-
content/handlers/image/webp.c | 2 +-
frontends/windows/font.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/content/content_protected.h b/content/content_protected.h
index fd0924d64..ce2a34cfe 100644
--- a/content/content_protected.h
+++ b/content/content_protected.h
@@ -120,7 +120,7 @@ struct content_handler {
*
* \param c The content being redrawn
* \param start_idx The start index of the text region to be redrawn
- * \param end_idx The end index of teh text region to be redrawn
+ * \param end_idx The end index of the text region to be redrawn
* \return NSERROR_OK on success else error code
*/
nserror (*textselection_redraw)(struct content *c, unsigned start_idx, unsigned end_idx);
diff --git a/content/handlers/image/webp.c b/content/handlers/image/webp.c
index c04c0efd2..32988516f 100644
--- a/content/handlers/image/webp.c
+++ b/content/handlers/image/webp.c
@@ -178,7 +178,7 @@ webp_cache_convert(struct content *c)
* demand.
*
* \param c The webp content object
- * \return true on successful processing of teh webp content else false
+ * \return true on successful processing of the webp content else false
*/
static bool webp_convert(struct content *c)
{
diff --git a/frontends/windows/font.c b/frontends/windows/font.c
index 3e81a80a1..91e05b16e 100644
--- a/frontends/windows/font.c
+++ b/frontends/windows/font.c
@@ -303,7 +303,7 @@ win32_font_split(const plot_font_style_t *style,
nserror res;
int c_off;

- /* get the offset into teh string on the proposed position */
+ /* get the offset into the string on the proposed position */
res = win32_font_position(style, string, length, x, offset, actual_x);
if (res != NSERROR_OK) {
return res;
--
2.46.2

[netsurf-dev] Re: Improve french translation

Hello,

Thank you very much for your review and integration of work. And
sorry to not have answered you sooner. Time flies very fast those
days…

My other patches are almost independent. I took time to rebase my
branch on the last state of master, if one want to have a look on
them? I explain bellow what they are about.

-
https://git.umaneti.net/netsurf/commit/?h=french-translation&id=f0e7fe3b9f30d6a5fce9c76b28b01db88af11092
This one is completely independent and fix a little typo in
content/fetchers/about/certificate.c (i.e. replace Privince by
Province in the certificate display UI). It also changes
a little the html used to display the nice version of the
certificate date: it ensure the page will be rendered as UTF-8,
what will avoid to display garbage characters if translation
contains non-ascii chars (accent…).

-
https://git.umaneti.net/netsurf/commit/?h=french-translation&id=88ddca04133f24d872db2e4fb9a68c85f0ad285f
This one make it possible to translate the "page info" widget
(the drawer opened by clicking on the netsurf icon or the
padlock to the left of the current uri in the uri bar). In the
same time I propose the first translated string for English
(extracted from previous source code), french (my language) and
some italian string available for the same context at other
place.

-
https://git.umaneti.net/netsurf/commit/?h=french-translation&id=5dc7e57897e47617d5a38adbb3892eebc7c6c465
https://git.umaneti.net/netsurf/commit/?h=french-translation&id=8fcca14770612a1fa838d24aa6e3275e46a971d1
https://git.umaneti.net/netsurf/commit/?h=french-translation&id=2614225923d83f46215c13c249ee7d4679373138
Those 3 commits should be added in this order to avoid conflicts
in fatmessage. They allow some forgotten part of the gtk3
frontend to be translated. Each commit is for a specific
page/widget and directly propose the missing labels for
fatmessage. I reused a lot of label from other frontends.

Let me know if you prefer those patch to be send differently, or
to propose changes on them.

Again, thank you very much for all your hard work!

Étienne

mardi 05 mars 2024 à 23:18, jmb@netsurf-browser.org a écrit :

> On 19/02/2024 15:12, Étienne Deparis wrote:
>> Hi there,
>> Since a few weeks I've been working on improving the french
>> translation
>> of the browser.
>> Being a Linux user, I've been more involved in the gtk3
>> frontend,
>> however I tried to also review strings for other frontends as
>> well. What
>> I mean is that I've only take care to compile and visually
>> check the
>> result of my changes with a gtk3 build, and thus cannot
>> guarantee my
>> other fixes respect the display on other systems (utf8 support,
>> string
>> length, wording habbit…). I'd be very happy to improve my copy
>> with any
>> feedback.
>> You can find these changes under the two following patches (may
>> be
>> applied in any order):
>> - for FatMessages:
>>  https://git.umaneti.net/netsurf/patch/?id=a95d5cabb787a9b6116045d334bb0781022a65ab
>> - for builtin html pages:
>>  https://git.umaneti.net/netsurf/patch/?id=0169b12fc8ca2ea9607da8465817b398f999980b
>>
>
> Thank you for these -- they have been applied in:
>
> https://git.netsurf-browser.org/netsurf.git/commit/?id=5bb2e9de3c3787d9425c1c8ba39802c75711c380
>
> and
>
> https://git.netsurf-browser.org/netsurf.git/commit/?id=583ec7268083fa2f4005067e0314ff9a56e62664
>
> respectively.
>
>> I also maintain a branch (including the previous patches) with
>> other
>> translation related improvement (like allowing the translation
>> of the
>> gtk3 history, cookies and bookmark windows, or the infopage
>> widget).
>> Let me know if I can already transmit those patches as well or
>> if you
>> prefer digest them one at a time (all my changes are in atomic
>> commit,
>> but order might be import).
>
> If they're independent of each other, by all means send them
> over
> as-is. Alternatively, if there are ordering constraints, let us
> know and
> I expect we can work with that, too.
>
> Many thanks,
>
>
> John-Mark.

[netsurf-dev] matches

Hello,
I want to add Element.matches to "my" browser based on the netsurf code.
The idea is:
generate the css rule:
$selector {color:#123456}

then for the given node, check whether computed css color is #123456.
It even works, but subsequent calls to this function cause memory leaks, which
I don't know how to resolve.

Code of this function looks like this.

void *
el_match_selector(const char *selector, void *node)
{
struct string text;
css_error code;
size_t size;
uint32_t count;
css_stylesheet_params params;
css_stylesheet *sheet = NULL;
css_select_ctx *select_ctx = NULL;
css_select_results *style = NULL;
uint8_t color_type;
css_color color_shade;

css_media media = {
.type = CSS_MEDIA_SCREEN,
};

css_unit_ctx unit_len_ctx = {0};
unit_len_ctx.viewport_width = 800; // TODO
unit_len_ctx.viewport_height = 600; // TODO
unit_len_ctx.device_dpi = F_90; //device_dpi;

/** \todo Change nsoption font sizes to px. */
/// f_size = FDIV(FMUL(F_96, FDIV(INTTOFIX(nsoption_int(font_size)), F_10)), F_72);
/// f_min = FDIV(FMUL(F_96, FDIV(INTTOFIX(nsoption_int(font_min_size)), F_10)), F_72);

unsigned int f_size = FDIV(FMUL(F_96, FDIV(INTTOFIX(50), F_10)), F_72); // TODO
unsigned int f_min = FDIV(FMUL(F_96, FDIV(INTTOFIX(50), F_10)), F_72); // TODO

unit_len_ctx.font_size_default = f_size;
unit_len_ctx.font_size_minimum = f_min;
void *ret = NULL;

params.params_version = CSS_STYLESHEET_PARAMS_VERSION_1;
params.level = CSS_LEVEL_21;
params.charset = "UTF-8";
params.url = "foo";
params.title = "foo";
params.allow_quirks = false;
params.inline_style = false;
params.resolve = resolve_url_empty;
params.resolve_pw = NULL;
params.import = NULL;
params.import_pw = NULL;
params.color = NULL;
params.color_pw = NULL;
params.font = NULL;
params.font_pw = NULL;

if (!selector) {
return NULL;
}
if (!init_string(&text)) {
return NULL;
}
add_to_string(&text, selector);
add_to_string(&text, "{color:#123456}");

/* create a stylesheet */
code = css_stylesheet_create(&params, &sheet);

if (code != CSS_OK) {
goto empty;
}
code = css_stylesheet_append_data(sheet, (const uint8_t *) text.source, text.length);

if (code != CSS_OK && code != CSS_NEEDDATA) {
goto empty;
}
code = css_stylesheet_data_done(sheet);

if (code != CSS_OK) {
goto empty;
}
//code = css_stylesheet_size(sheet, &size);

/* prepare a selection context containing the stylesheet */
code = css_select_ctx_create(&select_ctx);

if (code != CSS_OK) {
goto empty;
}
code = css_select_ctx_append_sheet(select_ctx, sheet, CSS_ORIGIN_AUTHOR, NULL);

if (code != CSS_OK) {
goto empty;
}
// code = css_select_ctx_count_sheets(select_ctx, &count);
//
// if (code != CSS_OK) {
// goto empty;
// }
code = css_select_style(select_ctx, node, &unit_len_ctx, &media, NULL, &selection_handler, 0, &style);

if (code != CSS_OK) {
goto empty;
}
color_type = css_computed_color(style->styles[CSS_PSEUDO_ELEMENT_NONE], &color_shade);

if (color_type && color_shade == 0xff123456) {
ret = node;
}

empty:

if (style) {
css_select_results_destroy(style);
}

if (select_ctx) {
css_select_ctx_destroy(select_ctx);
}

if (sheet) {
css_stylesheet_destroy(sheet);
}
done_string(&text);

return ret;
}

css selection handler functions are copy of netsurf-3.11 code for CSS.

Here is output of valgrind --leak-check=full elinks -test 1 element.matches.html

==126177== Memcheck, a memory error detector
==126177== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==126177== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==126177== Command: elinks -test 1 element.matches.html
==126177== Parent PID: 1827
==126177==
==126182==
==126182== HEAP SUMMARY:
==126182== in use at exit: 2,837,840 bytes in 28,145 blocks
==126182== total heap usage: 70,221 allocs, 42,076 frees, 27,357,263 bytes allocated
==126182==
==126182== LEAK SUMMARY:
==126182== definitely lost: 0 bytes in 0 blocks
==126182== indirectly lost: 0 bytes in 0 blocks
==126182== possibly lost: 0 bytes in 0 blocks
==126182== still reachable: 2,837,840 bytes in 28,145 blocks
==126182== suppressed: 0 bytes in 0 blocks
==126182== Reachable blocks (those to which a pointer was found) are not shown.
==126182== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==126182==
==126182== For lists of detected and suppressed errors, rerun with: -s
==126182== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==126177==
==126177== HEAP SUMMARY:
==126177== in use at exit: 59,984 bytes in 109 blocks
==126177== total heap usage: 80,910 allocs, 80,801 frees, 33,543,836 bytes allocated
==126177==
==126177== 72 (56 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 18 of 36
==126177== at 0x48455EF: calloc (vg_replace_malloc.c:1328)
==126177== by 0x54079D2: css__create_node_data (select.c:144)
==126177== by 0x54079D2: css_select__initialise_selection_state (select.c:1089)
==126177== by 0x54079D2: css_select_style (select.c:1273)
==126177== by 0x1D1C13: el_match_selector (css.c:2503)
==126177== by 0x1733EA: js_element_matches (element.c:3356)
==126177== by 0x29568A: js_call_c_function (quickjs.c:15913)
==126177== by 0x25CA0A: JS_CallInternal (quickjs.c:16108)
==126177== by 0x25CD84: JS_CallInternal (quickjs.c:16515)
==126177== by 0x26476F: JS_CallFree (quickjs.c:18581)
==126177== by 0x2D29AC: JS_EvalFunctionInternal (quickjs.c:34211)
==126177== by 0x2D3AD3: __JS_EvalInternal (quickjs.c:34346)
==126177== by 0x2CFA5C: JS_EvalInternal (quickjs.c:34364)
==126177== by 0x2CFA5C: JS_EvalThis (quickjs.c:34395)
==126177== by 0x2CFA5C: JS_Eval (quickjs.c:34403)
==126177== by 0x16423D: quickjs_eval (quickjs.c:409)
==126177==
==126177== LEAK SUMMARY:
==126177== definitely lost: 56 bytes in 1 blocks
==126177== indirectly lost: 16 bytes in 1 blocks
==126177== possibly lost: 0 bytes in 0 blocks
==126177== still reachable: 59,912 bytes in 107 blocks
==126177== suppressed: 0 bytes in 0 blocks
==126177== Reachable blocks (those to which a pointer was found) are not shown.
==126177== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==126177==
==126177== For lists of detected and suppressed errors, rerun with: -s
==126177== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

element.matches.html looks like this:
<li id="a" class="e">Philippine eagle</li>
<script type="text/javascript">
console.error('element.matches.html');
var bird = document.getElementById('a');
bird.matches('li');
bird.matches('li');
console.exit();
</script>

If I comment the second bird.matches, there is no leak, so I guess the "problem" is somewhere in releasing memory of libcss.
Line number of libcss might be different than in libcss-0.9.2, because some debug statement were added.
Sorry for spam, but you wrote to ask first, not to ask for ask.
How to get clean (no leak) output from valgrind? How to release libcss memory between calls of el_match_selector?
Or do you have an idea how to implement Element.matches simpler?

--
Regards,
Witold Filipczyk

[netsurf-dev] Stretched SVG-images in current netsurf?

I just want to ask whether there is a known issue with aspect ratios of SVG images in current Netsurf? For example, the globe icon on Wikipedia is not completely round for me, but a bit stretched out in the x-axis. I noticed after merging commits (r.310+ --> r.311+) into our port to Plan 9, but looks similar in other frontends I tested (gtk, riscos and haiku).

On a glance, I  didn't find anything related in the bug tracker, and I also tried reverting libsvgtiny to an older version. So I'll ask before digging further, maybe I just missed something.

Best,

Jonas Amoson

[netsurf-dev] Re: netsurf: branch master updated. release/3.11-63-g553dc93ec

On 25/05/2024 12:06, NetSurf Browser Project (Commit Mailer) wrote:

> - Log -----------------------------------------------------------------
> commitdiff http://git.netsurf-browser.org/netsurf.git/commit/?id=553dc93ec8f414f475e4e6d5e66e0a7d6131da96
> commit 553dc93ec8f414f475e4e6d5e66e0a7d6131da96
> Author: Daniel Silverstone <dsilvers@digital-scurf.org>
> Commit: Daniel Silverstone <dsilvers@digital-scurf.org>
>
> nsurl: Add support for IPv6 literals
>
> Unfortunately, despite previous assertions to the contrary,
> we do need to deal with IPv6 literals. For now we validate
> just that they are encased by square brackets and consist only
> of hex digits and colons. We do not validate that they are
> actually valid IPv6 addresses.
>
> Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
>
> diff --git a/utils/nsurl/parse.c b/utils/nsurl/parse.c
> index 06b6601e0..541248e11 100644
> --- a/utils/nsurl/parse.c
> +++ b/utils/nsurl/parse.c
> @@ -1263,6 +1263,9 @@ void nsurl__calc_hash(nsurl *url)
> * Valid hostnames are valid DNS names. This means they must consist only of
> * the ASCII characters a-z A-Z 0-9 '.', '_', or '-'.
> *
> + * Unfortunately we also need to deal with IPv6 literals which are constrained
> + * but strange. Surrounded by '[' and ']' there are hex digits and colons
> + *
> * \param host The hostname to check
> * \return NSERROR_OK if the hostname is valid
> */
> @@ -1271,6 +1274,20 @@ static nserror nsurl__check_host_valid(lwc_string *host)
> const char *chptr = lwc_string_data(host);
> size_t nchrs = lwc_string_length(host);
>
> + if (*chptr == '[' && chptr[nchrs-1] == ']') {
> + /* Treat this as an IPv6 Literal */
> + chptr++;
> + nchrs -= 2;
> + while (nchrs--) {
> + const char ch = *chptr++;
> + if (!isxdigit(ch) && ch != ':') {
> + /* Not hex digit or colon */
> + return NSERROR_INVALID;
> + }
> + }
> + return NSERROR_OK;
> + }
> +
> while (nchrs--) {
> const char ch = *chptr++;
> if (!isalnum(ch) && !(ch == '.' || ch == '-' || ch == '_')) {

You probably want to use the locale-agnostic helpers in utils/ascii.h:

s/isalnum/ascii_is_alphanumerical/
s/isxdigit/ascii_is_hex/

Otherwise, the behaviour of nsurl__check_host_valid will depend upon the
locale, which is rarely what we want anywhere in NetSurf.


J.

[netsurf-dev] Re: [PATCH] Custom memory functions

Dnia Wed, May 01, 2024 at 03:03:27PM +0100, John-Mark Bell napisał(a):
> On 01/05/2024 10:23, Witold Filipczyk (witekfl) wrote:
> > Hello,
> > I want to add custom memory allocators like in other libraries.
> > This will help to debug possible memory leaks in programs.
> > First parserutils. It is based on curl.
> >
> > Will you accept such patches?
>
> We used to have such a thing in most of the libraries, but it resulted in a
> great deal of complexity for no real gain (particularly as memory leaks can
> be detected using tools such as libefence, valgrind, and asan, amongst
> others).
>
> Custom allocator support was removed from libparserutils here: https://git.netsurf-browser.org/libparserutils.git/commit/?id=8e48b931091cbc99abeffacc7af80f363495ec23
>
> I don't think we want to reintroduce any of these (as libefence and friends
> demonstrate, you can inject your own allocator anyway via LD_PRELOAD (if
> dynamically linking) or by statically linking against libefence, whose
> symbols should bind tighter than those in the C runtime library.

OK. Thanks.

BTW, gcc-14 reports inverted order of parameters for calloc as en error.
calloc(sizeof(*something), 1) BAD
calloc(1, sizeof(*something)) OK

Witold Filipczyk

[netsurf-dev] Re: [PATCH] libcss SVG properties fill, stroke and stroke-width

Hi Michael,

I am happy that this benefits you as well.

To provide some background, my own interest in libCSS is to implement
an "SVG agent" using Cairo and libxml2 with the final purpose of
embedding
the agent as a video game GUI[0].

With opacity, fill-opacity, stroke-opacity, fill, stroke and
stroke-witdth
is enough for me to render the iconic tiger.svg, but I am still far from
a MVP,
so that's why I may be adding more in the future. For now I need to
focus on some attributes,
viewBox for example and add some I/O to get to get to MVP.

Anyway, thanks for testing!

[0] https://github.com/AeonGames/AeonGUI

On 2024-05-02 18:22, Michael Orlitzky wrote:
> On Thu, 2024-05-02 at 17:20 -0600, Rodrigo Hernandez wrote:
>> Hello,
>>
>> The attached patch adds SVG properties fill, stroke and stroke-width
>> as
>> well as some basic tests to libCSS.
>>
>> I noticed that fill and stroke opacity were recently added, and I will
>> likely be adding more SVG related properties as needed,
>> Let me know if there is already an active effort to add more SVG props
>> not to duplicate any work.
>
> Thanks for doing this. My main motivation for adding SVG support to
> libcss (and CSS support to libsvgtiny) is to eventually use libsvgtiny
> as a non-rust replacement for librsvg in GTK. For that we need only two
> things[0],
>
> 1. <style> support in libsvgtiny via libcss
> 2. "fill" support in libcss
>
> I've done (1), and your patch should take care of (2). So thanks. I'll
> test it out when I can.
>
>
> [0]
> https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gdktextureutils.c#L224