Closed Bug 130581 Opened 22 years ago Closed 22 years ago

Cannot enter addresses and subject of new mail until focus changes

Categories

(MailNews Core :: Composition, defect, P2)

Product:
MailNews Core
Component:
Composition
Platform:
All
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mozilla, Assigned: sspitzer)

References

Details

(Keywords: access, regression, Whiteboard: [ADT1])

Attachments

(4 files)

Animated GIF roughly illustrating the 2 carets phenomenon
28.15 KB, image/gif
Details
Screenshot showing both carets visible at the same time (in recipients and body)
15.00 KB, image/png
Details
Screenshot showing both carets visible at the same time (in subject and body)
15.20 KB, image/png
Details
until there is a proper fix, this turns off the cached compose window on unix.
325 bytes, patch
jesup
: review+
jesup
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031116

It is not possible to enter addresses and subject of a new mail message. There
is no cursor/focus in the new window and mozilla will not react when clicking in
the corresponding areas.

Reproducible: Sometimes
Steps to Reproduce:
1. Click Compose-Button -> Compose window comes up
2. Look at To: entry-area; no cursor? (if there is one, close and reopen window)
3. Try to enter addresses.

Actual Results:  It is not possible to enter text into addresses and subject area.

Seems that this happens exactly every second time you start a new Compose-window.
Workaround: You can activate it by switching to another mozilla window and return.
I see this too on linux. Interestingly enough, bringing another window over the
compose window and then bringing compose back into focus fixes the problem and
the cursor is blinking happily away in the To: field.

This is on 0.9.9

Maybe a problem with re-cycling the compose window?

Confirming, setting OS to all, setting component to composition.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Composition
Ever confirmed: true
OS: HP-UX → All
Hardware: HP → All
Can be reproduced for one user when running KDE desktop. First "Compose" after
launching Mozilla works OK, following "Composes" does not.

Another user could not reproduce the bug when running Gnome desktop. When same
user changed the desktop to KDE, the bug can be reproduced again.

Second user has "focus follows mouse" option turned on. Appears that this is
enough to move mouse over another to make To: cursor to blink again.

Is this really "minor" problem?
I am also using KDE, but original report was for HP-UX. Adding to summary.
Summary: Cannot enter addresses and subject of new mail → Cannot enter addresses and subject of new mail until focus changes
Note that my original report concerns mozilla 0.9.9 / KDE 1.1.2 / HP-UX 11.00. I
think this is a minor bug since there is an easy workaround; nevertheless it is
very annoying of course because it occures very often during extensive use.
sounds vaguely like bug 130418 and bug 130542
Only vaguely. If I read these reports correctly the caret is invisible, but
typing still puts info in the box. In what I'm seeing, the box is non
responsive, clicking on the box doesn't help. Only refocusing the window does
anything.

I haven't seen this problem since I turned off compose window recycling.
*** Bug 130824 has been marked as a duplicate of this bug. ***
Let me repeat what I said in bug 130824:

I've also seen this on 0.9.9 for Linux. Only help is to exit Mozilla. It turns
out that this takes really long (about a minute). So fat always lots of
instances of Java were running. Could be that the don't end probperly. When the
effect happened, I did not use anything wiht Java.

So different from the description in this bug, changing focus does not help.

pi
How can this be tagged as "minor"? Until the user discovers some work-around,
like changing focus, mail becomes unusable. I've been encountering this problem
a lot and ended up closing windows or restarting Mozilla. I only learned about
changing focus to another window by visiting this bug. Please upgrade to "major".
*** Bug 131997 has been marked as a duplicate of this bug. ***
More info on this bug:

1) Occurs under both KDE 1.1 and 2.2
2) Turning off compose window recycling definitely fixes it:

Put 

user_pref("mail.compose.max_recycled_windows", 0);

in your prefs.js file

Upping severity and adding coder of recycled windows code to this bug.

Nominating for 1.0
Severity: minor → major
Keywords: mozilla1.0
Cc saari@netscape.com since this is focus related.
*** Bug 132026 has been marked as a duplicate of this bug. ***
QA Contact: esther → olgam
Keywords: access
*** Bug 131953 has been marked as a duplicate of this bug. ***
*** Bug 132172 has been marked as a duplicate of this bug. ***
*** Bug 131259 has been marked as a duplicate of this bug. ***
*** Bug 131732 has been marked as a duplicate of this bug. ***
*** Bug 132157 has been marked as a duplicate of this bug. ***
*** Bug 130414 has been marked as a duplicate of this bug. ***
*** Bug 130501 has been marked as a duplicate of this bug. ***
Blocks: 132191
Copying what I said in bug 131259:

This is regression, this bug appeared at the same type (within a day or two) as
the bug 128659 (but failed to disappear when bug 128659 was fixed). Based on
this, I suspect that this was cased by the same bug 109081 checkin, as the bug
128659.

This bug is still there in BuildID 2002031319

I can reproduce this on 3 different machines, all running RedHat Linux 7.2 + all
updates using KDE 2.2.2, "focus follows mouse".

The workaround I use is to move the mouse pointer outside of the composition
window (to let the mailnews 3-pane window get the focus), then to bring it back
to the composition window. After that, the problem disappears (for this
particular window, next one will have it again).

Despite the workaround, this is highly annoying and visible bug, so IMHO it
needs to be fixed for 1.0

Also, I noticed that whether a particular composition window will be
affected by this bug or not depends on what happened to the *previous*
composition window.

For example, in BuildID 2002031607 after I kill a comosition window and answer
"don't save" when prompted, the next composition window will have this bug. On
the other hand, if I kill a composition window without typing anything in it (so
I don't get any prompt), the next composition window will behave normally. This
does not seem to depend on whether I create the new window using "Compose"
button or "Reply" button.

This enforces my suspicion that this was caused by the bug 109081 check-in
(which did something to cached compose windows).
No longer blocks: 132191
Keywords: regression
Blocks: 132191
This problem seems to hit a lot of people, nominating nsbeta1
Keywords: nsbeta1, relnote
I'll investigate.

One suggestion, until we figure this out, is to default this pref to 0 on unix
and 1 on mac and win32.

that will provide correctness for all linux users, but the performance
improvements will be lost on that platform.
Status: NEW → ASSIGNED
ok, I can reproduce this on RH 7.2 with KDE and "focus follows mouse".

I'm hoping I can fix this with a simple hack, trying something now...
ok, my simple hack was useless.  I'll debug and try to see why the window is
having these problems, and why shifting focus away and back fixes it.
ok, thanks to kin, this might really be bug #103197.

I'm going to try the hack suggested in that bug, as the monster bug #103197 
doesn't look like it's going to be fixed any time soon.
Depends on: 103197
yes, a similar hack (using setTimeout()) fixes this problem.

I'll polish up my patch, and then attach it for review.
Discussed at Mail News bug meeting with Engineering, QA Mktng and PjM.  Decided
to minus this bug.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0
What we will do in message compose without those timers :-)
*** Bug 132568 has been marked as a duplicate of this bug. ***
*** Bug 132781 has been marked as a duplicate of this bug. ***
*** Bug 132743 has been marked as a duplicate of this bug. ***
*** Bug 132884 has been marked as a duplicate of this bug. ***
*** Bug 132919 has been marked as a duplicate of this bug. ***
*** Bug 133285 has been marked as a duplicate of this bug. ***
my timer trick doesn't seem to be working.  I'm going to see if dmose can help 
me out with this, as linux is his primary platform.

I'll give a brain dump to dmose.
cc some linux and focus experts, in case they can offer some help.
*** Bug 134187 has been marked as a duplicate of this bug. ***
*** Bug 132147 has been marked as a duplicate of this bug. ***
Discussed in Mail News bug meeting.  Decided to ADT2 this bug.
Whiteboard: [ADT2]
Now that is _strange_, what I found recently with respect to compose window on
Linux.
Tested with trunk build 2002040211 (and seen with earlier nightlies too, just
recently took time to find a reproducable testcase) on KDE 2.2.2.
We can see 2 text carets in the compose window at the same time!

To reproduce:
1. Go to http://petition.eurolinux.org/index_html?LANG=en.
2. Click on the privacy link at the bottom of the page (it links to
privacy@eurolinux.org).
3. The compose window comes up with text caret blinking in the message body area.
4. Still with me? Now switch to the browser window (ALT-Tab or whatever shortcut
switches between windows on your window manager) and then back to the compose
window.

The recipients or subject field gets the focus, it receives the text caret, but
the caret in message body is still there and blinking, so there are 2 carets!

If you start typing from the keyboard, text starts appearing in the field which
received caret _after_ ALT-Tabbing (recipients or subject). So the input focus
is in that field, but it seems that the caret in message body wasn't destroyed
properly and is still displayed.

If you look carefully, you'll notice that the body caret is different: body
section is a kind of HTML  editor, so the caret is taller thanks to a bigger
font. It also blinks at a slightly different frequency, so even though initially
the 2 carets appear mutually exclusively on screen (when one disappears, the
other one appears), they get out of sync after a while (I'll attach a screenshot
where both of them are visible on screen at the same time.)
Yes, I see that "two carets" thing s lot - see the dup bug 131259 for another
way of reporudicing it.
speaking for me (2002031312 on Linux), this bug appeared first in 0.9.9, but it
could be also KDE related. I used 0.9.8 on KDE3 beta and 0.9.9 on KDE3 RC3
Aleksey:
I cannot repro that with the method from bug 131259. It seems that the problem
is more complex and there are many factors here that influence reproducability.
Bug appears for me in KDE 2.2.2 with 0.9.9 (2002031808).
Still in Linux 2002040308. Hope this one is fixed for 1.0. 

Thanks for the temp. fix though!

I had been typing the body and then shift-tabbing back to the address/subject
fields. This works, but refuses to use the Address Book. I did not notice that
it was every other Compose window...
*** Bug 135416 has been marked as a duplicate of this bug. ***
*** Bug 135960 has been marked as a duplicate of this bug. ***
*** Bug 136099 has been marked as a duplicate of this bug. ***
In addition, username expansion does not work.  When you type in a username,
normally the name would be checked against the LDAP databases and a pop up with
the possible completions would appear.  When the cursor doesn't appear, this
expansion also doesn't work.

I can also resolve this by closing the window and then immediately opening a new
compose window, then the cursor and everything will work.  The problem hits me
every other time I use the Mail composer.

I am running 9.90 (Build 2002040211) on Linux with KDE 2.2.
Raising priority
Whiteboard: [ADT2] → [ADT1]
sorry for the delay, back on this.

this is UNIX only (HPUX and Linux), so setting OS to linux.  (we haven't seen 
this on mac or windows, so it's not "all").

I'm going to investigate (again), and if nothing looks promising, I'm going to 
disable the cached compose window by default on unix builds until we can figure 
this out.
OS: All → Linux
*** Bug 136847 has been marked as a duplicate of this bug. ***
I put the following in my perfs.js file:
user_pref("mail.compose.max_recycled_windows", 0);

At first, it appeared to fix it, but alas, no, I still get this issue constantly
and fairly often.  It used to be every other time, but now it appears to be
random, sometimes 6 times in a row it comes up wrong :-(
Big isn't related to KDE only as mentioned in one of the comments Gnome 1.4 has
the same issue. The bug appears at random sometimes 5 mails go ok and nr 6 has
the focus issue
*** Bug 136705 has been marked as a duplicate of this bug. ***
fix landed on the trunk.

this has r/sr=bienvenu
Whiteboard: [ADT1] → [ADT1] [fix landed on trunk]
bug 137698 tracks the issue of turning it back on.
Blocks: 137698
Comment on attachment 79404 [details] [diff] [review]
until there is a proper fix, this turns off the cached compose window on unix.

a=rjesup@wgate.com for drivers.  (makring previous r/sr in bug)
Attachment #79404 - Flags: superreview+
Attachment #79404 - Flags: review+
Attachment #79404 - Flags: approval+
nominating adt1.0.0.  AFter this is tested and we're sure this still works,
please update the bug.
Keywords: adt1.0.0
fixed on the trunk.  olga verified it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [ADT1] [fix landed on trunk] → [ADT1] [fix verified on the trunk]
adt1.0.0+ (on ADT's beahlf) for checkin into the 1.0 branch. Pls check this in
today, and add fixed1.0.0. Once, QA has verified the fix on the branch, pls add
the verified 1.0.0 keyword. thanks again seth!
Keywords: adt1.0.0 → adt1.0.0+
fixed on branch as well, since I have a=leaf,asa and adt=jaime.

note, bug 137698 tracks the issue of fixing the real problem and then turning
the optimization back on for unix.
Since it's fixed on the branch, adding fixed1.0.0 keyword.
Keywords: fixed1.0.0
Verified on 2002-04-17-10-1.0.0.
Tested with IMAP, POP, Aol accounts when create new of edit existing message
(added more recipients).
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
Verified on build 20020418 as fixed. OS linux
*** Bug 138783 has been marked as a duplicate of this bug. ***
this is not exactly what happens to me.
address and subject cannot be entered even if focus changes (i.e. to text area)
and then back to address and subject fields again.
the only workaround is doubleclick twice on the title bar.

anyway: I did not installed 1.0rc1 yet; I'll post a comment asap when I install it.
We're not talking about focus between the different text entry fields, but
windows. Bring another window forward, then bring the compose forward again, and
you should be able to type in the compose window.
Whiteboard: [ADT1] [fix verified on the trunk] → [ADT1]
Verified as fixed on 1.0Rc1 on linux.
*** Bug 140984 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826

Can confirm a partial fix only.
Checking this bug after reporting similar thing in #133442 I find that the image
attachements are describing the exact issue I encountered in #133442. 
This here is marked as FIXED, but I can only see a partial fix. 

Consider the following situation when using File->Send page:

1) a signiture is defined

2) the buildup of the mail composition window is quite slow (amd athlon 650mhz
with processor idle > 90%), using a camera playback, I measured it to about
0.5sec from the window outline until the cursor is in the To: field.

3) it is clearly visible how the cursor is first positioned in the body area of
the composition window, then it is moved to the To: field. 

- as caret is placed in email body it starts as visible
- as caret is moved to To: field and becomes invisible as it arrives there,
being th next state of it's blinking cycle, but is seen as blinking later.

4) as usually I am quite prompt and my typing is pretty good, I often found
myself writing incomplete addresses in the To: field because the first one or 2
characters get written in the body area, which is then very annoying.

As such, cursor placement sequence is misleading until a stable blinking cursor
can be seen in the To: field.


*** Bug 134041 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
No longer depends on: 103197
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: