* TITLE/SUMMARY [PP] Lots'o'Scroll Bar Problems still in Mac Viewer (Pierre, I've combined these all together into one bug for your convenience, rather than bombard you with a ton of minor bugs, since I believe you mentioned preferring that approach. If I'm mistaken, please let me know if you'd prefer having this broken out into several bugs, and I'd be happy to do so.) * GENERAL FOO There are a lot of behavioral problems with the current scroll bar/resize box widget set on the current Mac builds, and which do not take place on the Win32 builds. (Simon Fraser pointed a bunch of these out.) Here are some: #1: The resize box in the lower-right hand corner does not appear upon creating a new Viewer window, but only after the viewer window is resized. #2: The horizontal and vertical scroll bars do not precisely track with the window borders while the windows are expanded or shrunken in size; frequently, while expanding a window, a 5-10 pixel white space gap will appear. While shrinking a window, portions of (or even the entire scroll bar) can disappear. #3: While expanding the content window, fragments of the scroll bar will be left in the content region. (I can't reproduce this --- perhaps it's been fixed in the 1.13.99 build --- but I'll keep my eye open for it.) * REGRESSION - Occurs On viewer (1.13.99 build for Mac OS) - Doesn't Occur On viewer (1.12.99 build for Win32) viewer (1.13.99 build for Linux --- build is broken) * CONFIGURATIONS TESTED - PowerMac 8500/120 (233 Mhz 604e), 64 MB RAM, 1024x768 (16-bit video), Mac OS 8.5.1

#4: Click on the upwards-pointing scroll arrow a single time. Wait a second. Now move the mouse pointer across the vertical scroll bar. ---> Each time you pass through the scroll bar, the scroll arrow you clicked will blink. (Same happens with downward-pointing scroll arrow, if you click on the downward-pointing scroll arrow, instead.)

Removed "[PP]" from summary line: these problems are relatively minor. Reassigned to mcmullen. John: if you don't have the time to look at this before the PP shebang is called off, please reassign to me.

Individually, they're relatively minor, but in the aggregate, they look extremely ugly, and IMHO make the Viewer app look a bit like a cobbled-together hack. Speaking of which... #5: After resizing the content region, there's a one-pixel horizontal white region between the downward-pointing scroll arrow and the resize box. Furthermore, the scroll region extends a pixel (or two?) to the left of the resize box.

Also, www.ebay.com is a great site to reproduce the scroll bar gunk left onto the top-of-page image map during scrolling. (item #3) Also, per chofmann's clarified definition of a platform parity bug (14 Jan 1999 to seamonkey-eng), I'm re-marking this as a Platform Parity bug, since it meets the description as I understand it.

Ok... Reduced priority and changed summary line to better reflect the importance of this bug compared to the other ones we have to fix.

WORKSFORME.

Simon would like to try one or more of these items.

I checked in some changes to improve scroll bar positioning, but problems 1-3 in this bug remain.

Problem 3 can no longer be reproduced, Eli said when opening the bug. Also the fix for 2258 "Messed up drawing after scrolling" may help to definitely fix that one too. A question about #2, Eli: can you see that empty space only when continuously moving the mouse while resizing the window, or also when keeping the mouse still during a resize? Can you also see it after releasing the mouse button?

Hey, Pierre --- The white space (and other alignment problems) now self-correct within about 1/2 second on the 1.19.98 build (even when the mouse button is still held down.) Simon & Pierre, I'm happy to mark this one verified/fixed, should you wish. You've addressed all the gross items (and the live resizing problem takes place slightly on Win32, anyway, during shrinking). The only platform-specific item remaining is #4, and it's such a minor cosmetic bug that I don't think it's worth holding the bug open for, let alone even worth tracking on its own (for a Gecko test application.) Thanks!

I'm not closing it: just reassigning it to me without the [PP] tag. I'd like to have a look at that problem #4. You can also reproduce it that way: - click the window title bar, somewhere above the Back & Forward buttons - move the window - as soon as you release the mouse button, move the mouse cursor above one of the 2 buttons (it has to be done quickly) ==> like the scrollbar, the button is in a state where it hilites even without clicking. Interesting isn't it?

[#4 also occurs with scroll bars within a document; i.e. the scrollbars that are appearing in the Slashdot banner ad.]

Setting all current Open/Normal to M4.

Fixed #4 as well as problem described on 01/19/99 14:44

Verified that problem #4 is now also fixed in the 3.9.99 builds of Mac OS Viewer & Apprunner. (Can't reproduce the other problem that Pierre found in that build; assuming fixed since Pierre classifies it as fixed.)