Navigating to page with non-successful response seems to reload javascript #1190
Comments
|
@RemcodM can you provide a minimal rails app showcasing the problem? |
|
I've also been seeing the same re-evaluation of scripts on our Drupal site: you can trigger the re-evaluation by going to any article (e.g. the Omnipedia article) and clicking the Edit tab which gives you a 403 error; after navigating to one or two other 200 response links, you'll start seeing the console debug messages duplicate. I can try and put together a reduced test case when I have some time. |
|
I just poked around in the Firefox dev tools a bit to try and see what's going on, and what I noticed is that the |
|
Yes, Turbo does this intentionally when you mark a script tag with |
|
I'm going to close this, since it seems expected behavior. But feel free to reopen with a test case if you find a bug. |
|
@afcapel We don't mark the scripts with the attribute at all if you view source, and what occurs is still a Turbo visit, not a full page load. If this was intended behaviour, shouldn't it force a full page load instead of doing a Turbo visit? |
|
Seems that you have a meta tag with data-turbo-track="reload"? 
I'd try removing it and see if that helps. But, also, as I said, happy to reopen the issue if you can provide a minimal reproduction. |
|
@afcapel I just tried removing it but it had no effect. That meta tag only ever changes when navigating between the site front-end and admin sections, where the Drupal theme changes and it does force a full page load as it's supposed to, so I would have been surprised if it had an effect. I appreciate you getting back to me, and I'll see if I can throw together a minimal reproduction. |
|
So I did some debugging in dev tools and discovered that the turbo/src/core/drive/error_renderer.js Line 18 in 861fcca This probably makes sense for some apps, but in our cases it seems like it's creating a weird in between state where a full page load has not occurred so scripts executed previously still linger in the JavaScript environment but the scripts get re-evaluated by turbo/src/core/drive/error_renderer.js Line 13 in 861fcca In our Drupal app, the 4xx pages contain the same linked JavaScript files as most other pages, so this means Turbo re-evaluates all the same JavaScript files on an error response. The full stack trace: Using that clue, I took a look at Line 219 in 861fcca and replaced that line with: await this.renderPageSnapshot(PageSnapshot.fromHTMLString(responseHTML), false);reloaded the page, and bingo, it no longer re-evaluates all of our JavaScript no matter how many 4xx error pages I visit. It's probably not the best way to do this and may break stuff I'm not aware of. Given that, is there a way to configure Turbo to use the normal renderer rather than the error renderer? |
hotwired/turbo#1190 Also combined patches into one file to keep things simple.
We are using Turbo Drive 7.3.0, but is also happens on our 8.0.2 branch that we are working on.
In some cases, when navigating with Turbo Drive, we can navigate to a page returning a non-successful error response, such as a error 403 because the user has no permission to that page.
When this happens, Turbo does not seem to keep track of the script tags in the header correctly. They seem to be evaluated on top of the existing JavaScript, causing all kinds of issues, such as:
Uncaught SyntaxError: redeclaration of const ...We are using
data-turbo-track="reload"on our scripts, however, the assets have not been changed between the requests. So we do not expect a reload at all.The problem does not seem to occur once we return the forbidden page with a successful response code (200). Once we change it back to 403, or even 404, 400 or 500, the problem returns.
The text was updated successfully, but these errors were encountered: