35442 - mailnews' Sidebar tab headers draw on taskbar

Status: VERIFIED WORKSFORME

(SeaMonkey :: Sidebar, defect, P3)

Description

[R.K.Aa.]

Build ID 2000041008 linux
Will try to attach a jpg showing this:
-scrollbar widget on sidebar differs from main mailnews scrollbar.
-sidebars bottom scrollbar arrow "stays on top" when sliding sidebar down,
causing it to overpaint the statusfield on it's way down.
-curbed sides of "folder-tab" pix in sidebar "stay on top", unlike the middle
region.
In addition: When opening mailnews with mysidebar in a "Lowered" state (not
showing tabs at all) the blue field labeled "My Sidebar" has to be first dragged
downwards and THEN upwards, to slide up and reveal the content. Only dragging
upwards have no effect at all.

Comment 1

[R.K.Aa.]

Attachment: painting oddities

Comment 2

[Paul MacQuiddy]

dark, it sounds like multiple problems here, can you open just one bug per 
problem? thanks

Comment 3

[Paul MacQuiddy]

marking invalid since there are multiple problems reported

Comment 4

[R.K.Aa.]

I mentioned an "In addition" because it can be related. The lack of mousefocus
for the heading can be related to the header being in the wrong layer initially,
till a "drag-down" is detected. But the subject of the bug is the real issue.

Should i file one bug for layerproblems with left-side tab pic, one for
rigth-side tab pic, and one for the bottom scrollbar arrow?

This seems to me to be very much one and the same error - the misbehaviour is
consistant, it seems to originate in the same code, they are all layer-related
for these widgets, and the widgets are now surfacing - together - in the same
erronous layer: In front of statusbar instead of behind.

Comment 5

[Paul MacQuiddy]

okay, thanks, I should have read more carefully

Comment 6

[Paul MacQuiddy]

marking as new, qa to shrir for now

Comment 7

[R.K.Aa.]

well i am a lousy bugreporter. I should stop it. In my last clarification is an
error: It is the TOP scrollbar-arrow area that is in wrong layer and draws on
top of statusbar. The attachment shows that too.

Comment 8

[Matthew T (active 1999-2002)]

Reproduced on 2000050808 build, Mac OS 8.6; --> All/All.

Sometimes bits of the tabs themselves get deposited on the taskbar, depending on 
the speed of dragging; I won't be able to tell if that's the same bug until this 
one gets fixed.

Comment 9

[Matthew T (active 1999-2002)]

*** Bug 37785 has been marked as a duplicate of this bug. ***

Comment 10

[Steve Lamm]

I see the clipping problem. I added some min-height rules to sidebarOverlay.css 
that help alleviate the problem, but I do still see it.

Passing to evaughan for some help.

Comment 11

[Eric Vaughan]

Light weight frames can't clip heavy weight widgets. But the work to fix stack 
z-order and to fix textfields in decks and tabs can fix this problem. Basically 
if a frame knows its children have widgets or views it creates a clip view or 
widget to clip them as needed.

Comment 12

[Eric Vaughan]

adding dependency

Comment 13

[John Morrison]

(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future'
milestone

Comment 14

[R.K.Aa.]

linux 2000082117: Only tiny anomalies remain of this one:

The blue "frame" area's bottom will be covered while the tab's pass it up/down.
The various elements (side of tabs, top of tabs and scrollbar) don't anymore
live in "independant" layers of eachother like when the bug was filed. So 90% of
it seems fixed.

Comment 15

[shrirang khanzode]

spam : changing qa to sujay (New Sidebar QA)

Comment 16

[R.K.Aa.]

Revisiting old bugs.. the last 10% of this one are gone as well now. WFM.

Comment 17

[sujay]

verified.

Comment 18

[sujay]

verified.