Closed
Bug 153572
Opened 23 years ago
Closed 18 years ago
Form widgets redrawn improperly at bottom during slow scrolling
Categories
(Camino Graveyard :: Page Layout, defect)
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
Comment 1•23 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•23 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•23 years ago
|
||
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•23 years ago
|
||
odd, I still don't see this
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
Comment 5•23 years ago
|
||
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•23 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•22 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•22 years ago
|
||
*** Bug 209647 has been marked as a duplicate of this bug. ***
Comment 9•19 years ago
|
||
Chris, perhaps you'd like to look at this?
Comment 10•19 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•19 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•19 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.
Comment 14•19 years ago
|
||
Yes, I don't see it while scrolling either, only just after slow scrolling.
Comment 15•19 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?
Updated•19 years ago
|
Severity: trivial → minor
QA Contact: winnie → page.layout
Comment 17•19 years ago
|
||
Comment 18•18 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•18 years ago
|
||
Comment 15 was fixed by bug 370659, so duping.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•