Bug #58755


Select-type fields and requestUpdate broken

Added by Francois Suter about 10 years ago. Updated over 5 years ago.

Must have
Backend User Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Consider the following situation: you have a table containing a select-type field with a setup such that it is displayed with two side-by-side selectors. Furthermore that select field is registered with "requestUpdate".

This does not work anymore with TYPO3 6.2. Indeed selecting an item in the left-hand selector triggers two actions:

  1. a confirm dialog box appears asking if we really want to reload the page
  2. the value selected on the left-hand side is copied to the right-hand selector.

The problem is that the second action is now triggered after the first one. It's a matter of milliseconds, but the value arrives in the left-hand column (and also the hidden field with the final values) just after the form is submitted. Thus the field stays empty.

As discussed in the Core list, a simple, very short timeout in the submission process is enough to solve the problem. It is not very elegant, but since this JS is due to be refactored anyway, it is an acceptable solution (according to Benni).


Actions #1

Updated by Francois Suter about 10 years ago

Steps to reproduce:

  1. install attached extension
  2. create a new record for table "Dummy"
  3. select a value in the "Content" field and observe the bug at work

Applying the (upcoming) patch solves the issue.

Actions #3

Updated by Gerrit Code Review about 10 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at

Actions #4

Updated by Francois Suter about 10 years ago

I'm sorry my test extension contained a mistake. I had created the relation field as INT, but the relation was not MM and so multiple relations could not be stored, as comma-separated values would not be accepted. I changed the field to VARCHAR now. I also added a field without request update, so that you can compare the 2 behaviors.

Actions #5

Updated by Francois Suter about 10 years ago

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

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF