Closed Bug 618467 Opened 14 years ago Closed 13 years ago

pane separator problem - too thin, can't tell what a click would do

Categories

(Thunderbird :: Theme, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.3a2

People

(Reporter: jack, Assigned: Paenglab)

References

Details

(Keywords: regression)

Attachments

(2 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101210 Firefox/4.0b8pre
Build Identifier: http://hg.mozilla.org/mozilla-central/rev/2705b22189f9

Quite often, when I try to resize a window pane, it's unnecessarily hard to do.  The new theme on windows 7 somewhat exacerbates this.  I don't think I even noticed on the old theme.

The separator between panes (between the message list, a message, or the folder list) appears as only one pixel wide;  I believe the click-able area of the separator may be wide (maybe just 2) but it's hard to say for sure.  The usual method of telling is that the cursor will change to a two-headed arrow, but that is not working most of the time.  Probably most of the time, there is some pending command submitted to the email server (this may be an unrelated problem but it's certainly commonplace in my experience), so instead of showing the two-headed arrow, it only shows the wait indicator (pointer + spinny thing, as opposed to just the large spinny thing).


Reproducible: Always

Steps to Reproduce:
1. Use new theme
2. Try to stretch pane

Actual Results:  
The mouse cursor does not indicate whether you can stretch

Expected Results:  
It should be easy to tell whether the mouse is positioned to click for pane-resizing
This may have been done on purpose in bug 545557 for reasons of style, but I agree that it's hard to realize that there actually is a splitter.
Blocks: 545557
Keywords: regression
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Theme
Ever confirmed: true
QA Contact: front-end → theme
The thin-ness is just one contributing factor, and yes, I'd love to see it widened.  The state of the mouse cursor is just as bad, though.  In my image, I think it makes more sense for the cursor to be a double-headed arrow than to be a "working on something" cursor.  I'm sure that t-bird/shredder is waiting on the server for something (you may need a horribly overloaded exchange IMAP server to reproduce this for more than a fraction of a second), but whatever it's doing, it doesn't prevent you from resizing the window (if you can find where to click and drag - this is probably why I never noticed a problem until the border went down to one pixel).  The purpose of that "waiting" cursor is nice for discouraging me from clicking on other messages too fast, but it should not be discouraging me from resizing the window or other actions that don't initiate server operations.

Hopefully that made my situation clear and I'll let others decide what, if anything, they want to do to address this use case.
So you are more complaining about showing the spinning pointer instead of the double-headed arrow? Without spinning pointer, is it hard to hit the separator?

The separator is 3px high (the area to grab the separator) but only showing a 1px line.
Ok, that makes sense. The old splitter was 5px in size, thus effectively the active area is 40% less now (but still better than the 1px it appears to be).

> (In reply to comment #4) ... showing the spinning pointer instead of the
> double-headed arrow? Without spinning pointer, is it hard to hit the separator?

I'm wondering why it's spinning to start with, synchronization or indexing? Downloading of the message alone doesn't show the spinning cursor for me...

Jack, can you have a look at Tools > Activity Manager if there is any indication what may be going on in the background?
Activity Manager shows nothing for most of the delay, then some quick bursts of normal-looking activity which are cleared faster than I can read them.  I don't think that's something we should worry about, it's just a horrifically slow server, and it's a known problem that is out of my hands.  Even just to check for new messages, on this server, I'm getting a spinning cursor while waiting for it to show that I *don't* have any new messages.  I have another account in the same profile which doesn't do it so much.

I'll let you make your own decisions as to what you want to do, since it never comes down to one person's opinion anyway, but let me just say that I find a 3 pixel target just a little hard to deal with.  Trying to identify the target with an unchanging spinning cursor is just a little hard to deal with.  Trying to hit a 3 pixel target with an unchanging spinning cursor is very frustrating.  Fix one, fix both, I'll be grateful for whatever I get.
Attached patch bigger grip area (obsolete) — Splinter Review
This adds a bigger grip area.
Attachment #497254 - Flags: ui-review?(clarkbw)
Attachment #497254 - Flags: review?(bwinton)
Comment on attachment 497254 [details] [diff] [review]
bigger grip area

Hmmm, this looks like the wrong selector... wouldn't you be changing height and not width for this?  I might be confused at the issue here.
I'd think that both horizontal #threadpane-splitter, #attachment-splitter and #folderpane_splitter, #threadpane-splitter:not([orient="vertical"]) splitters should be extended in their active grip area from 3px to 5px.
Attached patch Bigger grip area (obsolete) — Splinter Review
Bigger grip area for threadpane and folderpane. Also corrected a bug, where the collapsed folderpane_splitter isn't available to open again.
Attachment #497254 - Attachment is obsolete: true
Attachment #497916 - Flags: ui-review?(clarkbw)
Attachment #497916 - Flags: review?(bwinton)
Attachment #497254 - Flags: ui-review?(clarkbw)
Attachment #497254 - Flags: review?(bwinton)
In Bug 609245 I've added for collapsed splitters when hovered a highlight color for better visibility. When this is also desired here, I can add this too.
Blocks: 619579
Comment on attachment 497916 [details] [diff] [review]
Bigger grip area

agreed w/ comment 9
Attachment #497916 - Flags: ui-review?(clarkbw) → ui-review+
I gave now a "glow" effect when the collapsed splitters are hovered like in Bug 609245.
I ask again for ui-r because of the new effect and the invivible #threadpane-splitter when collapsed (but visible when hovering).
Attachment #497916 - Attachment is obsolete: true
Attachment #498780 - Flags: ui-review?(clarkbw)
Attachment #498780 - Flags: review?(bwinton)
Attachment #497916 - Flags: review?(bwinton)
Comment on attachment 498780 [details] [diff] [review]
Patch with "glowing" splitters when collapsed and hovered

(In reply to comment #13)
> Created attachment 498780 [details] [diff] [review]
> Patch with "glowing" splitters when collapsed and hovered
> 
> I gave now a "glow" effect when the collapsed splitters are hovered like in Bug
> 609245.
> I ask again for ui-r because of the new effect and the invivible
> #threadpane-splitter when collapsed (but visible when hovering).

Cool.  How is the bump from 1px to 2px on hover?

Have you tried adding a transition? e.g.

  -moz-transition-property: border-color, border-width;
  -moz-transition-duration: 2s, 2s;

I'm wondering if we could smooth it out and perhaps even go from 1 to 4.
The hovered splitters are now 4px and with transition. I had to change from -moz-border-start to border-left and add a :-moz-locale-dir rule because with -moz-border-start the transition doesn't work :(
Attachment #498780 - Attachment is obsolete: true
Attachment #499117 - Flags: ui-review?(clarkbw)
Attachment #499117 - Flags: review?(bwinton)
Attachment #498780 - Flags: ui-review?(clarkbw)
Attachment #498780 - Flags: review?(bwinton)
Comment on attachment 499117 [details] [diff] [review]
transition on splitters when hovered

I'm going to try getting my windows build up and running to see this working otherwise I'll just defer to what blake says.
Attachment #499117 - Flags: ui-review?(clarkbw) → ui-review+
Comment on attachment 499117 [details] [diff] [review]
transition on splitters when hovered

>+++ b/mail/themes/qute/mail/mailWindow1-aero.css
>@@ -3,34 +3,57 @@
>+#folderpane_splitter:-moz-locale-dir(rtl),
>+#threadpane-splitter:not([orient="vertical"]):-moz-locale-dir(rtl) {
>+  border-right: 1px solid #A9B7C9;
>+}

So, I think we should add a comment above this block, referring to bug 621351 and mentioning that we can switch this back when that gets fixed.

And it was kind of hard to see that there was something at the bottom if I collapsed the preview pane.  What do you think about making that splitter always visible?

Other than those two small things, I think I like it.

Thanks,
Blake.
Attachment #499117 - Flags: review?(bwinton) → review+
(In reply to comment #17)
> Comment on attachment 499117 [details] [diff] [review]
> transition on splitters when hovered
> 
> And it was kind of hard to see that there was something at the bottom if I
> collapsed the preview pane.  What do you think about making that splitter
> always visible?

I'll give this question to UI

clarkbw: what do you think about this? Should the collapsed splitter be visible? Then we have the 1px bottom border in -moz-use-text-color of the messagepanebox plus 1px splitter with the color #A9B7C9. Or would you something different?
(In reply to comment #18)
> clarkbw: what do you think about this? Should the collapsed splitter be
> visible? Then we have the 1px bottom border in -moz-use-text-color of the
> messagepanebox plus 1px splitter with the color #A9B7C9. Or would you something
> different?

Yes what you have sounds like a good plan, lets go for it.
Added comment for Bug 621351 and collapsed threadpane- and attachment-splitter are now with 1px visible.
Assignee: nobody → richard.marti
Attachment #499117 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Keywords: checkin-needed
Checked in: http://hg.mozilla.org/comm-central/rev/64c3e87f6e07
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: