Closed Bug 153572 Opened 22 years ago Closed 17 years ago

Form widgets redrawn improperly at bottom during slow scrolling

Categories

(Camino Graveyard :: Page Layout, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 370659
Future

People

(Reporter: stf, Unassigned)

References

()

Details

Attachments

(2 files)

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
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
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
Attached image 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
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
Fixed typo in summary (from->form)
Summary: From buttons partly redrawn during slow scrolling → Form buttons partly redrawn during slow scrolling
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.
*** Bug 209647 has been marked as a duplicate of this bug. ***
Chris, perhaps you'd like to look at this?
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
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
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.
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
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 15 was fixed by bug 370659, so duping.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: