215724 - Non-blinking or disappearing text input cursor (caret) when replying at forums.appleinsider.com

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Kerry Shetline]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624

On this web site, the text-input caret doesn't blink when you're typing into a
reply form. Sometimes the caret disappears completely, sometimes false carets
appears in the wrong place.

I've tried to isolate the bug with simple forms like this:

   <form action="#" name="test" method="post">
   <textarea name="message" rows="20" cols="60" wrap="virtual"></textarea>
   </form>

The above works fine, however. I'm not sure what combination of issues produces
the text input problems for Mozilla at appleinsider.com.

Safari and Internet Explorer don't have any problems with the appleinsider.com
reply forms.

Reproducible: Always

Steps to Reproduce:
1. You'll have to register for the web site. It's free, and no big deal to
register, but perhaps you have someone who handles Mac bugs who's already a member.
2. Select a forum and a topic.
3. Click "reply" for one of the messages.
4. You won't have to actually submit any replies. You should see the cursor
problem immediately.
Actual Results:  
Non-blinking, disappearing cursor in text field.

Expected Results:  
A properly blinking, non-disappearing cursor.

(I have yet to fill out a bug report where the "Actual Results" and "Expected
Results" fields of this bug form didn't seem kind of silly and redundant. You
know... Bug: X doesn't work. Actual Result: X didn't work. Expected Result: X
should have worked. D'oh! :) )

Comment 1

[Boris Zbarsky [:bzbarsky]]

If you save the web page, does the saved version reproduce the problem?  If so,
please attach that saved version to this bug.

Comment 2

[Kerry Shetline]

Oddly enough, a saved version of the web page, even using the "Web Page,
complete" option, doesn't show the bug. Only the live page straight from the web
site has the non-blinking cursor problem.

I should add that I've seen this bug for as long as I can remember using Mozilla
with the AppleInsider web site, so the bug is a long-standing issue.

Comment 3

[Boris Folgmann]

I have the same problem with moz 1.4 on Linux. I had to restart it, now I have a
text cursor again. It's really hard to type without it. I don't know why it happens.

Comment 4

[Erik Hensema]

I have the same problem. I use tabs created with dhtml, invisible tabs are
hidden by setting their visibility property to 'hide'.

input elements in a tab never have a blinking cursor.

Confirming bug. arch/os -> all (tested with windows and linux)
Changing url http://forums.appleinsider.com/ to testcase on
http://hensema.net/tmp/cursortest.php

tested on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119
Firebird/0.7+ and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210

Comment 5

[Alejandro Torras]

Hi,

I have a similar problem with a simple textarea: I get an erratic behaviour of
caret displaying (sometimes it disappears) and/or scroll movement.

For example: A textarea of 20 rows and 10 columns.
Steps:
1) Type 11 or more lines of arbitrary text.
2) The last line should be 21 or more chars wide.
3) Place the cursor to the last line
4) Type the DOWN key -> The cursos disappears 
*) If the cursor was at the end of the line and then you typed the DOWN key then
the cursor disappears AND the scroll doesn't move to the end of the line
(expected behaviour)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

Bye!

Comment 6

[Alejandro Torras]

I'm sorry, I really mixed a lot of things.

Forget the previous message.

Place a textarea with 10 rows and 20 columns
1) Put 11 lines of characters.
2) The last line should be 21 chars wide or more
3.a) Place the caret at any position but _not changing_ the scroll view and then
type the DOWN key -> The caret disappears
3.b) Place the cursor at any position having that the horizontal scroll is not
at the leftmost place and then type the DOWN key -> The cursor disappears again
but now the "view" scrolls to the first column.

It's not a critical but caret errors are alive since Mozilla 1.7.0 or sooner (I
submitted a similar bug)

Version: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

As Duke said: "I need a bed". It's 4:51AM in Spain 8-)

Good Bye!

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Tony Mechelynck [:tonymec]]

Moving to Core::Layout:Form Controls and resolving WORKSFORME. Feel free to reopen with Steps to Reproduce if seen on SeaMonkey 2.0.4 or later, or Firefox 3.5.9 or later.