You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I think I've stumbled on an issue with the new feature of allowing a Turbo Frame to drive navigation. It appears that the page is being cached earlier than it does when a Turbo Frame is not driving navigation.
I have a video recorded that shows 3 UI bugs that I think are all explained by this.
CleanShot.2021-11-24.at.13.57.00-converted.2.mp4
So everything visible in the window is in a Turbo Frame (there is UI above scrolled out of view that is not in the Turbo Frame). There is a form that encompasses all the filters in the dropdowns. The form is doing a GET request to load new results with the applied filters. Here are the 3 UI bugs to look for:
The date dropdown has a stimulus controller that, upon connect() instantiates a Litepicker, and upon disconnect() destroys the litepicker, removing its DOM. After restoring the initial page visit, there are two sets of Litepicker DOM in the dropdown. This indicates that a snapshot was taken before disconnect() was called.
The button in the Carrier dropdown gets disabled by Turbo and there is some disable-specific text inside the button. After restoring the initial page visit, the button remains disabled. This indicates to me that the snapshot was taken before Turbo re-enabled the button.
There is a Stimulus controller that wraps the filter form that is in charge of resetting the state of the inputs when the dropdown closes, so if the user checks a box and closes the dropdown without clicking "Apply" the checkbox will revert to its initial state. This stimulus controller adds a listener to document for turbo:before-cache that resets the form. But after restoring the initial page visit, the checkbox is still checked. It doesn't get unchecked until the dropdown is opened, and then closed. So the snapshot seems to be happening before turbo:before-cache gets called.
Hi, I think I've stumbled on an issue with the new feature of allowing a Turbo Frame to drive navigation. It appears that the page is being cached earlier than it does when a Turbo Frame is not driving navigation.
I have a video recorded that shows 3 UI bugs that I think are all explained by this.
CleanShot.2021-11-24.at.13.57.00-converted.2.mp4
So everything visible in the window is in a Turbo Frame (there is UI above scrolled out of view that is not in the Turbo Frame). There is a form that encompasses all the filters in the dropdowns. The form is doing a GET request to load new results with the applied filters. Here are the 3 UI bugs to look for:
connect()instantiates a Litepicker, and upondisconnect()destroys the litepicker, removing its DOM. After restoring the initial page visit, there are two sets of Litepicker DOM in the dropdown. This indicates that a snapshot was taken beforedisconnect()was called.documentforturbo:before-cachethat resets the form. But after restoring the initial page visit, the checkbox is still checked. It doesn't get unchecked until the dropdown is opened, and then closed. So the snapshot seems to be happening beforeturbo:before-cachegets called.Here's the abbreviated markup of the Turbo Frame
And because it is the smallest controller to include for an example, here is that reset controller:
Let me know if there's any other info I can provide!