18958 - Proper cursor for splitter is <-||-> not <-->

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[Sean Richardson]

Overview:
On Windows at least, the cursor used when hovering over vertical and horizontal
splitters in Mozilla to date does not match the cursor used by Communicator
and other MS-Win apps for the same purpose. This applies to Mail/News,
the Sidebar, and anywhere else in Mozilla a splitter appears - with any
luck a single change will fix them all. May be XP - dunno.
Trying XP Toolkit/Widgets first for an owner.

Steps to reproduce:
1. Watch the cursor carefully while manipulating any splitter in Mozilla
   (sidebar is easiest to find).
2. Watch the cursor carefully while manipulating any splitter in Communicator
   (at least two in Messenger).

Actual Result:
The cursor in Mozilla resembles this ascii art:   <----> (for vert splitter)
The cursor in Communicator resembles this ascii art:   <-||->

Expected result:
The cursor for the splitter in Mozilla should match that used in Communicator.
That cursor is very distinctive and, besides being what is expected,
is actually much more immediately meaningful than a simple double-headed arrow
in practice.

Tested with:
1999-11-15-12-M12 nightly build on Windows NT (same seen on Win95)
Communicator 4.7

Comment 1

[german]

Unfortunately <---> is what the cursor like that is supported in CSS for hor or
vert resizing. I'll check whether we can do the custom cursor support a la
cursor : url("firstchoice.cur"), url("secondchoice.csr"), e-resize;

Comment 2

[Sean Richardson]

Hmm. It surely would not be a disaster if the <-||-> cursor made no appearance,
but in my experience the conceptual distinction ( <-||-> resizes two regions
at once, <---> resizes one region ) is most useful to those with the least
experience with complex User Interfaces - and they understand it immediately.
The distinction is real and very visible, and if CSS treats both types of
resizing the same, the CSS spec could be improved in that area, IMO.

Comment 3

[Peter Trudelle]

assigning to evaughan and adding dependencies on Pav's XP cursor work.

Comment 4

[german]

Agree with sidr's assessment. Ideally we would support b/w GIFS with
transparency as cursors.

Comment 5

[Sean Richardson]

Implementation note: if this cursor is added, it will almost certainly need to
be enabled the same way as the remaining unsupported css2 cursors get enabled
in the FIX for bug 1916, "9 Values for the Cursor Property (CSS2) do not work",
ASSIGNED, M14.

Comment 6

[Eric Vaughan]

the cursor is set in CSS. When CSS supports this you will be able to set it.

Comment 7

[leger]

Setting the keyword all open [4.xp] bugs to 4xp.

Comment 8

[Peter Trudelle]

Mass moving M19 bugs to M20

Comment 9

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 10

[Blake Ross]

--> Themes

Comment 11

[Joe Hewitt (gone)]

Mass reassigning some of my theme bugs to Shuehan.

Comment 12

[Vidar Haarr (not reading bugmail)]

WFM on WinXP 2002062608 (trunk).

The cursor used to resize the sidebar and the cursor used to resize the
folderpane in Windows Explorer are identical.

Comment 13

[David G King]

I agree with comment #12, even though this goes against what is being requested.

Under Win98SE the cursor to move the vertical bar on the Mozilla Sidebar is the
exact same cursor as is used to move the vertical bar in Windows Explorer, that
is <--->.

IMHO, I'd prefer consistency with the Windows "look and feel" (Yes, OS is
Windows only), rather than being the same as Netscape 4.x. And, to add extra
fuel to this, IE uses <--->.

Comment 14

[Minh Nguyễn]

Windows Explorer uses the <-||-> cursor when hovering between column headers. So
the <-||-> cursor should be used while hovering between the column headers that
you'd see when you're at ftp://ftp.mozilla.org/ , for example. And the splitter
I see is actually closer to <-|-> than it is to <-||->.

Comment 15

[David G King]

Hmmm, interesting, I hadn't noticed that before. It appears that Windows
Explorer uses different cursors for different types of vertical splitters. And I
really don't think we need to start a discussion about what kind of vertical
splitter gets what kind of cursor.

So, if anything, Mozilla is easier to understand as it uses the same cursor for
all vertical splitters, no matter what type it is. And what's more, it makes it
fully compliant with CSS2 (well, that aspect of CSS2 anyway).

Comment 16

[Tim Powell]

The draft for CSS3 suggests and IE6 implements the col-resize and row-resize
cursors that look like 
             ^
             |
<-||-> and  ===
             |
             v

See bug 163174.

Comment 17

[Gérard Talbot]

I've filed bug 230081 and it was suggested this was a duplicate of this bug. Now
if this bug recommends to use col-resize and row-resize for frame and pane
resizing, then I'll leave bug 230081 as it is. If this bug supports col-resize
and row-resize for contextual table situations for resizing columns and rows,
then I think bug 163174 is already assigned to such situations. 

I think for frames and pane resizing, Mozilla should opt for (horizontal and
vertical) splitter/divider cursors which are specific to such contextual
situations. Right now, I have already built the .cur files for that (see
attachment 138400 [details]; let me know if you can't see the demo); I can still work on
these cursors more (shape, size, color, outline, etc..) if that's needed. 

I just wish we could merge these 2 bugfiles here by resummarizing this bug more
accordingly to something like
"Proper cursor for frame and pane resizing is <-|-> not <-->"
and then I'll be happy to "DUPLICATE" bug 230081. Comment #14 is correct when
saying that "the splitter I see is actually closer to <-|-> than it is to
<-||->". That's the case for a minority of Windows-based applications (like
Simply Web 2000).
My 2 cents

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420