23985 - stopping quickly can result in unpainted scrollbars

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Claudius Gayle]

Overview Description:

  It is possible to stop the browser qickly enough such that the scrollbars begin
to paint but not completely so. The scroll arrows and the little hash marks on the
scroll thumb don't always show up.

Steps to Reproduce:

1) Load any page that take more than a split second to reload.

2) Click reoad.

3) Immediately click stop.



Actual Results:

	The page begins to reload in blazing fashion but when stopped all of
the chrome is not there. The little images that make the complete scrollbars
aren't all there.

Expected Results:

	You shouldn't be able to catch the scrollbars mid-stream like that. The
functionality is still there but it doesn't look good.

Build Date & Platform info:

	This bug is XP and was reproduced on Mac & Linux builds from 20000113.

Additional Information:

	I understand the chrome as content idea in the Brave New XUL World, but
we should really be able to avoid glitche slike this and make it appear seamless.

Comment 1

[Claudius Gayle]

Attachment: screenshot of the problem on a mac

Comment 2

[Eric Vaughan]

targeting

Comment 3

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 4

[Paul MacQuiddy]

spam, open xptoolkit qa contact moving over to jrgm

Comment 5

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 6

[John Morrison]

can't reproduce this on mac/linux/win32 for 20000626nn builds. Marking WFM.
(But claudius knows what to do if ...)

Comment 7

[John Morrison]

verified (and throws down the gauntlet to CMax).