Closed Bug 214607 Opened 21 years ago Closed 20 years ago

caret appears at beginning of paragraph instead of in textbox

Categories

(Core :: Layout: Form Controls, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

On the second screen of http://www.psych.upenn.edu/~baron/lasik.htm, a lot of
things are wrong:
a) Sometimes, clicking the textboxes doesn't work. (Reloading fixes.)
b) Sometimes, clicking the buttons doesn't make them appear focused.
c) Clicking a textbox makes the caret appear in the wrong place (inside the
letter 'A' in the word 'Attribute') as long as the textbox is empty.

(All in Firebird 07/30.  The page works fine in Phoenix 0.5.  At least some of
the problems exist in Firebird 07/12 and in Seamonkey.)

This bug is about (c).  If fixing (c) doesn't fix the others, please file or ask
me to file more bugs.

Testcase coming...
Attached file testcase
This is the entire testcase:

<html><body>
<p>No matter where the textbox is, the caret will be here when the textbox is
empty<br>
<input type=text>
</body></html>

Adding whitespace before <html> or between <html> and <body> fixes the problem.
Experimenting with <br>s reveals that the caret always appears at the beginning
of the paragraph.
Btw, I think there are builds (between Phoenix 0.5 and 07/30) where the testcase
does not show a problem but http://www.psych.upenn.edu/~baron/lasik.htm does.
I have a testcase that does not show this bug in 2003072622 for Linux:

http://www.sas.upenn.edu/~baron/testcase.htm

I thought the bug might be specific to forms generated with JavaScript,
but that isn't it.  Both inputs work.

However many of my other studies have similar problems.  The caret
may be on the screen somewhere, but I can't find it, and I can't type
in the box unless I change viewport and then return.  (Reloading these
louses up the JavaScript.)  For example, see

http://finzi.psych.upenn.edu/~baron/ex/all1.htm

and many of the other studies in the same /ex/ directory that have
text input.  (Most don't.  But this one does.)  These are all forms
generated completely with JavaScript.  But note that this is not
the problem, since my testcase also uses JavaScript and it works (on
my build).

Also, and this may or may not be part of the same bug, the focus()
command is not working, just when these other problems happen.  In
the test case I made, the focus() command works.

I cannot modify my test case to get the bug, but I will keep working
on it if I have time.
*** Bug 215218 has been marked as a duplicate of this bug. ***
This version, and earlier versions, show the correct behavior:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030721 Mozilla
Firebird/0.6

This version, and later ones, show incorrect behavior:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Mozilla
Firebird/0.6

The third comment (by Tim) in the dupe of this bug has some interesting
information also.
It has seemed to me that this bug is related to the fact that you can't
focus on a text input field, even if you click on it, under some conditions.
I have discovered a work-around, which may give some clue about the bug.
Specifically, compare http://www.psych.upenn.edu/~baron/bugtest0.htm
with http://www.psych.upenn.edu/~baron/bugtest1.htm.  "bugtest0" shows
the bad behavior.  When you get to the list of questions with text input,
even clicking in the first box does not put focus in it.  In "bugtest1",
I added window.blur() and window.focus(), and this not only fixes
the problem but also allows the subsequent
tframe.document.subform.elements[0].focus() command to work, so that you
can just start typing without clicking the mouse.
My small testcase in comment 1 no longer shows this bug, but the original page
(http://www.psych.upenn.edu/~baron/lasik.htm) still does.
Keywords: testcase
So far as I can see, all the test cases now work properly:
http://www.psych.upenn.edu/~baron/bugtest0.htm
(my "bad" example)
and
http://www.psych.upenn.edu/~baron/lasik.htm
(which was Jesse Ruderman's last case that didn't work)

It seems that this bug has gotten fixed as a side effect of some other
change.  The caret now appears in the right place, and focus is also
in the right place.

I'm using the nightly build of 9/12/03 for Linux: 2003091122
I'm not marking it as "fixed" because (a) I'm not sure I can, and
(b) someone should test it on another platform.
Worksforme with a current Linux build too... Marking so; Jesse, if this is still
reproducible (which I doubt), please reopen.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040430
Firefox/0.8.0+
You need to log in before you can comment on or make changes to this bug.