Closed Bug 340867 Opened 19 years ago Closed 18 years ago

have to click on the text in the folder pane now, instead of anywhere in the row to select mail folder

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9alpha8

People

(Reporter: Biesinger, Assigned: janv)

References

Details

(Keywords: regression)

In a current (today's) trunk build (seamonkey, linux, non-cairo gtk2) I have to click on the text in the folder pane to select a folder, rather than just anywhere in the row. this is a regression. seems to have been caused by bug 296040
is this distinguishable from bug 340811 ?
similar, but not the same issue
affects all
OS: Linux → All
Hardware: PC → All
Summary: have to click on the text in the folder pane now, instead of anywhere in the row → have to click on the text in the folder pane now, instead of anywhere in the row to select mail folder
So, the old tree used to display the text selection but behaved like a row selection. I think I can live with changing the tree back to row selection as I always use the drop-down which emulates row selection anyway ;-)
Who else should comment on this?
OS: All → Linux
Hardware: All → PC
CCing mail folks as mail/base/content/messenger.xul also has seltype="text"
*** Bug 340903 has been marked as a duplicate of this bug. ***
*** Bug 341264 has been marked as a duplicate of this bug. ***
For what it's worth, from an appearance point of view the text selection _looks_ much better here. So ideally the tree could have row selection behavior and text selection painting here...
Trees used in mail/news should definitely adhere to row selection, since cell base selection is almost meaningless there and just plain annoying.
(In reply to comment #0) > this is a regression. > > seems to have been caused by bug 296040 Is it possible, that https://bugzilla.mozilla.org/show_bug.cgi?id=340907 is a regression of this patch too?
Thanks for reporting this, Christian. I thought I was loosing my mind when most of my clicks in the folder pane started having no effect.
OS=ALL? This happens for me in windows.
Yes, on windows for me, too.
OS: Linux → All
Hardware: PC → All
Setting pseudo blocking request to keep this on the radar.
Whiteboard: blocking‑seamonkey1.5?
This appears to be a dupe of bug 340811, where there is a patch supposedly in progress.
Depends on: 340811
Whiteboard: blocking‑seamonkey1.5? → blocking-seamonkey1.5?
This is a huge regression in usability for mail/news clients on the trunk, and has been since June '06. One would have hoped that checkins that cause regressions like this one would have been forcibly backed out, but that clearly has not happened. How can we get relief for this regression? How can we get back to having selection in the folder pane behave like row selection, even if it displays like text selection? It should suffice to click ANYwhere in the row to select the folder in that row. That's how TB, App Suite, and SeaMonkey all behaved for years until this regression occured.
(In reply to comment #18) > It should suffice to click ANYwhere in the row to select the folder in > that row. That's how TB, App Suite, and SeaMonkey all behaved for years > until this regression occured. I think, we have to wait for the SeaMonkey Council. If they are ready with porting SM to the toolkit, they hopefully begin to fix some of this old bugs, as specially the bugs in the newspart of SM. I think Usenet have a bigger priority in the council than in MoCo. BTW: Is the status 'confirmed' no longer possible? I miss it for this bug.
Ruediger Lahl, this has nothing to do with the Seamonkey Council. This but is a core tree widget problem -- see bug 340811. Both the xpfe and toolkit tree widgets are broken in the same way.
(In reply to comment #9) > For what it's worth, from an appearance point of view the text selection > _looks_ much better here. So ideally the tree could have row selection > behavior and text selection painting here... > ok, so the tree widget now supports seltype="single|cell|text" for selection and painting folder panes uses seltype="text" and you want to add another attribute to specify different behavior of selection? selstyle="row"? it should be easy to add support for that http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tree.xml#1021 but is it really right thing to do? thunderbird uses row selection and Neil expressed an opinion that he can live with row selection too
I personally don't really want anything other than to have clicks work... Please take any aesthetic UI design suggestions I make with a large grain of salt.
so let's change it to seltype="single" for now, ok?
Assignee: mail → Jan.Varga
I wonder whether we'll end up reimplementing selection in the folder pane to fix the "double-click selects in both old and new windows" bug.
(In reply to comment #24) > I wonder whether we'll end up reimplementing selection in the folder pane to > fix the "double-click selects in both old and new windows" bug. While this may not be appropriate for Seamonkey, Thunderbird worked around that problem by making double-click on a node only perform expand/collapse -- arguably a less surprising UI. A new window can still be opened via context menu -- which doesn't force the original window to change selection.
Just updated to nightly 2006-12-31 (Windows) and clicking somewhere in the row works again for me. How and when did that happen?
does not WFM version 3 alpha 1 (20061231) windows
Ouch! I'm very sorry for that false alarm - I somehow managed to download 2005-12-31 ...
Moving to Core since TB is affected as well.
Component: MailNews: Main Mail Window → XP Toolkit/Widgets: Trees
Product: Mozilla Application Suite → Core
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
FYI, I am running TB 2.0.0.0 on my intel mac. It appears that this bug is no longer happening. I can click to the right of the visible name of a mail folder or newsgroup and the folder or newsgroup gets selected. Is anything known about how this may have been fixed?
(In reply to comment #32) > FYI, I am running TB 2.0.0.0 on my intel mac. It appears that this bug is no > longer happening. The bug is still their on my today-SM-Trunk 2007042604 on Vista.
(In reply to comment #32) > FYI, I am running TB 2.0.0.0 on my intel mac. It appears that this bug is no > longer happening. It's not fixed. TB 2.0.0.0 doesn't have this bug, the issue doesn't exist on the 1.8 branch.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/200708060303 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) This bug is V.Fixed after "2007-08-05 14:00 neil%parkwaycc.co.uk ... Switch folder pane back to full row selection b=340811" checkin.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: blocking-seamonkey1.5?
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9 M8
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.