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)

x86
Linux
defect

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.
Keywords: nsbeta1
Summary: Hidden Create Filter rules blocks menus,selection. Must Alt+Tab to foreground. → Hidden Filter rules blocks menus,selection. Must Alt+Tab to foreground.
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
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla1.0
Depends on: 127919
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
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.
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.
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.
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.
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.
I'm fine with it being modal.  
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.
Attached patch Patch V.1 (obsolete) — Splinter Review
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.
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 on attachment 72660 [details] [diff] [review]
Patch V.1

sr=bienvenu
Attachment #72660 - Flags: superreview+
Attachment #72660 - Flags: approval+
Comment on attachment 72660 [details] [diff] [review]
Patch V.1

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Blocks: 127370
Marking Fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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 → ---
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?
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.
Moving out because it's possible to get back on Windows by using the Windows
taskbar.
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
Comment on attachment 72660 [details] [diff] [review]
Patch V.1

obsoleting patch which was already landed.
Attachment #72660 - Attachment is obsolete: true
*** Bug 142652 has been marked as a duplicate of this bug. ***
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? 
Yes, I agree with comment #27 for the browser, as this is the same behavior
noted in comment #21, first point in the list.
taking, I've fixed this on trunk. 
Assignee: varada → naving
Status: REOPENED → NEW
fixed
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
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)?
yes, this will be fixed by fix in bug 140591. I changed the design of how prefill
filters work. So this should be nsbeta1+. 
Please reiterate what is the intended change in behavior after the recent fix to
prefill filters.
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
Keywords: nsbeta1-adt1.0.0, nsbeta1+
Whiteboard: [adt2 rtm]
Keywords: approval
Whiteboard: [adt2 rtm] → [adt2 rtm] [Needs a=]
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.
Keywords: adt1.0.0adt1.0.0+
Whiteboard: [adt2 rtm] [Needs a=] → [adt2 rtm]
Blocks: 143047
Whiteboard: [adt2 rtm] → [adt2 rtm] [Needs a=]
changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.
Keywords: adt1.0.0+adt1.0.1+
Adding mozilla1.0.1 nomination.
Keywords: mozilla1.0.1
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?
right, adding fixed1.0.1 keyword.
Keywords: mozilla1.0.1fixed1.0.1
OK with june20 branch: win98,mac OS 10.1, linux rh6.2
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: