Closed
Bug 568825
Opened 14 years ago
Closed 13 years ago
moz-appearance: progresschunk overflows on the bottom
Categories
(Core :: Widget: Win32, defect)
Core
Widget: Win32
Tracking
()
VERIFIED
FIXED
mozilla6
People
(Reporter: mounir, Assigned: mounir)
References
Details
Attachments
(3 files, 3 obsolete files)
It looks like moz-appearance: progresschunk overflows on the bottom. It seems the overflow is a constant value of pixels I didn't check more than that but it's not a percentage. This is working correctly with the GTK widget.
Assignee | ||
Comment 1•14 years ago
|
||
Updating the test case, the overflow was misplaced. And I confirm this bug appears on Windows XP too.
Attachment #448005 -
Attachment is obsolete: true
Assignee | ||
Comment 2•14 years ago
|
||
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #519137 -
Flags: review?(doug.turner)
Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•13 years ago
|
Whiteboard: [needs review]
Assignee | ||
Comment 4•13 years ago
|
||
This is fixing a warning (11.f should be 11).
Attachment #519137 -
Attachment is obsolete: true
Attachment #519433 -
Flags: review?(doug.turner)
Attachment #519137 -
Flags: review?(doug.turner)
Comment 5•13 years ago
|
||
is 11 defined somewhere? Can we get this value dynamically? widgetRect.bottom -= 11;
Assignee | ||
Comment 6•13 years ago
|
||
No, 11 is defined nowhere. I found that by trying multiple values and reftesting with an element with overflow: hidden. The overflow is constant and doesn't seem to be dynamic. The "small" version of the reftest is here to prove that. I wonder if the overflow comes from a bug somewhere else but the way we draw progress bars seems quite simple and I don't understand what would create it.
Assignee | ||
Updated•13 years ago
|
Attachment #519433 -
Flags: review?(doug.turner) → review?(jmathies)
Assignee | ||
Comment 7•13 years ago
|
||
With a static const.
Attachment #519433 -
Attachment is obsolete: true
Attachment #519971 -
Flags: review?(jmathies)
Attachment #519433 -
Flags: review?(jmathies)
Assignee | ||
Comment 8•13 years ago
|
||
Hmmm, so my patch is working as a workaround but obviously the issue is somewhere else... If you open: data:text/html,<progress tabindex=1 value=1></progress> and click on (or tab on) the progress element, you will see the outline taking more than the progress' size. But I still have no idea where this comes from given that Windows is the only widget with that issue.
Comment 9•13 years ago
|
||
Comment on attachment 519971 [details] [diff] [review] Patch v1.2 Review of attachment 519971 [details] [diff] [review]: Hard coded values sucks, but I suppose it will flesh itself out over time.
Attachment #519971 -
Flags: review?(jmathies) → review+
Updated•13 years ago
|
Whiteboard: [needs review]
Assignee | ||
Updated•13 years ago
|
Whiteboard: [ready to land][waits for dependencies]
Assignee | ||
Comment 10•13 years ago
|
||
Pushed: http://hg.mozilla.org/mozilla-central/rev/65a4097a0d95
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [ready to land][waits for dependencies]
Target Milestone: --- → mozilla6
Comment 11•13 years ago
|
||
Backed out in http://hg.mozilla.org/mozilla-central/rev/dd9ba28d2bd9 to resolve bug 655860.
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 12•13 years ago
|
||
The regression wasn't caused by these patches. Re-landed: http://hg.mozilla.org/mozilla-central/rev/50a3b89cce71
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Flags: in-testsuite+
Comment 13•13 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0 Verified issue using attached Testcase on Win7 and WinXP. Everything is in order -> setting status to Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•