Closed Bug 67988 Opened 24 years ago Closed 24 years ago

focus problems in mail/news

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: blizzard, Assigned: blizzard)

Details

(Keywords: access)

Attachments

(3 files)

patch
2.32 KB, patch
Details | Diff | Splinter Review
patch #2
2.74 KB, patch
Details | Diff | Splinter Review
final patch
3.00 KB, patch
Details | Diff | Splinter Review
Build is 2001 02 07 11. Sometimes if I click in the message window ( not the message list or the folder list ) the widget doesn't get focus. Keys like delete/pageup/pagedown don't do anything at all. This is hard to reproduce but I'm running into it all over the place so I'm sure it's there.
Severity: normal → major
Whiteboard: critical for mozilla 0.8
there is an off chance that this is related to the status / meteors not finishing bug. I'll go explore that theory.
Status: NEW → ASSIGNED
well, there goes that theory. I can't reproduce this problem with (or without) bienvenu's fix. blizzard, anything happening on the console when you get into this state? if you can figure out how to reproduce it, let me know.
No, I haven't been able to figure out a way to reproduce it regularly and there isn't any console output when it does. I know this bug report sucks but it is a problem. If I can figure out how to reproduce it I'll update the bug. Have you even seen it?
I haven't seen it yet...were you using IMAP or POP? adding stephend, perhaps he can help try to reproduce it.
Chris + Seth, no, I personally can't reproduce this (at least, not at this moment) on RedHat 7, with Gnome and Sawmill. Especially since it's the mail window itself (usually if I do have problems, it's bringing focus from the folder pane to the message pane, and vice versa).
I'm using IMAP.
OK, I think I've got a way to reproduce this. Open an INBOX on the IMAP server by clicking on the INBOX under the account name. If you have lots of new messages and you can click on one of the new messages in the message header list _before_ it finishes loading it gets confused. If you click on the message you can see the message list lose focus but the message doesn't seem to have focus. Another little possibly relevant bit of information is that the Delete toolbar button isn't highlighted.
Unless this is a regression that just started showing up today, I don't agree that this is critical to 0.8.
I have had problems with the mail 3-pane window not giving up focus on 2001020808 Mac OS 9.1. I've had problems switching from the 3-pane view to a browser window, not just to message windows. Switching to another app and then going back to Mozilla clears it up and you can then change focus to another window. I haven't had problems with any other types of windows not giving up focus--just the main 3-pane window.
My gauge of "critical for 0.8" is that it's pretty broken and affects my ability to use mozilla as a day to day browser. I really started noticing it a lot more in these builds if that helps. As mail/news has started getting faster it's been showing up more and more.
Another interesting thing. If I sit long enough and wait the Delete icon will eventually become available. Maybe because I'm clicking on a message before the load of the inbox is done something is getting confused?
Here's yet another fun bit of information and it's quickly gotten to the top of my "mozilla most annoying list." o Let the filters refile your mail. o Click on a folder that has new mail. o Quickly click on a new message. o Quickly go to the Delete button and click it. At this point a dialog will pop up asking you if you're sure that you want to delete the entire folder. Huh? o Hit Cancel. The dialog will disappear and both the folder and the message in the header pane will be highlighted. There is some strange focus-fu going on here. I get that dialog about 20 times a day and it's really annoying.
Oh. That last thing shows up most easily if I shift-click several messages at once, say 4 or five, and delete them all at once.
OK, these focus problems are driving me completely batty. Is there a way that i can track the focus changes between the mail message area, the message header list and the folder list so I can figure out if there's something really strange going on or not?
Whiteboard: critical for mozilla 0.8
No patch in sight, can't be critical for mozilla0.8 unless it blows up your computer. /be
Summary: Mail message window won't take focus. → focus problems in mail/news
sorry for the delay. I'll go try to reproduce this.
Here's another bit of information that helps describe some of layout's state and how to tell when you've reproduced it. o Click in the folder pane on a folder that has new messages in it The thread pane loads with headers o Click on a message in the thread pane The message header in the thread pane is hightlighted and the folder that you have selected has turned gray. _However_ the focus ring is still around the folder list, not the thread pane like it should be. Does this give anyone any good clues? [ Adding saari who lives in focus hell. ]
If I notice that the folder pane still has focus and I switch to another window and come back the folder pane will end up highlighted again. I can then switch to the thread pane and it takes focus as expected. Sounds like a good NS_ACTIVATE clears mozilla's nose. It sounds like the focus out event is never making it to the folder pane? saari, how do I go about debugging this? Since someone has definitely reported this on Mac I'm marking this as a Platform All bug.
OS: Linux → All
I see this problem when deleting messages constantly, on the order of 30 or 40 times per day.
I've seen it once, but I'm not able to easily reproduce it. dmose, any tips to help me get this to happen more easily? I'm sure you got filters galore and biff going off. does it go away if biff is off and / or if filters are disabled? somewhere in my belly I think biff and filtering is causing us to lose focus.
In the case where you're clicking around before a load finishes, you may be sending new events into the system before the focus memory lock/semaphore is released. Sending these "injected" events definitely seems to be messing up the focus dance of window activation on linux, some of these cases may be releated.
I don't know. I looked at the source code for the linux focus code and it doesn't look like there's a lot of room there for error. The only place where I block focus events is when I'm grabbing focus on the toplevel mozarea and that's not going to cause this as near as I can tell. One of the things that happens here is that when you click on a message folder that has new messages is that focus is automatically given to the thread pane. I think that's intentional behaviour. The trigger for this seems to be if you happen to click at just the right moment in the window that the focus system gets screwed up and doesn't send the right focus in or focus out events. Once again, where I can trace this? In the event state manager? In the JS for mail/news?
OK, here's something in the code that's interesting. Bear with me for a second. One of the common things going on here is that we are trying to set focus to an item with a window click and something programatically is trying to set focus to that item at the same time. ( This sounds really similar to bug #68004 when I describe it like this, btw. I'll bet these are related. ) There's some code in the gtk code that does this: if (mHasFocus) { #ifdef DEBUG_FOCUS printf("Returning: Already have focus.\n"); #endif /* DEBUG_FOCUS */ return NS_OK; } This means that if you call SetFocus() on an element that already has focus it will just return NS_OK and never send any events back to the layout engine about focus changes. Maybe this is screwing things up. I'm going to play with this a bit.
Blizzard, you might be on the right track. I see that code get called when we're not sending the activate event to the newly actiavted window (which is the problem )
Oops, wrong bug for this comment, ignore me.
The way I trace this stuff is printfs in nsFocusController.cpp and in the appropriate widget code that dispatches the activate/deactivate and focus/blur events. If that all looks okay I add in a bunch of ESM printfs. If you watch the count on the focus lock in nsFocusController in relation to when the events are getting fired you can see if the focus tracker will ignore you or not. You want it to ignore some of the events during cross window transitions, but if that lock is still in place when the code fires to focus the message pane, then you'll be ignored by the focus controller producing the effects you see. I'm not sure this is the problem, just a guess. Also, you'll probably need the printfs in the ESM to see all the interesting focus events in this case.
I can't reproduce this in my optimized tip build. Suck. Maybe 0.8 is just doomed forever. I'm going to make an automated build and see if I can reproduce it there since it doesn't have the debugging spew.
With a daily build from February 18th I was able to reproduce this but only once after reading for hours. It's still there but it's just very rare now.
I marked netscape.test using Messages | Mark All Read Then I clicked on the inbox, because I think I heard biff go off (or I was expecting some bugmail that I just created.) Anyways, I'm pretty sure that because of the way biff works (drawing the icon and changing focus back and forth), it might be responsible for this bug.
Adding hyatt because I think wrote the focus controller. Hyatt, this is a strange problem, can you look at the symptoms and tell us if you have any ideas?
If biff triggered by the preference "Check for mail on this server every 10 minutes?" If it is then I don't use it.
OK, just for the sake of comparison this problem shows up on my machine at work a lot more often than at home. The machine at work is a 600mhz machine and the machine at home is a 400mhz laptop. The laptop is _much_ slower. So the faster the machine the more likely this is to happen.
No, that's just an automatic pref for checking it. If you check it by hang (pressing the GetMsg button), you run into another possible culprit, "Play a sound", underneath "When a new message arrives."
OK, I see it often after pressing the Get Msg button so it might be biff. Here's another interesting thing. When I get it into this confused focus state where the focus ring is around the folder pane but the thread pane has a message highlighted hitting <tab> doesn't change which window has focus. That works under normal circumstances. It's all very curious.
Woo hoo! I finally have a real, 100% reproducable test case for this. Here's how you do it. o Send yourself 15 or so messages that you know will be automatically refiled. Use a subject or something. o Click on the INBOX folder and let the messages be refiled into the folder. That folder should have new messages in it now. o Click on the folder with the new messages in it and _quickly_ click on another window to give it focus. This assumes that you are using click-to-focus like I am. You will probably see the window raise itself as focus is given to the thread pane. At this point I can see that the folder list still has the focus ring but the folder that's selected in the folder list has been blurred. o Click on a message in the thread pane that's new. At this point the mozilla window will get focus and the message in the thread pane will hightlight and the folder will be put into its blur state. However, the folder pane still has the focus ring around it. o Click delete and you will see the dialog about deleting this folder come up. Here's another interesting fact. If, when you clicking on the folder with new messages in it, click on another window, wait for mozilla to raise itself, click on the titlebar of the mozilla window giving it focus, click on another window to take focus away and then click again on the title bar of the mozilla window giving it focus you can see the folder list get the focus ring and the folder is highlighted. It could have something to do with that first focus that involves an NS_ACTIVATE event.
Now that I've played with this a bit it's much more simple. You don't need to have new messages. All you have to do is go from INBOX to another folder, click away really quickly, and then click in the thread folder and it's busted. There doesn't have to be new messages in the folder at all. The key is to get focus away from the toplevel mozilla window before the thread pane is given focus.
Attached patch patch — — Splinter Review
blizzard you rock. Patch looks reasonable, have to test it.
It's a start. It doesn't work when mozilla is embedded. I'm working on a patch that handles that case. It also comes with some other caveats that I need to open other bugs to get fixed since they are design related.
This is a gtk bug. All me. *sigh*
Assignee: sspitzer → blizzard
Status: ASSIGNED → NEW
Attached patch patch #2 — — Splinter Review
Here's what was happening to cause this bug: When you clicked on the folder it would start a load of the messages in the folder. If you clicked away from it the toplevel window would lose focus. When the folder load finished it would call |SetFocus| to set the focus on the thread pane. This is where things would start to go downhill. As part of that |SetFocus| call it would call gtk_widget_grab_focus() on the toplevel mozarea widget. This would cause the mozarea widget to get a focus_in signal and the widget would be labeled as having focus. When you gave focus back to the toplevel window the widget would never get a focus_in signal since it already thought that it had focus. Thus, it would never send the NS_ACTIVATE event and things would start going haywire. Here's how I fixed it: I don't grab the widget anymore in mozilla-the-browser. If the window doesn't have focus then I don't send any events. This is the way that things should work since the window doesn't actually receive focus. I still do grabs in the embedding case since it doesn't seem to hurt anything and it's needed to get the focus on the embedded window widget. Here's what it breaks: When you dingus click in mail/news and the already opened browser window is iconified it doesn't automatically pop up. Since I'm breaking this I thought it would be a good time to mention that I think that overloading |SetFocus| to have this functionality is a bad idea and lots of people who work with Mozilla on linux complain about it. I want to open another bug so that for those cases where we need to pop a window to the top of the stack someone has to call |GetAttention| on the widget. At least on Unix, |SetFocus| can not arbitrarily grab the focus since that has to be the sole domain of the window manager, not any one application. As far as I know this is only in a couple of places: Loading a url into another window like from mail/news or opening a new browser window with the little browser button in the lower left hand corner of the browser. How do people feel about this? Looking for reviews, too. Jump on in, one and all.
Oh, I also haven't seen bug #68004 since I've had this patch in my optimized build. It might be that I just haven't stumbled across it yet but I doubt it. I've been doing a full complement of mail/news, dingus clicking and web browsing for the last few hours.
Status: NEW → ASSIGNED
r=bryner
Breaking the behavior of the window coming forward on focus is a good thing, with the exception of new windows as you pointed out. I have bugs to make that stop happening on all platforms. I think the issue of new windows coming forward might have to be fixed before you land this patch though; modal dialogs could put us in a world of hurt if they don't come up front and center. I could be wrong too. BTW, this fixes the one reproduceable case for getting stuck in spacebar scrolling mode that I have, so it makes me happy!
I haven't run into a situation where dialogs don't come up. This only affects toplevel windows.
I havn't run into it either, was just a thought. r=saari
The first big comment about just returning doesn't seem to match the code at all. That should probably be fixed. nsWindow *mozAreaWindow = NS_STATIC_CAST(nsWindow * ... You have violated the sacred 80th column. Repent. Otherwise, it looks OK. sr=shaver, conditional on fixing the comment and feeling really, really guilty about the over-long line.
Attached patch final patch — — Splinter Review
Checked in. See bug #69664 about the window raising issue.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Using commercial build 2001-03-05 on winme, mac and linux and Chris's scenarios dated 2001-02-19 11:27 and dated 2001-02-09 10:46 and dated 2001-02-13 14:17 and dated 2001-02-19 11:14 this bug as originally stated is fixed. I will verify because the side affects of the fix has been logged. Also, if any of the focus/problems in mail/news that I didn't catch in this bug are still alive and well, maybe a new bug should be logged for them. Reopen if you disagree.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: