-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support back button (restore) even if page loaded in frame does not contain matching HEAD #1281
base: main
Are you sure you want to change the base?
Conversation
Would a better option for testing this would be the Something like: https://github.com/hotwired/turbo/compare/main...tleish:turbo:turbo-frame-back-navigation?expand=1 |
I think we both tested with that same file. It looks like you added I think I do like your testing approach a bit better. Will try to switch to it when I get a chance. The only piece I didn't quite understand is where you removed lines 114-117. Maybe you could help me understand that change? Have you found a better way to resolve the issue? |
Ignore those changes,I must’ve cut-paste instead of copy-paste.
The test is as far as I got. |
Confirmed that your testing approach accurately reproduced the issue and was resolved by the proposed implementation. Pushed. Thanks @tleish |
I believe the fix is a bit simpler. It appears with a turbo navigation that includes an action, turbo does the following:
see: https://github.com/hotwired/turbo/compare/main...tleish:turbo:turbo-frame-back-navigation?expand=1 |
That's a revert of part of ed72ba1 |
I'm happy to switch to that implementation in this PR if you think it's a better approach. |
After the changes made in [@hotwired/turbo#867][] and changes made in [@hotwired/turbo-rails#428][] (the canonical server-side implementation), Turbo expects full HTML documents in response to requests with `Turbo-Frame:` headers. Prior to this commit, the `FrameController` compensated for missing pieces of an HTML document by taking an HTML "snapshot" of the current page through the `<html>` element's [outerHTML][]. This commit changes the `fetchResponseLoaded` callback to read the `responseHTML` directly from the `FetchResponse`, since that will be a fully formed HTML document in Turbo v7.3.0 and later. To support that change, this commit also updates various `src/test/fixtures` files to render fully-formed HTML documents. [@hotwired/turbo#867]: #867 [@hotwired/turbo-rails#428]: hotwired/turbo-rails#428 [outerHTML]: https://developer.mozilla.org/en-US/docs/Web/API/Element/outerHTML
Hah! You mentioned this before on the issue thread. I didn't look at it, but you are right. It's a revert of this commit. |
Looks like this was discussed here: #887 (comment) |
This seems to continue to be a problem, what can we do to get this merged? |
Purpose
Resolves #1241
Approach
Set the location on the session even if the
PageView
does not render because thetrackedElementsAreIdentical
is false.Test
This test illustrates the issue, once you remove line 6 from
three.html
npx playwright test -g "promoted frame navigations are cached"