[bug] translateHref is using the wrong context ($page) in preprocessor leading to invalid href/action urls

[savar]

Problem

At least (not tested with <a href="?some=var">) with <form action="?/myaction"> when navigating from one page to another where such a <form> is defined, the action gets prefixed (as long as not disabled via data-no-translate) with the path of the previous page I was coming from.

This can be seen even on the playground example.

If starting on a page /about

and then going to Sverdle by clicking on the link, the form gets the wrong url:

so when filling out the first line with chracters and then press the enter button

the action is not called on the /sverdle routing but on the /about routing:

While trying to debug, the preprocessor function translateHref() in ParaglideJS.svelte showed that the $page object was still having in the .url the previous url (so here the /about) instead of the (already in the browser url visible) /sverdle.

We saw that in our own project initially but as the example project shows the same behaviour, I hope it is easier to debug/hunt this down. Best guess: the preprocessor is called before the $page was updated or any kind of event is not working as expected.

If you reload the /sverdle page, then the url is correctly prefixed.

Expected behavior

Either that the correct prefix (the URL which is actually opened in that moment) is added or it stays relative and no URL is added at all (not sure though if this is the expected behaviour when it comes to translating URLs or good for SEO).

Reproduction

1. go to https://stackblitz.com/~/github.com/lorissigrist/paraglide-sveltekit-example

2. click on the ABOUT link at the top of the loaded test page

3. enter any word in the first row

4. press the ENTER button

5. you should see "METHOD NOT ALLOWED" as an error.

Other information

No response

[samuelstroschein]

@LorisSigrist off-topic [ no reply needed in this thread ]: the preprocessor seems to be the wrong architectural decision. we should probably push the svelte team to provide a native solution

• seems like most bugs come from preprocessing
• this situation reminds me of our first i18n lib that also used preprocessing and was ultimately scrapped because source code transformation leads to too many bugs

[LorisSigrist]

This has come up again
https://discord.com/channels/897438559458430986/1070750156644962434/1247865462637727755