Bug #80366

Values aren't always saved in the TYPO3 backend

Added by Josef Glatz over 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
Backend User Interface
Target version:
Start date:
2017-03-21
Due date:
% Done:

100%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
hard
Is Regression:
No
Sprint Focus:
Stabilization Sprint

Description

Problem/Description

A video is worth a thousand pictures :-[
https://youtu.be/5cqln5P1MJA

Update: Just for the records

2 hours later, same browser session, same server environment, faster internet connection between client and server: I couldn't actually not reproduce the described behaviour.

ToDo(s)

*

Acceptance Criteria

*


Related issues

Related to TYPO3 Core - Bug #80312: TYPO3 backend broken after a re-login Closed 2017-03-17
Related to TYPO3 Core - Bug #80632: still issues with missing input in BE Closed 2017-04-02
Related to TYPO3 Core - Bug #80672: Saving problems in Chrome 57+ Closed 2017-04-04
Related to TYPO3 Core - Bug #80884: FAL metadata has to save multiple times before it's go to the database Closed 2017-04-19

Associated revisions

Revision 976934a3 (diff)
Added by Markus Klein over 2 years ago

[BUGFIX] JS: Fix FormEngine initialization

The FormEngine initialization process needs to be very careful
when the DOM is accessed.
This patch separates the routines and encapsulates those in
a DOMready handler, which are critical.

This solves a possible race condition when JS is executed faster
than DOM is built.

Releases: master, 7.6
Resolves: #80481
Resolves: #80366
Change-Id: I205aebc9f87a25f06942f923497f7f535fdb0c8f
Reviewed-on: https://review.typo3.org/52180
Tested-by: TYPO3com <>
Reviewed-by: Benni Mack <>
Reviewed-by: Wouter Wolters <>
Reviewed-by: Stefan Neufeind <>
Reviewed-by: Thomas Maroschik <>
Tested-by: Thomas Maroschik <>
Reviewed-by: Frank Naegler <>
Tested-by: Frank Naegler <>

Revision e6b3d3c3 (diff)
Added by Markus Klein over 2 years ago

[BUGFIX] JS: Fix FormEngine initialization

The FormEngine initialization process needs to be very careful
when the DOM is accessed.
This patch separates the routines and encapsulates those in
a DOMready handler, which are critical.

This solves a possible race condition when JS is executed faster
than DOM is built.

Releases: master, 7.6
Resolves: #80481
Resolves: #80366
Change-Id: I205aebc9f87a25f06942f923497f7f535fdb0c8f
Reviewed-on: https://review.typo3.org/52208
Tested-by: TYPO3com <>
Reviewed-by: Markus Klein <>
Tested-by: Markus Klein <>

History

#1 Updated by Josef Glatz over 2 years ago

  • Description updated (diff)

#2 Updated by Markus Hofmann over 2 years ago

Same problem in 7.6.16, required input fields are not saved on the initial save. The data is not transferred in the POST. Downgrade to 7.6.15 fixed the problem

#3 Updated by Markus Klein over 2 years ago

@Markus H.
Can you reproduce the issue reliably? Does your instance involve JS code from extensions?
Can you do a git bisect to find the offending commit?

The following changes have been merged between .15 and .16, which touch JS somehow:
https://review.typo3.org/51262
https://review.typo3.org/51816
https://review.typo3.org/51718

Don't know if those actually interfere here though.

#4 Updated by Markus Hofmann over 2 years ago

@Markus K.

We reproduced the bug in different TYPO3 instances. Every time a new data is inserted. I tested with be_users, required fields are password, username and usergroup in a blank and new typo3 instance, and with own types of data in other instances.

Fields with default values and fields, which are not required, are updated properly.

We found some possible issues in reviews and will test them. I'll give you feedback.

#5 Updated by Sven Juergens over 2 years ago

i had the same problem here some time ago, so i think it's not related to 7.6.16
the first time i see this issue i used current Chromium version as Browser, so i thought it's related to some new stuff in Chromium.
Maybe a JS Event is not fired every time or something like that. Because the Problem is, that the input of the fields are not transfered to the hidden input fields, which are sent.

#6 Updated by Josef Glatz over 2 years ago

My colleague had reproduced it with TYPO3 7.6.13 AND Chrome Version 57.0.2987.98 (64-bit) Mac. We can't reproduce the problem at the same time with Firefox for example.

So I could anybody of you can reproduce it with e.g. Firefox or IE?

#7 Updated by Nicolas Scheidler over 2 years ago

Encountered the same issue here in 7.6.16 (Chrome 57.0.2987.110 (64-bit)).

#8 Updated by Alex B over 2 years ago

Same here.

Typo3 Versions 7.6.15 and 7.6.16, Chrome 57.

I can not reproduce the bug in Firefox.

This happens for all fields and not just in required fields! Tested with Typo3 Header CE and various Fields in Extensions.
Tested with all custom Extensions turned off in Chrome.

#9 Updated by Markus Klein over 2 years ago

  • Category set to Backend User Interface
  • Status changed from New to Accepted
  • Assignee set to Markus Klein
  • Complexity set to hard
  • Is Regression changed from Yes to No

We will look into this tomorrow at the camp Vienna.

#10 Updated by Markus Klein over 2 years ago

Please apply the patch of #80459: https://review.typo3.org/52168 and check if things got better.
Feedback very appreciated.

#11 Updated by Sven Juergens over 2 years ago

hi,

testet it with 7.6.16.
the Problem still exisit.

the problem is here locatated (TYPO3 7.6.16)
typo3/sysext/backend/Resources/Public/JavaScript/FormEngineValidation.js

function:
FormEngineValidation.updateInputField ~ line 197

var config = $mainField.data('config');
if (typeof config !== 'undefined') {
.... here the fields are updatet
}

sometimes the var config is empty

#12 Updated by Markus Klein over 2 years ago

Thanks a lot Sven! Will look into this.

#13 Updated by Gerrit Code Review over 2 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/52180

#14 Updated by Gerrit Code Review over 2 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/52180

#15 Updated by Gerrit Code Review over 2 years ago

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/52208

#16 Updated by Gerrit Code Review over 2 years ago

Patch set 2 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/52208

#17 Updated by Gerrit Code Review over 2 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/52180

#18 Updated by Gerrit Code Review over 2 years ago

Patch set 3 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/52208

#19 Updated by Gerrit Code Review over 2 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/52180

#20 Updated by Markus Klein over 2 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#21 Updated by José Ricardo over 2 years ago

Any idea on when 7.6.17 will be available with this fix?

#23 Updated by Mona Muzaffar over 2 years ago

  • Related to Bug #80632: still issues with missing input in BE added

#24 Updated by Riccardo De Contardi over 2 years ago

I guess I've stumbled upon this issue on a fresh 8.7.0 install (I am not able to reproduce at the moment, just guessing)

#25 Updated by Mona Muzaffar over 2 years ago

  • Related to Bug #80672: Saving problems in Chrome 57+ added

#26 Updated by Pascal Hinz over 2 years ago

  • Related to Bug #80884: FAL metadata has to save multiple times before it's go to the database added

#27 Updated by Riccardo De Contardi almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF