Created attachment 512754 [details] [diff] [review] Patch v1 Cocoa's progress bar widget is the only widget that actually draw itself the bar so it needs the current value and the max value. For the moment, the code doing that is assuming that the element is a XUL progressmeter element. This patch makes it work with an HTML progress element. There is a [dirty] hack that consist of multiplying the float value we get because Cocoa's widget takes only integers for value and max.
How about this: Make GetProgressValue and GetProgressMaxValue return a float, and then in DrawProgress always set tdi.max to PR_INT32_MAX and do some calculations to get the correct value. Then we always use the best precision we can get and don't have to choose an arbitrary number.
Created attachment 512790 [details] [diff] [review] Patch v1.1 Should be better now even if I spent half an hour before understanding why PR_INT32_MAX*1 gives PR_INT32_MIN ;)
Comment on attachment 512790 [details] [diff] [review] Patch v1.1 Oh no :( Maybe roc has a better idea how to make this presentable.
Created attachment 515604 [details] [diff] [review] Patch v1.2 r=mstange The HTML progress element is now using doubles which is fixing the rounding issue. Markus, do you still want Roc's review?
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: http://hg.mozilla.org/mozilla-central/rev/5b69bdf44737