132224 - text areas do not retain caret focus in several situations

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Thomas F. O'Connell]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031106

i have encountered a number of situations, now, where text areas frustratingly
fail to retain cursor focus (i.e., when focus is returned to a Mozilla window
where a cursor was active in a text area, the cursor is no longer active).

Reproducible: Always
Steps to Reproduce:
1. launch Mozilla
2. visit http://bugzilla.mozilla.org/
3. see the cursor blinking.
4. File->New Navigator Window.
5. enter another URL in the Location Bar.
6. Tasks->1 mozilla.org Bugzilla...

Actual Results:  the formerly blinking cursor is no longer blinking.

Expected Results:  when focus is returned to the first active Mozilla window,
the cursor should blink.

this may be related to (the same as?) bug 96689.

also, it seems only to occur when focus is switched among Mozilla windows. i.e.,
if i switch to another application and return focus to Mozilla, the cursor
remains active.

finally, it only seems to occur when another Mozilla window actually loads a
page. for instance, if you skip step 5 above (i.e., leaving the new window with
no page loaded), the cursor will remain active when focus is returned to the
original window.

i have also had a problem with the cursor not remaining active when i move the
active Mozilla window on the screen. unfortunately, this problem does not turn
out to be 100% reproducible.

Comment 1

[Aaron Leventhal]

Does this occur on Mac only?

I wonder if this was caused by my March 9 checkin for bug 66597.
Could the reporter check to see if this bug is reproducable before and after 
that date?

1.329 aaronl%netscape.com Mar 9 22:21   Fixes bug 66597, bug 103284, bug 
114440, bug 120023, bug 128741, bug 19259. Cleans up browse with caret, makes 
it work with XML content docs, creates keyboard toggle for it (Accel+shift+K), 
synchronizes focus and document selection so that users can tab navigate 
relative to their last find or click in text, or vice versa, makes tabbing move 
relative to named anchor that has been jumped to. r=bryner, sr=alecf, a=asa 

Comment 2

[Thomas F. O'Connell]

i tried Mozilla 0.9.8 on Mac OS 9, and i had the same problem. it didn't follow
exactly the scenario i describe in the bug report, but it was very similar. i
merely had to toggle the Mozilla windows twice rather than once (using Cmd-1 on
the Mac, which toggles Navigator Window Tasks).

i also had the same problem on Mac OS X with 0.9.9.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Please retest with tomorrow's builds -- I suspect the fix for bug 135154 fixed this.

Comment 4

[Thomas F. O'Connell]

i still see the problem. i'm using Build ID 2002051005. now i see it with new
tabs rather than new windows. try the above scenario with a new tab rather than
a new window. the caret stops blinking again.

Comment 5

[Greg K.]

Using tabs rather than windows, confirmed using Mac/2002072203.

Comment 6

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 7

[Uri Bernstein]

WFM
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051001
Firefox/1.6a1 ID:2005100107

Comment 8

[Thomas F. O'Connell]

Just realized this is still open. Happy to resolve, but not sure whether WONTFIX or WORKSFORME is the best resolution at this point.

Comment 9

[alexander :surkov (:asurkov)]

worksforme since nobody can reproduce the bug but that's not big deal I think.