16651 - [PAINTING] personal toolbar causes excessive repaints when narrow

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P4)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

DESCRIPTION:  When the browser window is narrow enough that the entire top line
of chrome (with the M icon) doesn't fit in the window, hovering over icons in
the personal toolbar causes excessive repaints.  (Note:  my personal toolbar is
overfull when the window is wider than this critical point, so the bug may
require the personal toolbar to be full as well.)

STEPS TO REPRODUCE:
 * Load apprunner and enable paint flashing
 * make the window narrow enough so the M isn't completely visible (this should
be the default width, for some annoying reason...)
 * turn caps-lock on
 * hover over a button in the personal toolbar

ACTUAL RESULTS:
 * each hover/de-hover of a button causes 3 flashes:
    + the URL bar
    + the content frame
    + the entire window

EXPECTED RESULTS:
 * only the button is repainted

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-17, build from around 20:30 PDT.

ADDITIONAL INFORMATION:
 * This also happens on submenus within the personal toolbar if my patch to
   bug 15558 is applied (the patch creates border-based hover effects on
   said submenus).  Or at least it also happened in a tree from last week - I
   doubt it's changed since the main bug hasn't changed.

Comment 1

[Sean Richardson]

This sounds like a classic linux-repaints-too-much type of bug,
but since you said the magick word NUMLOCK, see also Bug 16620.

Can't Reproduce on 1999-10-17-08-M11 on Windows NT 4.0sp3

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I didn't say NUMLOCK.  I said CAPSLOCK, which is used in *debug* builds to
enable paint flashing when the option is checked - see the Debug pane of
preferences.  If you weren't using paint flashing, you might not be able to tell
whether this is happening.

Comment 3

[Sean Richardson]

Sorry, my bad. http://mozilla.org/binaries.html does not say if the nightly
binaries have debugging turned on, but after turning on Flashing in Edit>
Preferences>Debug, I'm seeing some, so retesting. Still does not reproduce
on 1999-10-17-08-M11 on Windows NT 4.0sp3.

Comment 4

[Peter Trudelle]

I'm seeing all of the chrome repaint on Win98 too.

Comment 5

[Peter Trudelle]

reassigning to pavlov

Comment 6

[Ramiro Estrugo]

This is an XP bug.  Ive seen this on windows as well.  Marking all.

Comment 7

[Paul MacQuiddy]

spam: changing qa contact from ckritzer -> paulmac for xul bugs

Comment 8

[Peter Trudelle]

targetting p4 for m16

Comment 9

[leger]

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.

Comment 10

[Paul MacQuiddy]

*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to
[e-mail]

Comment 11

[Paul MacQuiddy]

*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
[e-mail]

Comment 12

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 13

[Peter Trudelle]

moving to m18

Comment 14

[John Morrison]

really moving to M18 this time.

Comment 15

[Peter Trudelle]

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

Comment 16

[Stuart Parmenter]

this looks ok here... pink said it looked ok for him as did bryner