404 causes DOMException

[iamdriz]

I'm using the latest version of Turbo (beta 4 at the time of writing) and I've noticed that when you hit a 404 page it causes the following error in the console:

Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "turbo-frame" has already been used with this registry

This only happens when hitting a 404 from another link... if you refresh the non existent page the error doesn't happen.

[iamdriz]

If it helps here's a screenshot of exactly what happens in the console when the navigation to the non existent page happens:

[morindo]

I'm having the same problem using 7.0.0-beta.4 configured with Webpack in ASP.NET Core. Response with 404 and 500 status code seems to reload turbo.

[clinejj]

This looks to be related to #104 and a similar issue from Turbolinks: turbolinks/turbolinks#179

Essentially Turbo handles 404/500 pages differently, and ends up re-rendering the page and initializing itself twice which leads to these errors. Unfortunately, the monkey patch from the issue above doesn't work on Turbo (or I can't get it to work at least)

[clinejj]

I opened hotwired/turbo-rails#249 as this seems to be more of an issue with turbo-rails than Turbo, and the specific use case we're able to replicate on is using a custom error controller that has the same layout as our main application which includes turbo. Because the ErrorRender in Turbo reloads both the body and head, it leads to turbo-rails and turbo being initialized twice. It seems that Turbo is protected from this (here), but turbo-rails is not.

[tydoo]

Same problem with 7.0.1

[markdavies]

I am seeing the same issue in a non-Rails setup

[kmmbvnr]

I fixed this with data-turbo-eval="false" on the script tag with turbo bundle

<script src="{% static 'viewflow/js/turbo.es5-umd.js' %}" data-turbo-eval="false"></script>

[denydias]

This one is indeed a showstopper for anything handling 4xx and 5xx errors.

As @clinejj observed above, the monkey patch didn't work and it'll never work with Turbo. It turns out that HttpRequest class was removed altogether. But rather than what he also pointed out, it's not only turbo-rails related. Also, it's not limited to turbo-frame and turbo-stream as PR #483 address. My laravel project also suffers with the same 4xx and 5xx handling issues, while having no turbo-frame nor turbo-stream implemented. For my particular case, turbolinks HttpRequest monkey patch provides quite an easy and reliable fix.

It would be really nice from Turbo devs if they could elaborate a bit on the reasoning behind HttpRequest removal. It would be even nicer from their part if a workaround could be provided... It doesn't even need to be funcional code tho. A shallow overview would suffice for devs like us to figure out the rest.

[kidlj]

I'm having the same problem with "@hotwired/turbo": "^7.1.0", not on Rails framework.

After changing

import "@hotwired/turbo"

from index.js to

if (!window.Turbo) {
	require("@hotwired/turbo")
}

The problem is gone, but the 404 page would flash a bit, not as smooth as normal pages.