Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||get rid of "text was truncated" popup|
|Status:||CLOSED FIXED||QA Contact:||issues@gsl <issues>|
|Target Milestone:||OOo 3.1|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description richlv 2008-08-12 11:50:16 UTC
when inserting numeric and formatted fields with limited allowed max content length, attempting to enter another symbol when at the limit pops up a message : "The inserted text exceeded the maximum length of this text field. The text was truncated." such a text is not displayed for normal textfields. this popup serves no hugely useful purpose, interrupts the workflow and makes user read (or learn to ignore) the popup and close it. the length should be limited just like it is for plain text field, without any popups.
Comment 2 philipp.lohmann 2008-08-12 12:08:03 UTC
Comment 3 richlv 2008-08-13 14:14:57 UTC
ah, my search for 'text was truncated' didn't turn those up. anyway, i consider that in this case the fix has been worse than the problem it tried to fix. the problems with this solution : 1. it interrupts user's workflow with the popup dialog (user has to read & close the dialog); 2. this can even result in a minor data loss - suppose somebody is entering some long number, then hits some other key when at the character limit (and the field has max value set) - field contents are immediately set to max value, as soon as the popup is opened; 3. this is inconsistent, as text fields do not produce such a warning. this popup looks really weird especially on fields that allow single char input and are appropriately sized... possible ways to improve it : 1. try to detect pasting (which seems to be the biggest cause of the disappointment with the old behavior) ? this is done in some places (for example, irssi), so that warning is only shown when there is actual possibility that loss of pasted content might go unnoticed; 2. make the warning non-obtrusive - something like oo.org help agent pop-under or down-sliding warning in firefox (for prevented page popups and other things). this way user would be properly notified of field limit both when pasting and when trying to type past the limit, but the workflow would not be interrupted. i really believe form fields have become much less convinient to use with this change, but i won't be pursuing the issue, i'm just pasting my impressions & suggestion for the consideration. i can report any of them as new issues, or reopen this one for implementation of particular improvement (like non-obtrusive warning).
Comment 4 philipp.lohmann 2008-08-13 19:40:45 UTC
ok, let's ask mr. formfield then: fs, what's your opinion ?
Comment 5 Frank Schönheit 2008-08-15 09:48:29 UTC
I definitely agree to richlv. A message box popping up during normal text/data input is certainly a severe usability issue. If it's not possible to fix this in VCL in general (by detecting paste operations, as suggested by richlv - this would be the right way to fix it IMO), then we should introduce a setting/flag/whatever at the controls, and VCL controls create from within the toolkit should set this flag then. Adding usability keyword, adding regression keyword (since the usability issue is in fact a regression, even if it was intentional), targeting to next feasible release, confirming.
Comment 6 philipp.lohmann 2008-08-15 10:02:17 UTC
We can change it again, but defined behavior can neither be a defect nor a regression
Comment 7 richlv 2008-08-15 10:55:58 UTC
thanks for the positive response, i'm impressed & very glad ;) maybe a non-obtrusive warning in all cases (both typing in and pasting) would solve most issues here ? or maybe non-obtrusive warning for typing, and a popup for pasting, if that can be detected ? also, if these changes get introduced, they probably should also be propogated to the text field, which currently does not have the warning, as opposed to formatted fields.
Comment 8 Frank Schönheit 2008-08-20 11:16:04 UTC
fs->pl: Maybe the behavior was defined that way for controls in normal OOo dialogs, but the changed behavior of form controls is most certainly an undesired side effect. In case it isn't - I do not know who "specified" the new behavior of a modal message box during normal user input, but a) such a behavior clearly is a big usability flaw and b) to my best knowledge, nobody from the DB/forms team was involved into this decision. Anyway. As long as we fix this problem for 3.1, I don't care too much what flags we give it. May I suggest to apply the changed behavior if and only if the max text length is exceeded due to a pasting operation? Popping up a model message box during a normal typing really is weird, usability-wise. If users really need to get feedback that the letter they were to type doesn't fit anymore, we should find non-intrusive methods to tell them.
Comment 9 philipp.lohmann 2008-11-03 15:19:44 UTC
done so in CWS vcl96
Comment 10 Frank Schönheit 2008-11-03 15:37:27 UTC
thanks a lot!
Comment 11 richlv 2008-11-03 15:39:14 UTC
even more thanks from me ;)
Comment 12 philipp.lohmann 2008-11-17 12:18:05 UTC
please verify in CWS vcl96
Comment 13 marc.neumann 2008-11-24 12:13:08 UTC
verified in CWS vcl96 find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fvcl96
Comment 14 Frank Schönheit 2008-11-24 16:30:43 UTC
*** Issue 82495 has been marked as a duplicate of this issue. ***
Comment 15 thorsten.ziehm 2010-02-22 15:39:50 UTC
This issue is closed automatically. It should be fixed in a version with is available for longer than half a year (OOo 3.1). If you think this issue isn't fixed in the current version (OOo 3.2) please reopen it. But then please pay attention about the field 'target milestone'. The closure was approved by the Release Status Meeting at 22nd of February 2010 and it is based on the issue handling guideline for fixed/verified issues : http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues