Bug #80672
closed
Story #69617: FormEngine bugs
Saving problems in Chrome 57+
100%
Description
Hi TYPO3 Community!
Since one of the last Google Chrome Browser updates there are existing saving problems in the backend.
That is the way I can reproduce it:
- Setup a plain TYPO3 7.6 project in the current minor version. I did so with composer.
- Update your Google Chrome to the newest version or download it.
- Install the backend user administration and try to create a backend usergroup
- If the create process is working - try to rename the group multiple times
- You can test it with similar other saving processes (tt_content, page settings, ...)
In my case ~25% of the saving processes did fail. I tried Chrome on Windows 10 and MacOS in the current version. I also tried on multiple other TYPO3 7.6 LTS projects with the same result.
The problem does not occur on Firefox, IE 11 and Safari (so I guess only at Chrome).
My exact Chrome Version: 57.0.2987.133
I am aware that this might also be a Chrome problem but I am curious if other people out there can also reproduce this error!
Thank you for your help and work!
Kind regards
Stephan
Updated by
Updated by Damian Parpan over 7 years ago
Hi Stephan, hi community!
I can reproduce the problem. In every backend form I have tried so fare, your description of the saving issue happens.
What I noticed: if i write some text in an input field, then place my curser in an other field, the content is saved. If the curser stays in the field, it is not saved.
Tried it with Firefox and Safari on the Mac, IE 11 and Edge and on Windows: the problem does not occur there.
My Chrome version (Mac): 57.0.2987.133 (64-bit)
TYPO3 versions the problem occurs: 7.6.12, 7.6.16, 8.6.1
Some of my clients have the same problem with their Chrome (on Windows mostly).
Greetings
Damian
Updated by Riccardo De Contardi over 7 years ago
I think I can confirm it for 8.7.0
Updated by Mona Muzaffar over 7 years ago
- Related to Bug #80632: still issues with missing input in BE added
Updated by Mona Muzaffar over 7 years ago
- Related to Bug #80366: Values aren't always saved in the TYPO3 backend added
Updated by Pascal Hinz over 7 years ago
- Related to Bug #80884: FAL metadata has to save multiple times before it's go to the database added
Updated by Riccardo De Contardi over 7 years ago
- Category set to FormEngine aka TCEforms
- Parent task set to #69617
Updated by Tymoteusz Motylewski over 7 years ago
@Damian, please try with most recent v7.6.18 version.
There were 2 patches in that area which were included in 7.6.17.
[BUGFIX] JS: Invert dependency definition for FormEngine and Validation (Markus Klein)
[BUGFIX] JS: Fix FormEngine initialization (Markus Klein)
Updated by Tymoteusz Motylewski over 7 years ago
seems we're not the only project having issues with chrome 57.
http://stackoverflow.com/questions/43129799/chrome-57-making-data-not-function-well
https://www.devexpress.com/Support/Center/Question/Details/T493066
https://bugs.chromium.org/p/chromium/issues/detail?id=709375
Updated by Tobias Schmidt over 7 years ago
To avoid confusion: This is not fixed in TYPO3 CMS 7.6.18. See #80884-9 for a possible Bugfix.
Updated by Markus Klein over 7 years ago
- Related to Bug #80481: FormEngine.Validation may access DOM too early added
Updated by Lars Peter Søndergaard over 7 years ago
I don't seem to be able to reproduce the issue on latest Chrome 58.x (neither in 8.7.1 nor 7.6.18)
Can someone confirm?
Updated by Riccardo De Contardi over 7 years ago
Unable to reproduce so far with Chrome 58 and latest Master (MAC)
Updated by Anders Kostending over 7 years ago
I've been able reproduce this issue in Chrome 58.
It is easier to reproduce if the throttle is set to 3G or something like that.
Updated by Christer V over 7 years ago
- In Chrome set throttling to Regular 3G or slower
- Add new element
- Before JS is done loading fill a input field and click away
- Save
- The input entered is lost since the the hidden field isn't filled, since the onchange is set to late
Updated by Markus Klein over 7 years ago
- Subject changed from [Backend] Saving problems in Chrome 57 to Saving problems in Chrome 57+
- Status changed from New to Accepted
- Priority changed from Should have to Must have
- Target version set to Candidate for patchlevel
Updated by Gerrit Code Review over 7 years ago
- Status changed from Accepted to Under Review
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52613
Updated by Riccardo De Contardi over 7 years ago
- Related to Bug #77729: Save Button must be disabled until formengine form is fully loaded added
Updated by Georg Ringer over 7 years ago
- Has duplicate Bug #80998: TCA validation in backend failed added
Updated by Gerrit Code Review over 7 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52613
Updated by Gerrit Code Review over 7 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52613
Updated by Gerrit Code Review over 7 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52613
Updated by Urs Braem over 7 years ago
I experience this in a non-https site, very dominantly when editing BE users; chrome is displaying the "Not Secure" Warning.
Another site with https, same TYPO3 version 7.6.16, has no such issues.
Could it be related?
Updated by Sven Liebendahl over 7 years ago
Christer V wrote:
How to reproduce:
- In Chrome set throttling to Regular 3G or slower
- Add new element
- Before JS is done loading fill a input field and click away
- Save
- The input entered is lost since the the hidden field isn't filled, since the onchange is set to late
Can confirm that for Chrome 57 and 8.7. Mainly the header field in content elements is affected.
When there is a header and bodytext field, saving for the bodytext field is always fine – for the header field not.
Updated by Andreas Allacher over 7 years ago
With 7.6.16 and chrome 57 I sometimes had the issue that bodytext formatting like bold was lost but the text itself was store.
Hiwever that might have been fixed with the JS fixes in 7.6.17.
Updated by Gerrit Code Review over 7 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52613
Updated by Gerrit Code Review over 7 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52776
Updated by Frank Nägler over 7 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset df6594dffae9b5e591c731dadb4c6425909ba598.
Updated by Gerrit Code Review over 7 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_7-6 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/52777
Updated by Frank Nägler over 7 years ago
- Status changed from Under Review to Resolved
Applied in changeset 6e13bffdd2da198245a0b58c409279c34a7ed56a.
Updated by José Ricardo over 7 years ago
We have applied the patch.
What we could see it that this solves the problem but creates another: the overlay is on "loading" forever on some Google Chrome (windows). I didn't tested a lot, but on a local machine with the test server in the same network (no speed problems), the result was not being able to edit the form even after waiting for more than 5 minutes. :/ (TYPO3 7.6.18)
It worked on my local Chrome (Ubuntu), however.
Updated by Riccardo De Contardi over 7 years ago
@José Ricardo I had the same problem.... IIRC I solved it reloading the backend with clearing the browser cache
Updated by
Updated by Oliver Bartsch about 4 years ago
- Related to Task #84140: Disable Save buttons if record is reloading after field change added