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
Our Editors noticed that the datasavers used in our forms have the same entries multiple times (one case with 20 identical entries). It bothered them so we tried to investigate this and there is really a case where the user is not doing anything wrong and you still have multiple entries. Luckily we could not reproduce this with Android Devices or Desktop Browser but on iOS. On iOS Devices (any browser -> Apple Webkit Browser Engine is used by all browsers) a reload is sent if you visit an old tab or when the displayed „picture“ in the tab overview is updated. Somehow if the last request was a POST the browser sends the request again without asking the user if it’s intended.
Steps to reproduce:
Have a Plone 6-Site with easyform installed (see buildout.cfgbelow)
Create a simple form - default settings everywhere
Add a datasaver to the form.
With an iPhone Simulator (open -a Simulator.app on MacOS)
4.1. Select iPhone 12 with "File - Open Simulator".
4.2. Open the easyform-page (as anon) in Safari and submit it.
4.3. Open a tab to a www.google.com (or any other random website).
4.4. Close the simulated device (top left „x“)
4.5. Open the selected iPhone again.
4.6. Open Safari again and go to the tab-overview - this should already resend the form data.
4.7. Now go to the tab with the form - this should resend the data as well.
In most cases this could be fixed with a redirect-after-post (so you have a GET as the last request) but with easyform you lose the ability to display the form data. The response`s redirect-method doesn’t take any data, only the URL.
Redirecting to a special (global) site and giving the form data as GET-Params is IMO no option because of GDPR.
Another solution could be to inject a hash into the form (when loading it) and store this hash -> in buttonAndHandler checking if the hash was already sent. This is also tricky in easyform because it’s possible to have no datasavers at all (so we don’t know the entries sent before).
Currently, we are trying to develop a workaround that includes sending the request per AJAX and updating the displayed HTML with its response. So the last request (made by the browser) is the GET which loaded form. But we don’t know if it works and it seems „dirty“ to us.
The text was updated successfully, but these errors were encountered:
The idea of sending the request per AJAX would be easy to extend in Plone 6 since we have pat-inject (https://patternslib.com/demos/inject) from patternslib there. Just a simple setup:
This sends the form via ajax to the action and replaces the current #this-content node with the #response-content node from the response.
I could imagine to extend the easy form schema with extra cssclass field and a dataattribute like we did in the form fields already (sidenote: there you can use pat-depends (https://patternslib.com/demos/depends) for fields visibility depending on other field inputs)
Note this is related to #218 .
Description
Our Editors noticed that the datasavers used in our forms have the same entries multiple times (one case with 20 identical entries). It bothered them so we tried to investigate this and there is really a case where the user is not doing anything wrong and you still have multiple entries. Luckily we could not reproduce this with Android Devices or Desktop Browser but on iOS. On iOS Devices (any browser -> Apple Webkit Browser Engine is used by all browsers) a reload is sent if you visit an old tab or when the displayed „picture“ in the tab overview is updated. Somehow if the last request was a POST the browser sends the request again without asking the user if it’s intended.
Steps to reproduce:
buildout.cfg
below)open -a Simulator.app
on MacOS)4.1. Select iPhone 12 with "File - Open Simulator".
4.2. Open the easyform-page (as anon) in Safari and submit it.
4.3. Open a tab to a www.google.com (or any other random website).
4.4. Close the simulated device (top left „x“)
4.5. Open the selected iPhone again.
4.6. Open Safari again and go to the tab-overview - this should already resend the form data.
4.7. Now go to the tab with the form - this should resend the data as well.
bulidout.cfg:
Possible Solutions
Currently, we are trying to develop a workaround that includes sending the request per AJAX and updating the displayed HTML with its response. So the last request (made by the browser) is the GET which loaded form. But we don’t know if it works and it seems „dirty“ to us.
The text was updated successfully, but these errors were encountered: