Form widgets redrawn improperly at bottom during slow scrolling

RESOLVED DUPLICATE of bug 370659

Status

Camino Graveyard
Page Layout
--
minor
RESOLVED DUPLICATE of bug 370659
16 years ago
11 years ago

People

(Reporter: Stephane Moureau, Unassigned)

Tracking

unspecified
Future
PowerPC
Mac OS X

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
If you hold down the vertical scroll thumb and drag slowly the bug report page
in order to show and hide the half bottom of the form buttons 'Commit' and
'Remember etc' with the status line at the bottom of the window, they are not
always correctly/entierely drawed.
It happens only with the thumb, not with page/line up/down.
I can't find a pattern.
Build 20020621 16:08

Comment 1

16 years ago
Hmmm, seems to work fine in my nightly build. Any more information about your
machine or if your see this after browsing for a while, in tabs, etc?
Status: NEW → ASSIGNED
(Reporter)

Comment 2

16 years ago
It's very easy to reproduce, even after a new launch.
There is a general update/redraw problem I think linked to scroll, see my latest bug report 
for CSS from 06/22 (html div)
http://bugzilla.mozilla.org/show_bug.cgi?id=153283

Comment 3

16 years ago
Created attachment 88823 [details]
Screenshot

What I see is that if you scoll up and down over a button it sometimes gets its
dropshadow cut off. Attached a screenshot. Chimera/20020622

Comment 4

16 years ago
odd, I still don't see this
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
yeah, i see this. no big deal. the problem is that the dropshadow is outside of
the button's rectangle, so we don't get the update correctly. i had similar
issues when trying to clip to the button rectangle. we'd end up clipping out a
bunch of the drop shadown. yay apple.

trivial though.
Severity: normal → trivial
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 6

16 years ago
Fixed typo in summary (from->form)
Summary: From buttons partly redrawn during slow scrolling → Form buttons partly redrawn during slow scrolling

Comment 7

15 years ago
I think i've seen this more often recently... but that might mean nothing.
Theres also been at least one other (recent) report of this and i'm off to hunt
it down and mark it a dupe.

Comment 8

15 years ago
*** Bug 209647 has been marked as a duplicate of this bug. ***
Chris, perhaps you'd like to look at this?

Comment 10

13 years ago
This happens a lot with form select widgets (aka menus) of size=0 or 1, too. I can reproduce it much more easily with those than with a button.

Having the browser.display.focus_ring_width set to default (1) makes this worse; setting it to 0, as I have it, makes it almost go away for the buttons (but not selects). This makes me wonder if a fix for bug 327373 might fix this.

cl
Summary: Form buttons partly redrawn during slow scrolling → Form widgets partly redrawn during slow scrolling

Comment 11

13 years ago
More info: setting the focus ring width to 2 or higher seems to prevent this on buttons, but not on selects. One more summary tweak, too -- this only ever happens on the bottom edge of the widgets, as far as I can tell.

cl
Summary: Form widgets partly redrawn during slow scrolling → Form widgets redrawn at bottom during slow scrolling

Comment 12

13 years ago
Whoops. Missed a word in there.
Summary: Form widgets redrawn at bottom during slow scrolling → Form widgets redrawn improperly at bottom during slow scrolling
I see this from time-to-time, but never *while* scrolling.  The "Commit" button in Bugzilla displays it a lot, which makes me think bug 310266 might be involved (see bug 310266 comment 12).  I also see it with drop-down selects, as Chris notes.
Yes, I don't see it while scrolling either, only just after slow scrolling.

Comment 15

13 years ago
This is because our native buttons (and their focus rings) can draw outside the nsFrame.
I meant to say "I also see this when there is/has been no scrolling at all, like on a page that fits completely within the viewport" (but on buttons or selects that otherwise and other times display completely and properly.)

I assume the fix for comment 15 involves further educating the layout functions about our native widgets?
Severity: trivial → minor
QA Contact: winnie → page.layout
Created attachment 216075 [details]
Updated screenshot (shows problem on select widgets).

Comment 18

12 years ago
I bet Cairo fixes this, in exchange for all the other fun widget bugs. I also highly doubt pink is actively working on this, so assigning back to default.
Assignee: mikepinkerton → nobody
Status: ASSIGNED → NEW

Comment 19

11 years ago
Comment 15 was fixed by bug 370659, so duping.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 370659

Updated

11 years ago
Duplicate of this bug: 209649
You need to log in before you can comment on or make changes to this bug.