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)
Core
XUL
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
Comment 1•19 years ago
|
||
is this distinguishable from bug 340811 ?
Assignee | ||
Comment 2•19 years ago
|
||
similar, but not the same issue
Reporter | ||
Updated•19 years ago
|
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
Comment 4•19 years ago
|
||
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 ;-)
Assignee | ||
Comment 5•19 years ago
|
||
Who else should comment on this?
OS: All → Linux
Hardware: All → PC
Comment 6•19 years ago
|
||
CCing mail folks as mail/base/content/messenger.xul also has seltype="text"
Comment 7•19 years ago
|
||
*** Bug 340903 has been marked as a duplicate of this bug. ***
Comment 8•19 years ago
|
||
*** Bug 341264 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 9•19 years ago
|
||
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...
Assignee | ||
Comment 10•19 years ago
|
||
The added check is here:
http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tree.xml#760
Comment 11•19 years ago
|
||
Trees used in mail/news should definitely adhere to row selection, since cell base selection is almost meaningless there and just plain annoying.
Comment 12•19 years ago
|
||
(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?
Comment 13•19 years ago
|
||
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.
Comment 14•19 years ago
|
||
OS=ALL? This happens for me in windows.
Comment 15•19 years ago
|
||
Yes, on windows for me, too.
Reporter | ||
Updated•19 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 16•19 years ago
|
||
Setting pseudo blocking request to keep this on the radar.
Whiteboard: blocking‑seamonkey1.5?
Comment 17•19 years ago
|
||
This appears to be a dupe of bug 340811, where there is a patch supposedly in progress.
Updated•19 years ago
|
Whiteboard: blocking‑seamonkey1.5? → blocking-seamonkey1.5?
Comment 18•19 years ago
|
||
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.
Comment 19•19 years ago
|
||
(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.
![]() |
||
Comment 20•19 years ago
|
||
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.
Assignee | ||
Comment 21•19 years ago
|
||
(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
![]() |
||
Comment 22•19 years ago
|
||
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.
Assignee | ||
Comment 23•19 years ago
|
||
so let's change it to seltype="single" for now, ok?
Assignee: mail → Jan.Varga
Comment 24•19 years ago
|
||
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.
Comment 25•19 years ago
|
||
(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.
Comment 26•19 years ago
|
||
Just updated to nightly 2006-12-31 (Windows) and clicking somewhere in the row works again for me. How and when did that happen?
Comment 27•19 years ago
|
||
does not WFM version 3 alpha 1 (20061231) windows
Comment 28•19 years ago
|
||
Ouch! I'm very sorry for that false alarm - I somehow managed to download 2005-12-31 ...
Comment 31•18 years ago
|
||
Moving to Core since TB is affected as well.
Component: MailNews: Main Mail Window → XP Toolkit/Widgets: Trees
Product: Mozilla Application Suite → Core
Updated•18 years ago
|
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Comment 32•18 years ago
|
||
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?
Comment 33•18 years ago
|
||
(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.
Comment 34•18 years ago
|
||
(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.
Comment 35•18 years ago
|
||
[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?
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
Updated•18 years ago
|
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.
Description
•