Closed
Bug 112714
Opened 23 years ago
Closed 22 years ago
Hidden Filter rules blocks menus,selection. Must Alt+Tab to foreground.
Categories
(SeaMonkey :: MailNews: Message Display, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: laurel, Assigned: naving)
References
Details
(Whiteboard: [adt2 rtm] [Needs a=])
Attachments
(1 obsolete file)
Using nov28-29 commercial trunk build, linux rh6.2 After launching a prefill filter "Create Filter" rules dialog you can click in the main mail window causing the filter rules dialog to be hidden, but you can't use any mail menus or select anything. Alt+Tab will bring filter dialog to foreground where you can dismiss it and regain mail window composure. 1. Select a mail message in the 3-pane window. 2. Click on an address header in the header envelope --> select Create Filter. Filter rules dialog appears with info prefilled. 3. Click in the mail window. 4. Try to access mail window Message menu or click on header again. This is supposed to cause an alert window to let you know there's a filter rules dialog open and then surface it. Result: it does nothing. Gives user appearance mail might be hanging. 5. Alt+Tab to get the filter rules dialog to surface, then you can dismiss and regain use of the mail window. Result: hidden prefilled filter rules dialog hangs on to focus rendering mail menus, operations useless. Must Alt+Tab or use system task/window bar to bring filter rules to foreground to resolve situation.
FYI -- Mac behaves differently, filter rules stays in foreground until dismissed but still can't use mail window. Shouldn't we allow mail window usage even if the rules dialog is open?
QA Contact: esther → laurel
Summary: Linux: Hidden Create Filter rules blocks menus,selection. Must Alt+Tab to foreground. → Hidden Create Filter rules blocks menus,selection. Must Alt+Tab to foreground.
Summary: Hidden Create Filter rules blocks menus,selection. Must Alt+Tab to foreground. → Hidden Filter rules blocks menus,selection. Must Alt+Tab to foreground.
Comment 2•23 years ago
|
||
I just wanted to add the comment that on Windows, I can't really do anything either. It lets me select another IMAP message, but it won't load until I dismiss the window. We should either make this modal or make it so that it doesn't block the 3 pane window.
Status: NEW → ASSIGNED
Updated•23 years ago
|
Updated•22 years ago
|
Target Milestone: --- → mozilla1.0
this bugs depends on 127919 that prevents modal dependant windows being created during the onload of the original window. I suggest the following fix. In the scenario where the message filter window is not up already and the user clicks on the Create Filter - the (new filter) Filter Rules dialog is opened in a non-modal way. This would mean two things. Pros: The UI thread is not locked up and allows the user to move on if the filter window is pushed to the background. Cons: The newly created Message Filters dialog would be visible as well as clickable. I dont know if the other bug is going to be fixed anytime soon and therefore I think that this solution is better than stranding the user if the filter window loses the focus to other windows. Jennifer could you give your thoughts on this?
No longer depends on: 127919
Assignee | ||
Comment 4•22 years ago
|
||
This is basically what I suggested to fix another bug because of this modal problem - bug 127370
Note: I'm getting weird behavior with the Main Mail window when I open the Message Filters and Filter Rules dialogs and then go back to Main Mail window. These dialogs should be modal to the Main Mail window like 4.x. For Create a Filter, user clicks on an address header in the header envelope --> select Create Filter. Both the Message Filters dialog and Filter Rules dialog should open (FR on top of MF) and they should be modal (FR to MF) to the Main Mail or Mail Compose window. Varada, does your comment mean this is not possible right now?
The FR is currently modal to the MF window but the MF has never been modal to the Mail window. You can always click on the mail window when the MF window is up there . If you want the FR ->MF->MailWindow to be all modal then we dont have a problem. The user will never be able to click on the mailwindow once he has clicked on CreateFilter and we wont have this bug. I was under the assumption that the MF window needs to be non modal w.r.t. Main Mail window.
>If you want the FR ->MF->MailWindow to be all modal then we dont have a
>problem.
That was how 4.x worked. What do you think of doing it that way? I can't think
of any reason the user would Need to return to the Main Mail window once they
started to create a filter.
laurel, scott - do you have any problems with jennifer's approach to make all the windows modal one on top of the other. jennifer - will this be the case only for createfilter or also for the regular filters?
if we can reach an accord on this by today we can get it into the tree when it opens.
Reporter | ||
Comment 10•22 years ago
|
||
I will bow to whatever is decided on by everyone else. My personal usage is such that I do find I sometimes go to the mail window when in the midst of creating a filter. I seem to remember some flack about the way 4.x was, but I could be wrong.
Comment 11•22 years ago
|
||
I im'd with scottip briefly this am and he is fine with either. I don't feel strongly one way or the other. My inclination is to make FR->MF->MailWindow modal, like 4.x. Both from the normal path and the Create a Filter path.
Comment 12•22 years ago
|
||
If there are no more objections - I am going to go ahead and implement the Message Filters Dialog and Filter Rules dialog as being modal.
Comment 13•22 years ago
|
||
They are already modal when opened the traditional way; you need to put in the modal flags in the openDialog() call for this new menuitem.
Comment 14•22 years ago
|
||
I'm fine with it being modal.
Comment 15•22 years ago
|
||
Sorry, on a second thought; I don't think this should be made modal. As said in comment 10 by laurel, it's quite common that users go to the mail window when creating a filter (to find out an email address or name they want to filter). Varada, if I understand this bug correctly, is there no way of using the window-mediator (like I already implemented, in a way), to check if a filter rules window is open and then just focus it or something? If there is a cleaner way that just modalizing all dialogs, I would argue we try to do that instead.
Comment 16•22 years ago
|
||
This makes the message filter as well as filter editor windows modal. This will prevent the user from accessing the mail window while creating a filter or viewing message filters but will solve the problem of locking up the UI thread. Navin could you review this patch. I tested the case of being able to create a new folder in the filter editor window and it worked but there might be other cases that you would like to try.
Assignee | ||
Comment 17•22 years ago
|
||
Comment on attachment 72660 [details] [diff] [review] Patch V.1 r=naving, wow making modal really cleans up lot of code !! the changes look good, please try few more test case - going back and forth between these 3 windows mail 3pane, MF, FR The filter editor window was already modal to the filter list window, I don't see this patch changing that behavior
Attachment #72660 -
Flags: review+
Comment 18•22 years ago
|
||
Comment on attachment 72660 [details] [diff] [review] Patch V.1 sr=bienvenu
Attachment #72660 -
Flags: superreview+
Updated•22 years ago
|
Attachment #72660 -
Flags: approval+
Comment 19•22 years ago
|
||
Comment on attachment 72660 [details] [diff] [review] Patch V.1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Comment 20•22 years ago
|
||
Marking Fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 21•22 years ago
|
||
Using mar07 commercial trunk: Not working correctly. 1. linux rh6.2: same thing. Filter rules will still go to background when clicking mail window... mail window and open browser window unresponsive, must use Alt+Tab to surface the filter rules dialog again. Same as when written. 2. win98: (maybe a separate bug needed) Can't get to mail window, but if you switch to browser window and try to use the menu Tasks|Mail&Newsgroups or the netscape task bar to get the mail window to surface (with the filter rules) nothing happens. Can't resurface mail window by menu or task bar while the filter rules is open. Must Alt+Tab. 3. macOS 10.1: Can't click in mail window per se, but can in mail window's title bar then mail window is accessible with the filter rules dialog in background. Haven't tried mac OS 9.2 yet. Anyway, linux is still in same state. Don't know if we want to track the other platforms' behavior separately...let me know.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 22•22 years ago
|
||
On Win NT I see that you can't use the Task menu from the browser, but I can click on the taskbar and get back to the mail window which has a modal filter rules dialog on top of it as expected. On Win 98, you can't click on the taskbar?
Reporter | ||
Comment 23•22 years ago
|
||
On win98 I can't get to mail window via Tasks menu or Netscape's task bar, but I can get to mail via the system task bar or Alt+Tab.
Comment 24•22 years ago
|
||
Moving out because it's possible to get back on Windows by using the Windows taskbar.
Comment 25•22 years ago
|
||
Comment on attachment 72660 [details] [diff] [review] Patch V.1 obsoleting patch which was already landed.
Attachment #72660 -
Attachment is obsolete: true
Reporter | ||
Comment 26•22 years ago
|
||
*** Bug 142652 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
On linux RC1, this modal dialog blocks the browser window too. Why in the world should creating a mail filter keep me from surfing the web?
Reporter | ||
Comment 28•22 years ago
|
||
Yes, I agree with comment #27 for the browser, as this is the same behavior noted in comment #21, first point in the list.
Assignee | ||
Comment 29•22 years ago
|
||
taking, I've fixed this on trunk.
Assignee: varada → naving
Status: REOPENED → NEW
Assignee | ||
Comment 30•22 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 31•22 years ago
|
||
What's the status of this for RTM? The nsbeta1- was given a long time ago... Doesn't this tie in somehow with the fix for prefill filters (140591)?
Assignee | ||
Comment 32•22 years ago
|
||
yes, this will be fixed by fix in bug 140591. I changed the design of how prefill filters work. So this should be nsbeta1+.
Reporter | ||
Comment 33•22 years ago
|
||
Please reiterate what is the intended change in behavior after the recent fix to prefill filters.
Reporter | ||
Comment 34•22 years ago
|
||
Looks OK on may20 trunk build: win98, linux rh6.2, mac OS 10.1 Marking verified on trunk. Leaving any keyword/rating stuff for RTM up to putterman/naving/adt. The rules dialog will not bring up a filter list dialog when you Cancel. The rules dialog is modal to its mail window from whence it was launched (if multiple mail windows, each filter rules is modal to its relative window). If the rules dialog (or even filter list & rules) is open, an open browser window is reachable via Alt+Tab or switch on system task bar and is usable. If multiple mail windows open, any which do not have a filter dialog tied to it is accessible and usable. (However, if switching from browser to mail window via the Window menu, you won't see the mail window surface with its filter dialog, you must switch directly to the open filter dialog as its own window.)
Status: RESOLVED → VERIFIED
Updated•22 years ago
|
Comment 35•22 years ago
|
||
adt1.0.0+ (on ADT's behalf) for approval to checkin to the 1.0 branch, pending Driver's re-approval (e.g. a= is older than 3 days). After, checking in, please add the fixed1.0 keyword.
Comment 36•22 years ago
|
||
changing to adt1.0.1+ for checkin to the 1.0 branch. Please get drivers approval before checking in.
Comment 38•22 years ago
|
||
it appears as though this is fixed on the 1.0.1 branch and that 140591 is fixed on the 1.0.1 branch too. looks like this should have fixed1.0.1 keyword; no?
Assignee | ||
Comment 39•22 years ago
|
||
right, adding fixed1.0.1 keyword.
Keywords: mozilla1.0.1 → fixed1.0.1
Reporter | ||
Comment 40•22 years ago
|
||
OK with june20 branch: win98,mac OS 10.1, linux rh6.2
Keywords: fixed1.0.1 → verified1.0.1
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•