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

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;

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.

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

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

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.

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

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

Mass moving M19 bugs to M20

Mass-moving all M20-M30 XPToolkit bugs to Future

--> Themes

Mass reassigning some of my theme bugs to Shuehan.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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