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

Status: RESOLVED FIXED

(Thunderbird :: Theme, defect)

Description

[Jack Eidsness]

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

Comment 1

[Jack Eidsness]

Attachment: Image of mouse cursor near or possibly on the pane separator

Comment 2

[rsx11m]

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.

Comment 3

[Jack Eidsness]

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.

Comment 4

[Richard Marti (:Paenglab)]

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.

Comment 5

[rsx11m]

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?

Comment 6

[Jack Eidsness]

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.

Comment 7

[Andreas Nilsson (:andreasn)]

Attachment: bigger grip area

This adds a bigger grip area.

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 9

[rsx11m]

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.

Comment 10

[Richard Marti (:Paenglab)]

Attachment: Bigger grip area

Bigger grip area for threadpane and folderpane. Also corrected a bug, where the collapsed folderpane_splitter isn't available to open again.

Comment 11

[Richard Marti (:Paenglab)]

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.

Comment 12

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 497916 [details] [diff] [review]
Bigger grip area

agreed w/ comment 9

Comment 13

[Richard Marti (:Paenglab)]

Attachment: 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).

Comment 14

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 15

[Richard Marti (:Paenglab)]

Attachment: transition on splitters when hovered

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 :(

Comment 16

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 17

[Blake Winton (:bwinton) (:☕️)]

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.

Comment 18

[Richard Marti (:Paenglab)]

(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?

Comment 19

[Bryan Clark (DevTools PM) [:clarkbw]]

(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.

Comment 20

[Richard Marti (:Paenglab)]

Attachment: Patch for check-in

Added comment for Bug 621351 and collapsed threadpane- and attachment-splitter are now with 1px visible.

Comment 21

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/64c3e87f6e07