Closed Bug 230474 Opened 16 years ago Closed 7 years ago

text form element "resets" view when value is auto-updated

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla22

People

(Reporter: felipe, Assigned: mounir)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

I am developing a web app for internal use. It happens that the secretaries
REALLY want everything to capitalize automagically, so I am using 'this.value =
this.value.toUpperCase()' on keyup events to get that as best as possible.

Unfortunately, what this is doing in MozFb is, when the text input width exceeds
that of the form element, the toUpperCase thingie causes the element's
"viewpane" to reset such that the last characters the user typed are only
momentarily visible.

IE doesn't have this problem, though it does have other issues. It would be nice
if there were a standard way to alter the value of a text form element without
affecting cursor position; I have not found such in my searching.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
I tried to reproduce it with the given URl, but I get a 404.
Not Found
The requested URL /~fgasper/bug.html was not found on this server.

Can you still reproduce this problem with a recent Firefox?
I've reproduced the problem here:

http://fshn-dads.foods.uiuc.edu/test/textbug.htm

FF 0.9.1 still acts the same way. I have since resorted to CSS's text-transform
property, but that's really not supposed to affect form values, so this would
still be the more standards-compliant way of capitalizing a form input's display
(until CSS3 is implemented).
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0

I'm still seeing this bug in the latest nightly.
This looks to be fixed on trunk, in any case.

Reporter, do you still see this?
(In reply to comment #4)
> This looks to be fixed on trunk, in any case.
> 
> Reporter, do you still see this?

No, actually - using FF 1.0.2.
(In reply to comment #5)
> (In reply to comment #4)
> > This looks to be fixed on trunk, in any case.
> > 
> > Reporter, do you still see this?
> 
> No, actually - using FF 1.0.2.

Request close worksforme
Moving to Core->Editor...
Assignee: firefox → mozeditor
Component: General → Editor
Product: Firefox → Core
QA Contact: bugzilla
Version: unspecified → 1.0 Branch
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Hm - I must have been thinking of something else when I said I don't see it anymore.

Using FF 1.0.7, this does still happen. You have to put enough text into the
form element to fill its displayable content. Then notice that you can't go
"past" that because of the auto-capitalization.

For example, try typing "Four score and seven years ago." When you release the
key, you see the *start* of the text, not where the cursor is.
*** Bug 230533 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → editor
Assignee: mozeditor → nobody
This still happens almost a decade after reported. I'm similarly developing an internal tool which is severely affected by this - I replace diacritics while a user is typing using keyUp event, when the text reaches the end of the input element the view gets reset continuously to the start so the user can not see what he is typing - very annoying.

In Chrome this works as expected.

Thanks
Oh and btw: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20130107 Firefox/19.0 ;)
It can be tested by running the following on a site with INPUT (using jQuery but easily adapted I think if need be):

$('input').keyup(function() {
	$(this).val($(this).val());
}
This should be fixed by the patch in bug 829606.
Assignee: nobody → mounir
Status: UNCONFIRMED → ASSIGNED
Component: Editor → DOM: Core & HTML
Depends on: 829606
Ever confirmed: true
OS: Windows 2000 → All
Hardware: x86 → All
Version: 1.0 Branch → Trunk
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in before you can comment on or make changes to this bug.