Created attachment 448005 [details]
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.
Created attachment 448007 [details]
Updating the test case, the overflow was misplaced.
And I confirm this bug appears on Windows XP too.
Created attachment 448008 [details]
Screenshot on Windows 7
Created attachment 519137 [details] [diff] [review]
Created attachment 519433 [details] [diff] [review]
This is fixing a warning (11.f should be 11).
is 11 defined somewhere? Can we get this value dynamically?
widgetRect.bottom -= 11;
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.
Created attachment 519971 [details] [diff] [review]
With a static const.
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 on attachment 519971 [details] [diff] [review]
Review of attachment 519971 [details] [diff] [review]:
Hard coded values sucks, but I suppose it will flesh itself out over time.
Backed out in http://hg.mozilla.org/mozilla-central/rev/dd9ba28d2bd9 to resolve bug 655860.
The regression wasn't caused by these patches. Re-landed:
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.