Closed Bug 16651 Opened 25 years ago Closed 24 years ago

[PAINTING] personal toolbar causes excessive repaints when narrow

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dbaron, Assigned: pavlov)

Details

(Keywords: perf) 

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.
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
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.
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.
I'm seeing all of the chrome repaint on Win98 too.
Assignee: trudelle → pavlov
reassigning to pavlov
Status: NEW → ASSIGNED
Summary: personal toolbar causes excessive repaints when narrow → [PAINTING] personal toolbar causes excessive repaints when narrow
OS: Linux → All
This is an XP bug.  Ive seen this on windows as well.  Marking all.
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Priority: P3 → P4
Target Milestone: M16
targetting p4 for m16
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to
jrgm@netscape.com
QA Contact: paulmac → jrgm
*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
jrgm@netscape.com

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
moving to m18
Keywords: perf
really moving to M18 this time.
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
this looks ok here... pink said it looked ok for him as did bryner
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.