Last Comment Bug 634549 - Cocoa's progress bar widget should use HTML progress element's values
: Cocoa's progress bar widget should use HTML progress element's values
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla6
Assigned To: Mounir Lamouri (:mounir)
:
:
Mentors:
Depends on: 514437
Blocks: 633207 634551
  Show dependency treegraph
 
Reported: 2011-02-16 02:16 PST by Mounir Lamouri (:mounir)
Modified: 2011-05-10 07:10 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (4.63 KB, patch)
2011-02-16 02:16 PST, Mounir Lamouri (:mounir)
no flags Details | Diff | Splinter Review
Patch v1.1 (6.17 KB, patch)
2011-02-16 06:51 PST, Mounir Lamouri (:mounir)
mstange: review+
Details | Diff | Splinter Review
Patch v1.2 (6.07 KB, patch)
2011-02-28 06:38 PST, Mounir Lamouri (:mounir)
roc: review+
Details | Diff | Splinter Review

Description Mounir Lamouri (:mounir) 2011-02-16 02:16:20 PST
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.
Comment 1 Markus Stange [:mstange] 2011-02-16 02:31:23 PST
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.
Comment 2 Mounir Lamouri (:mounir) 2011-02-16 06:51:15 PST
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 3 Markus Stange [:mstange] 2011-02-16 07:11:27 PST
Comment on attachment 512790 [details] [diff] [review]
Patch v1.1

Oh no :(

Maybe roc has a better idea how to make this presentable.
Comment 4 Mounir Lamouri (:mounir) 2011-02-28 06:38:21 PST
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?
Comment 5 Mounir Lamouri (:mounir) 2011-05-09 05:40:44 PDT
Pushed:
http://hg.mozilla.org/mozilla-central/rev/94dc6447f102
Comment 6 Shawn Wilsher :sdwilsh 2011-05-09 16:11:51 PDT
Backed out in http://hg.mozilla.org/mozilla-central/rev/dd9ba28d2bd9 to resolve bug 655860.
Comment 7 Mounir Lamouri (:mounir) 2011-05-10 06:59:27 PDT
The regression wasn't caused by these patches. Re-landed:
http://hg.mozilla.org/mozilla-central/rev/5b69bdf44737

Note You need to log in before you can comment on or make changes to this bug.