Search messages window has no intrinsic way of closing itself.

RESOLVED FIXED

Status

SeaMonkey
MailNews: Message Display
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: bz, Assigned: Scott MacGregor)

Tracking

({access, fixed-aviary1.0})

Trunk
access, fixed-aviary1.0
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

Build: linux 2001-09-19-08 nightly.

Steps to reproduce:

1)  Open mailnews
2)  Select Search > Search Messages
3)  Try to close the resulting search window

Expected results:  A button, a menu, or a keyboard shortcut that will close the
                   window.

Actual results: have to use the windowmanager's window decorations or menus to
                close the window.
mpt sez no menu/button, but add a ctrl-w shortcut.  Over to mailwindow front end.
Assignee: mpt → sspitzer
Component: User Interface Design → Mail Window Front End
Product: Browser → MailNews
QA Contact: zach → esther
reviews?
Keywords: patch, review
Comment on attachment 50469 [details] [diff] [review]
Patch to add a keyboard shortcut

Working on a better approach (focus first textfield instead of vbox)
Attachment #50469 - Attachment is obsolete: true
Created attachment 50490 [details] [diff] [review]
Better patch (I'm starting to like xbl... :) )

Updated

17 years ago
QA Contact: esther → laurel

Updated

17 years ago
OS: Linux → All
Hardware: PC → All

Comment 6

17 years ago
Comment on attachment 50490 [details] [diff] [review]
Better patch (I'm starting to like xbl... :) )

This code looks good.

r=hwaara
Attachment #50490 - Flags: review+
some comments:

how do these changes affect the edit filter dialog?  looking at them, it looks
like it would put focus in the first term (for a new filter).  currently, it
looks like for a new filter (and an existing filter) we have focus in the filter
name area.

adding the call to searchVal.focus() in createSearchRow is bad for editing
existing filters, since we'll update focus on every row created, right?  where
does that leave the focus when we're done?

does hitting ctrl w do the right thing if a search is in progress?  make sure 
calling close() properly calls our onclose handler which stops the search.
*** Bug 95643 has been marked as a duplicate of this bug. ***
Comment on attachment 50490 [details] [diff] [review]
Better patch (I'm starting to like xbl... :) )

Seth, good points.  The edit filter
dialog would be adversely affected by this.

And onclose is _not_ called.

In view of that, and the fact
that focusing the textfield makes hitting
ctrl-w a pain on Linux anyway, I'm going to
attach a simpler patch.
Attachment #50490 - Attachment is obsolete: true
Created attachment 52041 [details] [diff] [review]
A more correct fix that avoids all the focus problems.

Comment 11

17 years ago
If you are just going to focus the outermost box, I don't see a reason to do it
manually at all.

Can't you just skip the .focus() call and do only the ctrl+w thing?
No, because then nothing has focus as the dialog comes up.  At that point
closing the dialog requires clicking on something first (or hitting tab then
ctrl-w, maybe; I have not tested that).  This seems poor from an accessibility
keyboard-only-UI-access standpoint.

Oh, and clicking on the main XUL window does _not_ focus it (a feature
apparently).  So you have to know to click on a form control if you're clicking.

Comment 13

17 years ago
Isn't window.close() supposed to notify the onclose event handler?

Doesn't seem like something that is supposed to be done manually.
According to hyatt, no.

window.close() will call onunload().

Clicking the windowmanager's [x] will call onclose() and then onunload()

Comment 15

17 years ago
May I ask why we have an onclose() at all if it's bogus (i.e., doesn't trigger
on window closure)?  This could be something serious we need to fix.
Hakan, onclose() triggers if the window is closed externally (ie by the
windowmanager).  I believe the assumption is that if we're closing the window
from inside the window itself we will handle closure properly.

The point of onclose() is that if it returns "false" the window is _not_ closed.
 In other words, onclose() is where you put things like confirmation dialogs
that allow the user to "cancel" closing a window that has unsaved content.

Or so I understand from talking to hyatt.
This is an accessibility issue..
Keywords: access

Comment 18

17 years ago
*** Bug 121437 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Summary: Search window in mailnews has no intrinsic way of closing itself. → Search messages window has no intrinsic way of closing itself.

Comment 19

16 years ago
*** Bug 123766 has been marked as a duplicate of this bug. ***
nominating for aviary1.0, and giving to Scott (punt as needed) to see if this
could be fixed for Thunderbird. on tbird this would be applicable to the Search
Messages and Search Addresses dialogs.

on a related tangent, see also bug 183419 --which requests adding a Close button.
Assignee: sspitzer → mscott
Flags: blocking-aviary1.0?
(Assignee)

Updated

14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
(Assignee)

Comment 21

14 years ago
Created attachment 160400 [details] [diff] [review]
updated fix

I made Boris's patch also work for the address book search dialog and the
filter list dialog. I had already hooked up escape to close all of these
dialogs. This patch just adds ctrl-W support.

I didn't seem to need the JS that set focus within the box anymore. It worked
fine without it. I wonder if something changed over the last couple years that
made that not necessary :)
Attachment #52041 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.