Closed Bug 362656 Opened 18 years ago Closed 4 years ago

view menu (mailview dropdown) exhibits strange behavior when keying through its options

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
Thunderbird 3

People

(Reporter: myk, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: H'n'C)

Attachments

(2 files, 2 obsolete files)

If I focus the View menu (f.e. by tabbing to it), then press the down arrow repeatedly to traverse its items, strange things happen.  The first couple presses just bring me to the "All" and "Unread" items, which behave as expected, but then I go to "Tags" and "Views", which have no apparent effect (since they represent submenus).

The next press displays "Tags" on the menu but opens up the dialog associated with the "Save View as a Folder..." item, which is the next item in the list (so it makes sense that I would land on that item, but it seems strange that it would cause the dialog to open automatically, and it's also strange that the menu would display "Tags" at that point).

After closing that dialog, the next press opens up the dialog associated with the "Customize..." item.

After closing that dialog, the view selected in it gets automatically selected, after which pressing the down arrow navigates through the views in the Custom Views" submenu until I reach the last view, at which point it jumps back to the All item at the top of the menu.

It seems like:

1. dialogs shouldn't open until the user selects the item after activating it (but perhaps the current behavior is the standard approach for accessibility);

2. the menu should not allow one to select the "Tags" and "Custom Views" submenu labels but rather traverse the submenus themselves;

3. the menu should display "Save View as a Folder..." and "Customize...", not "Tags", when activating those menu items;

4. closing the "Customize..." dialog should not result in the last selected item from the tree in that dialog being selected in the View menu.
I see this in Windows, too.  Strange behavior.  At one point, I had the Customize dialog keep popping up after I cleared it with <esc> or the Close button, but it did eventually stop recurring.
OS: Linux → All
Hardware: PC → All
Summary: view menu exhibits strange behavior when keying through its options → view menu (mailview dropdown) exhibits strange behavior when keying through its options
(In reply to comment #1)
> I see this in Windows, too.  Strange behavior.  At one point, I had the
> Customize dialog keep popping up after I cleared it with <esc> or the Close
> button, but it did eventually stop recurring.

I spoke too soon -- it did not stop recurring.  I thought it had because TB started sucking down CPU and spinning before popping the window back up.  I was unable to clear the dialog for good.  I'll see if I can come up with Steps to Reproduce this virtual hang.
Severity: minor → major
Flags: blocking-thunderbird2?
(In reply to comment #2)
> I was unable to clear the dialog for good.

Oh, I see bug 362567 is about this problem.  Sorry!  I'll reset this.
Severity: major → minor
Flags: blocking-thunderbird2?
Target Milestone: --- → Thunderbird2.0
> The next press displays "Tags" on the menu but opens up the dialog associated
> with the "Save View as a Folder..." item, which is the next item in the list
> (so it makes sense that I would land on that item, but it seems strange that
> it would cause the dialog to open automatically, and it's also strange that 
> the menu would display "Tags" at that point).

This behaviour is not new, in fact it should be there since it was introduced.
(I wonder if there isn't an old bug already filed, probably against the suite?)

> 1. dialogs shouldn't open until the user selects the item after activating it
> (but perhaps the current behavior is the standard approach for accessibility);

If you're keying down a collapsed list, each item gets activated as you step on it, thus the dialogs open. Otherwise, the shown dropdown state would not correspond with the actual state of affairs it controls...

> 2. the menu should not allow one to select the "Tags" and "Custom Views"
> submenu labels but rather traverse the submenus themselves;

Again, that's probably not a view dropdown problem but a core/widget problem, that's how we do it anywhere else, too.

> 3. the menu should display "Save View as a Folder..." and "Customize...", not
> "Tags", when activating those menu items;

Yeah, probably. I'll look into that.

> 4. closing the "Customize..." dialog should not result in the last selected
> item from the tree in that dialog being selected in the View menu.

That's arguable, but you should file another bug for it.
> > 2. the menu should not allow one to select the "Tags" and "Custom Views"
> > submenu labels but rather traverse the submenus themselves;
> 
> Again, that's probably not a view dropdown problem but a core/widget problem,
> that's how we do it anywhere else, too.

I haven't seen the discussion that resulted in the creation of these submenus, but presumably they were created to make the many items in the View menu more manageable.  But submenus have manageability problems of their own.  I suggest we retain a single menu but make "Tags" and "Custom Views" be option headings, just as accounts are headings in menus for selecting a folder.

That would accomplish the same goal of improving manageability while offering the advantage of retaining the ability to easily navigate to a tag or custom view with the keyboard.


> > 4. closing the "Customize..." dialog should not result in the last selected
> > item from the tree in that dialog being selected in the View menu.
> 
> That's arguable, but you should file another bug for it.

Ok, I filed this as bug 362990.
(In reply to comment #5)
> > > 2. the menu should not allow one to select the "Tags" and "Custom Views"
> > > submenu labels but rather traverse the submenus themselves;
> > 
> > Again, that's probably not a view dropdown problem but a core/widget problem,
> > that's how we do it anywhere else, too.
> 
> I haven't seen the discussion that resulted in the creation of these submenus,
> but presumably they were created to make the many items in the View menu more
> manageable.  But submenus have manageability problems of their own.  I suggest
> we retain a single menu but make "Tags" and "Custom Views" be option headings,
> just as accounts are headings in menus for selecting a folder.
> 
> That would accomplish the same goal of improving manageability while offering
> the advantage of retaining the ability to easily navigate to a tag or custom
> view with the keyboard.

I like this idea too. Karsten's been the main views guru recently doing most of the work here, so I'd like to know what he thinks as well. This change would be consistent with the work Neil and I did for the folder drop down picker in the search dialog and folder location toolbar buttons where the submenus were flattened out into a single list.
> > but presumably they were created to make the many items in the View menu 
> > more manageable.

Yes, the drop down could get very large. I actually mimicked the dropdown in the Message Filters dialog which has this submenu structure, too.

> > I suggest we retain a single menu but make "Tags" and "Custom Views" be
> > option headings, just as accounts are headings in menus for selecting a 
> > folder.

I'm somewhat split. Having to key through all tags just to select a custom view (or vice versa) is pretty painful. Furthermore, using arrow keys in a dropdown will result in showing the popup on Mac anyway, although Windows does this on ALT+arrow only.  

> > That would accomplish the same goal of improving manageability while 
> > offering the advantage of retaining the ability to easily navigate to a tag 
> > or custom view with the keyboard.

IMO, manually opening the dropdown _popup_ and then keying through the submenu structure is much easier to navigate than a closed (one line!) dropdown.
Furthermore, keying through the closed dropdown will result in all views touched being applied while looking for the one you want - not very performant... The dropdown popup only applies a new view on activation.

> This change would be consistent with the work Neil and I did for the folder 
> drop down picker in the search dialog and folder location toolbar buttons
> where the submenus were flattened out into a single list.

True, but especially using the closed location bar is a real pain for keying through eg newsgroups... 
(In reply to comment #7)
> > > but presumably they were created to make the many items in the View menu 
> > > more manageable.
> 
> Yes, the drop down could get very large. I actually mimicked the dropdown in
> the Message Filters dialog which has this submenu structure, too.

I suspect the number of tags & user created mail views is going to be much smaller than say the list of all known folders that we show in the message filters dialog. (which uses submenus). I think in most use cases, showing a flat list for tags & views would be reasonable. My two cents. :)
(In reply to comment #8)
>I think in most use cases, showing a flat list for tags & views would be reasonable.
You would have to populate the list using the focus event rather than the open event - would that be reasonable?
(In reply to comment #9)
> (In reply to comment #8)
> >I think in most use cases, showing a flat list for tags & views would be reasonable.
> You would have to populate the list using the focus event rather than the open
> event - would that be reasonable?
> 

I think it would be. :)
Yes, I think a flat list should work -- otherwise: make it configurable?
Attached patch View Picker Overhaul, v1 (obsolete) — Splinter Review
This patch (for both SM and TB)
* turns the View: label into a dropdownbutton with the (new) default option "Reload View" and the dialog-opening items "Save as Folder" and "Customize", taken off the view list.
* renders the tags and custom items lists in the view list "flatly", as long as at most 10 (pref'd by mailnews.flat_views_max) are there. A submenu is used only if there are more.
* fixes a bug with the checked state of the view menuitems on Mac.
Assignee: mscott → mnyromyr
Status: NEW → ASSIGNED
Attachment #315674 - Flags: superreview?(dmose)
Attachment #315674 - Flags: review?(neil)
Whiteboard: H'n'C
Severity: minor → normal
Flags: wanted-thunderbird3.0a1?
Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.
Flags: wanted-thunderbird3.0a1? → wanted-thunderbird3.0a2?
Comment on attachment 315674 [details] [diff] [review]
View Picker Overhaul, v1

I don't like the dropdown button. Maybe you can use a context menu instead?

>+        <menupopup id="viewMessagePopup"
>+                   onpopupshowing="RefreshAllViewPopups(this, false);">
>+            <menupopup id="viewMessageTagsPopup"
>+                       onpopupshowing="RefreshTagsPopup(this, false);"/>
>+            <menupopup id="viewMessageCustomViewsPopup"
>+                       onpopupshowing="RefreshCustomViewsPopup(this, false);"/>
You're doing an awful lot of unnecessary refreshing. When the main popup opens you refresh both the tags and the custom views, which is OK, but then when a submenu opens you refresh it again although you already refreshed it opening the menu and then the event bubbles up and you refresh everything again...

>+  var item = submenu.previousSibling;
>+  while (item && item.localName != "menuseparator")
>+  {
>+    var next = item.previousSibling;
>+    mainpopup.removeChild(item);
>+    item = next;
Nit: could use item = submenu.previousSibling;
Attachment #315674 - Flags: review?(neil) → review-
Attached patch View Picker Overhaul, v2 (obsolete) — Splinter Review
Fixed some nits and edges:
> I don't like the dropdown button. 

Uh. This should have been of type="menu-button", not "menu". Fixed.
Also needed some additional styles for Classic/Pinstripe/Qute, because obviously noone ever used a <button type="menu-button"/> yet. ;-)

> You're doing an awful lot of unnecessary refreshing.

Fixed.

> Nit: could use item = submenu.previousSibling;

Or even drop item entirely. Fixed.
Attachment #315674 - Attachment is obsolete: true
Attachment #323782 - Flags: superreview?(bienvenu)
Attachment #323782 - Flags: review?(neil)
Attachment #315674 - Flags: superreview?(dmose)
(In reply to comment #15)
> Created an attachment (id=323782) [details]
> Fixed some nits and edges:
> > I don't like the dropdown button. 
> Uh. This should have been of type="menu-button", not "menu". Fixed.
I guess once our toolbars are customisable it won't be a problem, but it still looks like useless clutter to me ;-)
> Also needed some additional styles for Classic/Pinstripe/Qute, because
> obviously noone ever used a <button type="menu-button"/> yet. ;-)
Wow, those broken styles go way back. I don't suppose you could fix toolkit?

> > You're doing an awful lot of unnecessary refreshing.
> Fixed.
Not quite; popupshowing events still bubble.
(In reply to comment #16)
> > Also needed some additional styles for Classic/Pinstripe/Qute, because
> > obviously noone ever used a <button type="menu-button"/> yet. ;-)
> Wow, those broken styles go way back. I don't suppose you could fix toolkit?

I'll try, but rather in separate "thread". :-|
Let these styles go in here until some day toolkit is fixed. 

> > > You're doing an awful lot of unnecessary refreshing.
> > Fixed.
> Not quite; popupshowing events still bubble.

*sigh* Veeenkmaan!  ;-)
Assignee: mnyromyr → nobody
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Assignee: nobody → mnyromyr
Status: ASSIGNED → NEW
wanted‑thunderbird3.0a2+; we have a patch in progress.
Flags: wanted-thunderbird3.0a2? → wanted-thunderbird3.0a2+
Target Milestone: Thunderbird2.0 → Thunderbird 3
cc'ing Brian - this is a significant change to the view menu, if I'm understanding it correctly. It adds a separate button/drop down for reload/save as saved search/customize, and changes the way the view picker decides to make sub-menus.

One nit - I don't think "save as folder" is consistent with the rest of our ui since you're really creating a saved search - I would think it would be "save as saved search", even though that's a bit awkward.
While we're on the topic, I'd like to suggest that we rethink the terminology of saved searches, btw -- I don't think most users have a clue what those are.  Mail.app calls them Smart Mailbox, (just like iTunes calls them Smart Playlists), and I think that would be a fine concept to riff off of.  Smart Folders?
Comment on attachment 323782 [details] [diff] [review]
View Picker Overhaul, v2

adding ui review request.

Re Smart Folders, the name by itself doesn't really help the user know what they do. If we created some of them automatically, then that'd be smart :-)

I can't remember what Outlook called these. We used to call them Virtual Folders, but decided that wasn't very meaningful, so we changed the name to Saved Searches...
Attachment #323782 - Flags: ui-review?(clarkbw)
(In reply to comment #20)
> While we're on the topic, I'd like to suggest that we rethink the terminology
> of saved searches
Agreed, but we should probably open a separate bug for "Smart" vs. "Saved", since we'd want to be a bit more consistent across Thunderbird with that change.  My preference would be toward something like "Smart" as it's an active (and now widely used) term where "Saved" sounds a bit more static as if it's just going to keep the mail that I see right now without updating later.
For reference, here's what the view menu currently looks like.
Comment on attachment 323782 [details] [diff] [review]
View Picker Overhaul, v2

I'm a bit unsure, I have two questions and I'll try to upload a pic of the second one for more clarity.

1. Do we need the reload view option?  Shouldn't the view be updating without reload?

2. Can we keep a visual relationship between the view label/button and the drop down?  I'm afraid by separating it out into a button and a drop down we'll lose the meaning.

Other than those questions I think the changes are good.
Attached image flattened view button
Here I flattened out the view button into just a label and created an arrow button for that view popout.  Not sure about the technical possibilities of this, but my goal is to convey keeping the visual connection between the two elements.  So is something near to this workable?
(In reply to comment #24)
> 1. Do we need the reload view option?

Yes. 

> Shouldn't the view be updating without reload?

No, and currently it doesn't.

Imagine using the Unread view with default settings for 'mark as read': 
As soon as you'd read a messages, the message won't be unread anymore and disappears from the view. The next message would get displayed and marked as read and disappear. And so on.

Apart from technical problems, I also think it's not even desirable: setting status values like read/junk/etc. or tags would make messages disappear in a very confusing manner - and it'd be quite arduous to undo.

> 2. Can we keep a visual relationship between the view label/button and the
> drop down?  I'm afraid by separating it out into a button and a drop down
> we'll lose the meaning.

Not much space for drawing a groupbox around it in SM, but such a box would fit into TB's toolbar. (SM could just hide the box by CSS.)

+- Mailviews ----------------------+
| +-------+--+ +--------------+--+ |
| | View: |\/| | Unread       |\/| |
| +-------+--+ +--------------+--+ |
+----------------------------------+

or

+- Mailviews ------------------------+
| +--------------+--+ +---------+--+ |
| | Unread       |\/| | Actions |\/| |
| +--------------+--+ +---------+--+ |
+------------------------------------+

We probably could minimize the distance between button and dropdown even more, but that'd easily look kludgy...

(In reply to comment #25)
> Here I flattened out the view button into just a label and created an arrow
> button for that view popout.

I doubt that a small stray arrow button would be very usable or comprehendable. It'd look rather strange, imo. And it'd be hard to use, even with a mouse.

> Not sure about the technical possibilities of this, but my goal is to convey
> keeping the visual connection between the two elements.  So is something
> near to this workable?

The technical side is not the problem.
(In reply to comment #26)
> > 1. Do we need the reload view option?
> 
> Yes. 

WRT "need": it would be handy to have, and users have even asked for it (although I can't find any bug on that currently, my Bugzilla foo is rather low again).
> (In reply to comment #24)
> > Shouldn't the view be updating without reload?
> 
> No, and currently it doesn't.
> 
> Imagine using the Unread view with default settings for 'mark as read': 
> As soon as you'd read a messages, the message won't be unread anymore and
> disappears from the view. The next message would get displayed and marked as
> read and disappear. And so on.

In Thunderbird 2, views do get updated automatically, but only to add messages.  Automatic updates don't remove messages currently in the view, even if they no longer meet the view criteria.

So messages marked read don't disappear from the Unread view, even when new unread messages appear.  Once you select a different view, of course, the list gets updated with the current set of messages that meets the new view's criteria.

This seems like reasonable behavior, and it doesn't require a "reload view" option (although it doesn't preclude the UI from having one, and I could imagine it being useful in some cases).


(In reply to comment #27)
> (In reply to comment #26)
> > > 1. Do we need the reload view option?
> > 
> > Yes. 
> 
> WRT "need": it would be handy to have, and users have even asked for it
> (although I can't find any bug on that currently, my Bugzilla foo is rather low
> again).

Perhaps I misunderstand, but isn't adding a "reload view" option a bit of a separate bug from this one, which is about funky behavior of the list during keyboard navigation?
> This seems like reasonable behavior, and it doesn't require a "reload view"
> option (although it doesn't preclude the UI from having one, and I could
> imagine it being useful in some cases).

That's what I meant.

> Perhaps I misunderstand, but isn't adding a "reload view" option a bit of a
> separate bug from this one, which is about funky behavior of the list during
> keyboard navigation?

Well, to fix the "funky behaviour", I moved the actions out the list into a dual menu button - and used the occasion to add a no-brainer collateral fix. It doesn't make the actual fix substantially more/less difficult.
I think a flattened view wouldn't work very well when you have a decent amount of tags. 

Late to the party, but I recalled bug 395985 - the idea there would be very handy indeed. (Though not necessarily the suggested UI.)
> I think a flattened view wouldn't work very well when you have a decent amount
> of tags. 

See comment #12.

Comment on attachment 323782 [details] [diff] [review]
View Picker Overhaul, v2

This patch has bitrotted quite a lot.

So, do we have any plan here? Bryan?
Rereading this over I think at this point we were just looking into fixing some styling issues.  I was a little hesitant about the reload view action, but if it clears up some odd behaviour issues we should probably just stick with it.
Comment on attachment 323782 [details] [diff] [review]
View Picker Overhaul, v2

bitrotted per comment #32. :(
Attachment #323782 - Attachment is obsolete: true
Attachment #323782 - Flags: ui-review?(clarkbw)
Attachment #323782 - Flags: superreview?(bienvenu)
Attachment #323782 - Flags: review?(neil)
All the msgViewPickerOverlay.* stuff is now forked.
Since TB seems to be uninterested in this, I'd like to move it over to SeaMonkey to get it fixed there finally. 
Dissenting votes?
(In reply to comment #35)
> All the msgViewPickerOverlay.* stuff is now forked.
> Since TB seems to be uninterested in this, I'd like to move it over to
> SeaMonkey to get it fixed there finally. 
> Dissenting votes?

Given Bryan's comment 34 and the previous comments, could you not just clone this bug and leave the comments and ideas here for TB folks to find if we want to pick this up again later?
> Given Bryan's comment 34

?

> and the previous comments, could you not just clone this bug and leave the
> comments and ideas here for TB folks to find if we want to pick this up again
> later?

Sure, but if noone would have objected, it'd have been easier. *g*
Cloned SeaMonkey portion as bug 500919.
Assignee: mnyromyr → nobody
related it seems, is arrow keys don't work after alt+i accesskey.  Sometimes view changes on first hit, sometimes not, and sometimes never.
Keywords: access

Jean-Philippe, is there still an issue here?

Flags: needinfo?(jpmengual)

Hi,

I absolutely dont reproduce this bug. I guess it has been fidex for years, I had never experienced it but not used T 11 years ago.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jpmengual)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: