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)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
136 bytes,
text/html
|
Details |
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...
Reporter | ||
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
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.
Comment 6•21 years ago
|
||
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.
Reporter | ||
Comment 7•21 years ago
|
||
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
Comment 8•21 years ago
|
||
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.
Comment 9•20 years ago
|
||
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
Reporter | ||
Comment 10•20 years ago
|
||
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.
Description
•