Frame not updating a second time unless I manually clear src attribute

[WriterZephos]

Hi folks. Cudos to all the people building this thing. I think it bodes well for the future of software development.

I am having a similar issue to some others I have researched: #263, #360, #339, #349.

I have a link above an empty turbo-frame as so:

<a class="icon-link" data-turbo-frame="new_chapter_at_1_form" data-controller="text-tooltip" data-text-tooltip-text-value="New chapter" href="/versions/16/chapters/new?q%5Border%5D=1">
      <i class="fas fa-plus"></i>
</a>
<turbo-frame id="new_chapter_at_1_form">
  
</turbo-frame>

The response to the link is as so:

<turbo-frame id="new_chapter_at_1_form">
  <div id="new_chapter_at_1_form_div">
    //form here
    ...
    //Cancel button that removes enclosing div with id="new_chapter_at_1_form_div" from dom using a stimulus controller
  </div>
</turbo-frame>

The issue is that if I click the cancel button to remove the div containing the form, the link can't load the form again because the src gets set on the turbo-frame. The request succeeds and the browser returns the html, but it doesn't update the frame. If I clear the src manually, then it works again.

I tried to use a stimulus controller to clear the src attribute in the connect() lifecycle callback, but it never actually calls it because the turbo-frame is there from the beginning and never actually get reloaded (just its contents, as originally intended). I have seen some other stimulus controllers that apparently do what I need, but they look overly complex for such a simple task (not a javascript guy, hence the appeal of hotwire/turbo).

I am hoping there is an easy solution to this, but I am using 7.0.0-rc.3 which was supposed to have a fix to the similar issues I listed above, so I am at a loss and think there might be another facet to this bug that hasn't been fixed yet.

[kirillplatonov]

@WriterZephos this issue should be fixed already #360

Could you please provide a sample app with a reproducible bug?

[WriterZephos]

Yeah I will work on that. Might take me a day or two since this is purely a side project outside my day job.

[WriterZephos]

@kirillplatonov I got a demo app that demonstrates the issue I am having. Instructions to reproduce it are in the readme: https://github.com/WriterZephos/TurboBugDemo

[tleish]

@kirillplatonov I took a look at the code example. It appears the issue is caused by nested turbo-frames.

The following does not work

<turbo-frame id="new_test_model" reloadable="">
  <a data-turbo-frame="test_model_form" href="new">New</a>
  <turbo-frame id="test_model_form" src="http://localhost:3000/test_models/new"></turbo-frame>
</turbo-frame>

Moving the link outside the parent frame works

<a data-turbo-frame="test_model_form" href="new">New</a>
<turbo-frame id="new_test_model" reloadable="">
  <turbo-frame id="test_model_form" src="http://localhost:3000/test_models/new"></turbo-frame>
</turbo-frame>

[WriterZephos]

I was able to verify this. Thank you for taking a look at it!

This does seem like a bug to me, however, since the frame loads the first time. I think anyone could reasonably expect it to work subsequently.

[tleish]

I created an MR with just the failing test for this in #370, but I do not have a solution.

It appears the recent MR #360 modified FrameRedirector#linkClickIntercepted. It appears this method applies to links outside a frame, but from what I can tell links inside a frame are handled by Framecontroller#linkClickIntercepted.

[tleish]

I also discovered the form#get requests do not reload (inside a nested frame or outside a frame) and added these test scenarios to the MR #360.