Project

General

Profile

Actions

Bug #16951

closed

Autofill in form functions fail on Firefox & Internet Explorer

Added by Thomas Oppelt almost 18 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2007-02-07
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.1
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If you try to fill a backend form field by using autofill in form functions of your browser, the value won't be saved! Seems that there is no onchange event activated by using this function, but i suppose it's a typo problem not browser caused because its reproducible on Firefox (2.0.0.1) and Internet Explorer as well.
It's confirmed for 4.0.4, 4.1RC1 ...

(issue imported from #M4938)


Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Feature #17021: Add autocomplete="off" to BE loginClosedBernhard Kraft2007-02-20

Actions
Related to TYPO3 Core - Bug #17671: Autocomplete OFF for BE-Login formClosedBernhard Kraft2007-10-11

Actions
Related to TYPO3 Core - Bug #18581: Rename record don't workClosed2008-04-07

Actions
Related to TYPO3 Core - Bug #17622: t3lib_tceform & jsfunc.tbe_editor.js: Autocompletion disables saving of input-fieldsClosed2007-09-20

Actions
Has duplicate TYPO3 Core - Bug #18189: Problem with Firefox 2.0.12 useing the autocomplete list for renaming a pageClosedOliver Hader2008-02-11

Actions
Actions #1

Updated by Oliver Hader almost 18 years ago

Indeed, this could be a problem. Please see http://allinthehead.com/retro/102/the-times-they-are-onchanging - it's not only a concern of TYPO3 but more of the browsers which are not triggering a onchange event.

So, I can confirm this issue.

A workaround could be to handle onfocus/onblur events (the user was to click/select a field to change data and for saving he will leave this field again).
Another solution could be, to disable auto-fill via <meta> tag like suggested in the article from above. Possibly some browsers already have such feature?

Actions #2

Updated by Oliver Hader almost 18 years ago

Due to this comes from the browser and TYPO3 could only work around, I'm not sure if this is a major or tweak problem. It could also just be a feature.
But in fact it could annoy/hinder users while administrating data in the TYPO3 back-end.

Actions #3

Updated by Thomas Oppelt almost 18 years ago

Hmm...otherwise i think its not least Typo3 which makes itself fully dependend on correctly triggering javascript event-handlers, so i think we should offer a solution even if its just a workaround...? well just my personal opinion.

I would like to emphasise your assumption that this effect could really annoy and hinder users!...and mainly: if you save+close, it may take a possibly fatal while until not saved values get evident...i think its a major issue.

Actions #4

Updated by Thomas Oppelt almost 18 years ago

Just a little add note: there exists a non-standard html attribute called "autocomplete" (tested it for Firefox 2 and IE 7 / win and it works) which can be used to switch it off within form field tags...but this is an evil way and actually it would be nice to use the feature instead of disabling it...

Actions #5

Updated by Bernhard Kraft almost 15 years ago

The problem most probably is, the naming of the fields.

Firefox recognizes an input-box by its name="" property. In TYPO3 the name-property of each field is different as it has the uid of the field in the name-string. So if you edit an already existing content element, you will get the autocomplete drop-down when editing the same element again.

But for this reason autocomplete does not work with new elements, as they have a random string as uid (NEW0123456789abcdef)

So autocomplete partly works ... you can re-enter an already used value for the same element again.

It would be nice to have this feature for NEW records. The only thing to do would be to generate the NEWxyz string using a repeatable mechanism.

Actions #6

Updated by Alexander Opitz over 11 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)
  • PHP Version deleted (4)

As this report is very old, is the handling in newer TYPO3 CMS Versions (like 6.0/6.1) more like you expect it?

Actions #7

Updated by Alexander Opitz about 11 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Bernhard Kraft)

No feedback for over 90 days.

Actions

Also available in: Atom PDF