Re: [hackers] [surf] [PATCH] Introduce JavaScriptMarkup option (limit site JS w/o user JS)

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Sun, 20 Apr 2025 17:43:46 +0200

> <noscript> tags (ugh, this one bites,)

That sounds meh indeed.

> > I think that's fine, as this was kind of happening before anyway,
> > and if we can remove that IPC between main and ext through
> > ugly glib, the better.
>
> Not sure I get this one. Why glib?

Because of the need for integrating into the main gtk loop,
look at the whole GIO madness (which doesn't work well too)
from pageusermessagereply().

> > - If we're going to have scrolling in main, let's remove the webext
> > entirely as it wouldn't be of use anymore (we can reintroduce it
> > later if needed).
> > That would mean altering the Makefile too, I could do it if you
> > want.
>
> For me, webext is not only this scrolling-enabling thing, but also an
> example for writing one's own webexts. So what we can do is removing
> the scrolling code from the webext and leaving most other code
> (extension initialization, page creation, message processing) intact
> for one to hack on merrily.

Maybe, but this is mostly already part of the webkitgtk documentation.
We could keep a skeleton on the side, but as a second time patch,
making clear we remove the main surf webext, while having a something
like a webext-example.c on the side.

> I didn't do this, because it's quite a far-reaching change that should
> better be discussed before implementing.

Sure, that's why we can discuss it :)

> > - Maybe it's not really useful to disable JavaScript (the original
> > one) entirely as it's needed for the core feature of being able to
> > scroll. Instead, we could substitute it for JavaScriptMarkup
> > directly.
>
> This is my doubt too. I opted for a separately toggled option because
> it seems useful (to a paranoid like me) to have a master override like
> JavaScript setting in addition to *-Markup one. But that also means
> that one can accidentally disable scrolling, which is not that
> intuitive.
>
> But the course of action with substituting JavaScript for
> JavaScriptMarkup in user-facing code (-Ss option, config examples
> maybe) seems most sane to me too.

Yeah, what could be done is to do the substitution regarding
the option handling and toggling,
while keeping both options for those who actually want it.

Then what could be useful is some comment somewhere,
eihter in the config.def.h directly, or the README.
Received on Sun Apr 20 2025 - 17:43:46 CEST