Redirect links break history-backwards

[aartaka]

Describe the bug It often happens with me that I open some link with redirection (think GitHub notification links) that redirect to a seemingly benign part of a page with a different fragment URL or a different query parameter set. Somewhy, Nyxt history mechanisms (not sure which part—htree, quri, nyxt/history-mode, or whatever) don't recognize the redirection and seem to store only the first link in history, not storing the link to where the redirection happened.

Storing just the initial redirection link kills history, because when going history-backwards to those, Nyxt starts following the redirection links and end up in the same place it started from. Bruh.

Precise recipe to reproduce the issue

• Open Nyxt.
• Go to GitHub.
• Open notifications menu.
• Follow some link to a PR/issue there.
• Wait until the page fully loads.
• Call history-backwards.
• Notice that nothing happened, except for some loading messages in the message buffer.

Information

• OS name+version: GuixSD

$ guix describe
Generation 9	Nov 20 2022 08:17:15	(current)
  guix 8cef05b
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8cef05bab6251978018ccab7bb44883676ce8f6c
  games 66fe8b7
    repository URL: https://gitlab.com/guix-gaming-channels/games
    branch: master
    commit: 66fe8b72d114ee2de218fc46d0f7ad95d8b3129e
  aartaka 8b072df
    repository URL: https://github.com/aartaka/guix-channel
    branch: master
    commit: 8b072dfd03588b3134303d298313b81f7be3a439
  chur 8fcb5dd
    repository URL: https://github.com/aartaka/chur-guix
    branch: master
    commit: 8fcb5ddaa15fd10d71c1e50950405bb6d48e4393
  nonguix f3227e3
    repository URL: https://gitlab.com/nonguix/nonguix
    branch: master
    commit: f3227e33d1782508bbf530de61fa3a8bda253423

• Graphics card and driver: Intel UHD 620, i915

$ lspci -v
...
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics (rev 01) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 5089
	Flags: bus master, fast devsel, latency 0, IRQ 165
	Memory at 601c000000 (64-bit, non-prefetchable) [size=16M]
	Memory at 4000000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915
...

• Desktop environment / Window manager name+version: StumpWM 20.11
• How you installed Nyxt (Guix pack, package manager, build from source): guix package -f nyxt.scm
• Information from show-system-information:

Nyxt version: 3
Renderer version: GI-GTK
Operating system kernel: Linux 6.0.7
Lisp implementation: SBCL 2.2.10 (Dynamic space size: 3221225472)
Features: (:QUICKLISP :NYXT-GI-GTK :NYXT-GTK :NYXT-3 :CUSTOM-HASH-TABLE-NATIVE
 :CLIPBOARD-CONTENT-METHOD :SLYNK :PLUMP-UTF-32 :PARENSCRIPT :NSYMBOLS
 :FSET-EXT-STRINGS :SBCL+SAFE-STANDARD-READTABLE :NAMED-READTABLES :GLOBAL-VARS
 :SWANK :CL-FAD :LPARALLEL :21BIT-CHARS :CL-PPCRE-UNICODE :CL-UNICODE
 :CL-JSON-DOUBLE-FLOAT-IS-SUBSUMED :CL-JSON-SINGLE-FLOAT-IS-SUBSUMED :CL-PPCRE
 :CHUNGA :FLEXI-STREAMS :WEBKIT2 :WEBKIT2-2.36 :WEBKIT2-CORS-ALLOWLIST
 :WEBKIT2-PASTE-PLAINTEXT :WEBKIT2-TRACKING :WEBKIT2-MUTE :WEBKIT2-EMOJI
 :WEBKIT2-MEDIA :WEBKIT2-SANDBOXING :GTK-3-22 :GTK-3-20 :GTK-3-18 :GTK-3-16
 :GTK-3-14 :GTK-3-12 :GTK-3-10 :GTK-3-8 :GTK-3-6 :GTK-3-4 :GTK :GDK-3-22
 :GDK-3-20 :GDK-3-18 :GDK-3-16 :GDK-3-14 :GDK-3-12 :GDK-3-10 :GDK-3-8 :GDK-3-6
 :GDK-3-4 :CAIRO-1-10 :CAIRO-1-12 :GDK-PIXBUF :CLOSER-MOP :GLIB-2-30 :GLIB-2-32
 :GLIB-2-34 :GLIB-2-36 :GLIB-2-38 :GLIB-2-40 :GLIB-2-42 :GLIB-2-44 :GLIB-2-46
 :GLIB-2-48 :GLIB-2-50 :GLIB-2-52 :GLIB-2-54 :GLIB-2-56 :GLIB-2-58 :GLIB
 :BORDEAUX-THREADS :LPARALLEL.WITH-CLTL2 :LPARALLEL.WITH-CAS
 :LPARALLEL.WITH-STEALING-SCHEDULER :SPLIT-SEQUENCE
 CFFI-FEATURES:FLAT-NAMESPACE CFFI-FEATURES:X86-64 CFFI-FEATURES:UNIX :CFFI
 CFFI-SYS::FLAT-NAMESPACE ALEXANDRIA::SEQUENCE-EMPTYP :FAST-IO-SV :FAST-IO
 :ASDF-SYSTEM-CONNECTIONS :CL-JSON-CLOS :CL-JSON :SBCL-USES-SB-ROTATE-BYTE
 CHIPZ-SYSTEM:GRAY-STREAMS :THREAD-SUPPORT :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3
 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC
 :64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
 :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
 :SB-THREAD :SB-UNICODE :SBCL :UNIX)

ASDF version: 3.3.5
ASDF registries: (NYXT-SOURCE-REGISTRY ENVIRONMENT-SOURCE-REGISTRY USER-SOURCE-REGISTRY
                      USER-SOURCE-REGISTRY-DIRECTORY
                      DEFAULT-USER-SOURCE-REGISTRY SYSTEM-SOURCE-REGISTRY
                      SYSTEM-SOURCE-REGISTRY-DIRECTORY
                      DEFAULT-SYSTEM-SOURCE-REGISTRY)
Critical dependencies: (/gnu/store/0i5m73f626jhibrc7lzfcsihymjj6l1g-cl-cffi-gtk-0.11.2-2.e9a46df/share/common-lisp/source/cl-cffi-gtk/gtk/cl-cffi-gtk.asd
 /gnu/store/ywvnpy9gzq22c8p5aaix4x8j8d8k2yg1-cl-gobject-introspection-0.3-1.d0136c8/share/common-lisp/source/cl-gobject-introspection/cl-gobject-introspection.asd
 /gnu/store/kxwqmvla0kg3h7agz7ppnl43qr9y5rnf-cl-webkit-3.5.6/share/common-lisp/source/cl-webkit/webkit2/cl-webkit2.asd)

Guix version: 

Output when started from a shell

[aadcg]

Do you really mean redirection here? A redirection is an alias for an URL. For instance, https://tomato.com can have a redirection to https://potato.com.

From history's perspective, two URLs that differ exclusively by query and/or fragment are distinct. In other words, every node of following navigation flow https://tomato.com -> https://tomato.com#Taste -> https://tomato.com?feed-me-tomato should be registered and it should be possible to reverse the flow.

[aartaka]

But opening any of the links but the last one will trigger the same chain of redirection until you're on the last link. That's why it's important that history is aware of redirections OR we never allow it to store the redirecting URL. Otherwise we end up with non-navigable history, which triggers lots of redirections and never gets you back in history properly.

[aadcg]

But opening any of the links but the last one will trigger the same chain of redirection until you're on the last link.

I don't follow. Maybe an example would help.

Also, I don't understand what you mean by a redirection. I define it as:

A redirection is an alias for an URL. For instance, https://tomato.com can have a redirection to https://potato.com

Therefore, https://tomato.com#taste is not a redirection.

[aartaka]

So, in your terms, we either should mark alias URLs as such, or ignore all the alias URLs whatsoever.

[aartaka]

Because opening an alias URL will make us get to an aliased URL unconditionally, thus interfering with the history-backwards movement and making it useless.

[aadcg]

Dealing with alias URLs is indeed not an easy task. Right now, I can't help much unfortunately. As a last resort, we could find some kind of heuristic along the lines of "if this URL was set for a short time interval, then regard it as a redirection". But my educated guess is that when making a HTTP(S) request, it is somehow possible to infer from the server reply whether there will be a redirection. Renderers must deal with this I suppose.

But I think there's a simpler and more important issue that we could prioritize:

every node of following navigation flow https://tomato.com -> https://tomato.com#Taste -> https://tomato.com?feed-me-tomato should be registered and it should be possible to reverse the flow.

As always, this could be a user option. The default behavior should be as I describe above since that's what most browsers do.