Remove web extensions

[aartaka]

Description

This removes all the WebExtensions-related code from Nyxt, in favor of external libwebextensions (to be open-sourced separately).

Fixes #2917
Fixes #2114

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

• Git hygiene:
  • I have pulled from master before submitting this PR
  • There are no merge conflicts.
• I've added the new dependencies as:
  • ASDF dependencies,
  • Git submodules,

    cd /path/to/nyxt/checkout
    git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

  • and Guix dependencies.
• My code follows the style guidelines for Common Lisp code. See:
  • Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
  • Google Common Lisp Style Guide
• I have performed a self-review of my own code.
• My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
• Documentation:
  • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
  • I have updated the existing documentation to match my changes.
  • I have commented my code in hard-to-understand areas.
  • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
    • Changelog update should be a separate commit.
  • I have added a migration.lisp entry for all compatibility-breaking changes.
  • (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
• Compilation and tests:
  • My changes generate no new warnings.
  • I have added tests that prove my fix is effective or that my feature works. (If possible.)
  • I ran the tests locally ((asdf:test-system :nyxt) and (asdf:test-system :nyxt/gi-gtk)) and they pass.

[aadcg]

For future reference, @aartaka, would you like to briefly state why libwebextensions is superior to the strategy that is being removed in this PR?

Note that this PR is not complete. For instance, file INSTALL has references to web extensions. I'd suggest carefully grepping through the repository.

[aartaka]

For future reference, aartaka, would you like to briefly state why libwebextensions is superior to the strategy that is being removed in this PR?

Sure! libwebextensions is more embeddable, self-contained, and much more maintainable due to being written in Scheme instead of C.

Note that this PR is not complete. For instance, file INSTALL has references to web extensions. I'd suggest carefully grepping through the repository.

Done.

[aadcg]

@aartaka take a closer look at INSTALL or class gtk-extensions-directory in gtk.lisp.

[aadcg]

@aartaka should this PR close #2114?

[aartaka]

Okay, bot of the cases (INSTALL and gtk-extensions-directory) are covered. I've also grep-ped a bit and fixed some small remaining mentions. Rebased over master. Ready for review/merge.

[aadcg]

@aartaka please double-check. Thanks.

[aartaka]

@aartaka please double-check. Thanks.

The only ones I can find are:

• Mention of WebExtensions in the manual section of user scripts.
• Mention of WebKitWebExtensions in renderer/gtk.

Am I missing something?

[aadcg]

Is gtk-extensions-directory from gtk.lisp related to web extensions? It is still in the sources.

[aartaka]

Is gtk-extensions-directory from gtk.lisp related to web extensions? It is still in the sources.

It's related to WebKitWebExtensions, not WebExtensions. These two are distinct entities. The former is the extension mechanism provided by WebKitGTK and working as shared libraries loaded at runtime. The latter is JavaScript-based conventional architecture for browser extensions supported by major browsers like Mozilla Firefox and Google Chrome.

[aadcg]

I'm still confused.

From the INSTALL file:

By default the GTK renderer loads the libnyxt library (enabling WebExtension
support) relatively to the nyxt.asd location. You can also configure this at
runtime through the gtk-extensions-directory resolve method.

This seems to suggest that gtk-extensions-directory is indeed related to libnyxt (libraries/web-extensions), which this PR deletes.

[aartaka]

You sure you're checking the right branch? 2c94866 removes this snippet.

[aadcg]

Yes, I am checking the right branch. Let me rephrase my previous question since there was a misunderstanding.

If the snippet from INSTALL has been deleted and it references gtk-extensions-directory, what justifies the need for gtk-extensions-directory in gtk.lisp? I believe the answer is that it is an entry point for WebKitWebExtension (which differ from WebExtensions). My question is: what value do we get from having this entry point for WebKitWebExtensions? It seems that, in the past, it was used exclusively for libnyxt, i.e. it was meant for supporting WebExtensions. Put differently, now that we're not going to pursue WebExtensions in that fashion, what justifies the need for the entry point?

[aartaka]

My question is: what value do we get from having this entry point for WebKitWebExtensions? It seems that, in the past, it was used exclusively for libnyxt, i.e. it was meant for supporting WebExtensions. Put differently, now that we're not going to pursue WebExtensions in that fashion, what justifies the need for the entry point?

It's useful to allow other kinds of WebKit extensions, like blockit etc. Just to be a good WebKitGTK browsers citizen.

[aadcg]

@aartaka this is not on topic, but it follows from the piece of information that you have shared. This has been looking at us all along then. There are webkitgtk-specific extensions such as blockit that would add great value to Nyxt. Ad blocking extensions are the most requested kind of extension. How hard would it be to support blockit in Nyxt? Maybe we should open an issue about it.

---

I'll do a final review and merge.

[aadcg]

I've added the changelog myself, but please take it into account for the future.

Great, the codebase is now a little bit lighter!

[aartaka]

aartaka this is not on topic, but it follows from the piece of information that you have shared . This has been looking at all along then. There are webkitgtk-specific extensions such as blockit that would add great value to Nyxt. Ad blocking extensions are the most requested kind of extension. How hard would it be to support blockit in Nyxt? Maybe we should open an issue about it.

It shouldn't be a problem. You just drop the extension into the extension dir, setup the initialization data (you don't need that in case of blockit; in most cases really), and run Nyxt. WebKit will do the rest. The only difficulty with blockit was that it's build with Rust, which is extremely hard to work with on Guix. I was unable to compile and test blockit because of that.