Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

tpaulshippy
Copy link

Purpose

Resolves #1241

Approach

Set the location on the session even if the PageView does not render because the trackedElementsAreIdentical 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"

@tleish
Copy link
Contributor

tleish commented Jun 21, 2024

Would a better option for testing this would be the src/tests/functional/frame_navigation_tests.js?

Something like: https://github.com/hotwired/turbo/compare/main...tleish:turbo:turbo-frame-back-navigation?expand=1

@tpaulshippy
Copy link
Author

tpaulshippy commented Jun 22, 2024

Would a better option for testing this would be the src/tests/functional/frame_navigation_tests.js?

I think we both tested with that same file. It looks like you added goBack testing to frame navigation with data-turbo-action whereas I removed the <script> tag from three.html and tested with promoted frame navigations are cached.

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?

@tleish
Copy link
Contributor

tleish commented Jun 22, 2024

The only piece I didn't quite understand is where you removed lines 114-117. Maybe you could help me understand that change?

Ignore those changes,I must’ve cut-paste instead of copy-paste.

Have you found a better way to resolve the issue?

The test is as far as I got.

@tpaulshippy
Copy link
Author

Confirmed that your testing approach accurately reproduced the issue and was resolved by the proposed implementation. Pushed. Thanks @tleish
Looking forward to seeing any alternative implementation ideas. I'm not convinced this is the best possible way to resolve the issue.

@tleish
Copy link
Contributor

tleish commented Jun 24, 2024

I believe the fix is a bit simpler. It appears with a turbo navigation that includes an action, turbo does the following:

  1. Calls FrameController#loadFrameResponse where it loads and updates the frame on page
  2. During this method, it calls await this.fetchResponseLoaded(fetchResponse); which is defined inside of FrameController#proposeVisitIfNavigatedWithAction
  3. frame.delegate.fetchResponseLoaded defined within FrameController#proposeVisitIfNavigatedWithActionsimulates a "Turbo#visit" (last line) wherein the PageSnapshot is updated with the HTML from the mocked response object. Instead of setting the HTML to be the frame html, we could set it to be the current/updated page HTML (which has the frame contents loaded at this point). Doing this means that the PageSnapshot.headSnapshot.trackedElementSignature will always match when the logic compares the history for back navigation.

see: https://github.com/hotwired/turbo/compare/main...tleish:turbo:turbo-frame-back-navigation?expand=1

@tpaulshippy
Copy link
Author

tpaulshippy commented Jun 24, 2024

That's a revert of part of ed72ba1
I guess I wonder why that change was made. There's a bit of an explanation there but it sounds more like "this is why this works" rather than "this is why we need this."
@seanpdoyle maybe you can help?

@tpaulshippy
Copy link
Author

I'm happy to switch to that implementation in this PR if you think it's a better approach.

tleish referenced this pull request Jun 24, 2024
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
@tleish
Copy link
Contributor

tleish commented Jun 24, 2024

That's a revert of part of ed72ba1

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.

@tpaulshippy
Copy link
Author

Looks like this was discussed here: #887 (comment)

@fonji
Copy link

fonji commented Oct 31, 2024

This seems to continue to be a problem, what can we do to get this merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Turbo frame history not navigating properly w/ back button after upgrading from 7 to 8
3 participants