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
Product: Core
Classification: Components
Component: Widget: Cocoa (show other bugs)
: Trunk
: All All
-- normal with 1 vote (vote)
: mozilla6
Assigned To: Mounir Lamouri (:mounir)
: Markus Stange [:mstange]
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:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

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 User image 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 User image 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 User image 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 User image 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 User image Mounir Lamouri (:mounir) 2011-02-28 06:38:21 PST
Created attachment 515604 [details] [diff] [review]
Patch v1.2


The HTML progress element is now using doubles which is fixing the rounding issue. Markus, do you still want Roc's review?
Comment 5 User image Mounir Lamouri (:mounir) 2011-05-09 05:40:44 PDT
Comment 6 User image Shawn Wilsher :sdwilsh 2011-05-09 16:11:51 PDT
Backed out in to resolve bug 655860.
Comment 7 User image Mounir Lamouri (:mounir) 2011-05-10 06:59:27 PDT
The regression wasn't caused by these patches. Re-landed:

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