Closed Bug 130581 Opened 19 years ago Closed 19 years ago
Cannot enter addresses and subject of new mail until focus changes
28.15 KB, image/gif
15.00 KB, image/png
15.20 KB, image/png
325 bytes, patch
|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.
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
Cc firstname.lastname@example.org since this is focus related.
*** Bug 132026 has been marked as a duplicate of this bug. ***
*** 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. ***
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).
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.
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.
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 email@example.com). 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.
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]
Comment on attachment 79404 [details] [diff] [review] until there is a proper fix, this turns off the cached compose window on unix. firstname.lastname@example.org for drivers. (makring previous r/sr in bug)
nominating adt1.0.0. AFter this is tested and we're sure this still works, please update the bug.
fixed on the trunk. olga verified it.
Status: ASSIGNED → RESOLVED
Closed: 19 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!
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.
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).
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.
19 years ago
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. ***
You need to log in before you can comment on or make changes to this bug.