WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
36206
Fix the rendering of HTMLProgressElement
https://bugs.webkit.org/show_bug.cgi?id=36206
Summary
Fix the rendering of HTMLProgressElement
Yael
Reported
2010-03-16 19:34:28 PDT
I received today this link from Ian Hickson, which details the expected style for HTMLProgressElement.
http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-progress-element-0
.
Attachments
Patch v1.
(18.01 KB, patch)
2010-03-17 12:33 PDT
,
Yael
no flags
Details
Formatted Diff
Diff
Patch v2.
(12.30 KB, patch)
2010-03-17 14:28 PDT
,
Yael
no flags
Details
Formatted Diff
Diff
Patch v3
(13.05 KB, patch)
2010-03-26 07:10 PDT
,
Yael
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Yael
Comment 1
2010-03-17 12:33:46 PDT
Created
attachment 50932
[details]
Patch v1. Update the style information to conform to
http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-progress-element-0
. Originally, I did copied the style of <input type="range">, not knowing that the style was actually specified. Since this patch is blocked by
https://bugs.webkit.org/show_bug.cgi?id=36113
, and I am not sure how to handle this situation, I included the code that is up for review in
https://bugs.webkit.org/show_bug.cgi?id=36113
in this patch.
Yael
Comment 2
2010-03-17 14:28:59 PDT
Created
attachment 50959
[details]
Patch v2. Update the patch after
https://bugs.webkit.org/show_bug.cgi?id=36113
was resolved.
Yael
Comment 3
2010-03-22 09:51:14 PDT
This style adjustment will be merged to
https://bugs.webkit.org/show_bug.cgi?id=36224
.
Yael
Comment 4
2010-03-26 05:34:58 PDT
Splitting up the patch from
https://bugs.webkit.org/show_bug.cgi?id=36224
again.
Yael
Comment 5
2010-03-26 07:10:20 PDT
Created
attachment 51738
[details]
Patch v3 Previously, I thought that <progress> element should be simillar to the slider of <input type="range">, so I used code from RenderSlider, (baselinePosition and calcPrefWidths).
http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-progress-element-0
specifies the rendering rules for <progress> element, so this patch fixes that mistake. This patch also removes code in RenderProgress::updateFromElement() that tries to optimize the size of the rect to be repainted. The optimization will be redone later.
Antti Koivisto
Comment 6
2010-03-26 07:44:53 PDT
Comment on
attachment 51738
[details]
Patch v3 r=me, but consider changing these:
> Index: WebCore/platform/qt/RenderThemeQt.cpp > =================================================================== > --- WebCore/platform/qt/RenderThemeQt.cpp (revision 56617) > +++ WebCore/platform/qt/RenderThemeQt.cpp (working copy) > @@ -679,7 +679,7 @@ bool RenderThemeQt::paintProgressBar(Ren > option.rect = r; > option.maximum = 65536; > option.minimum = 0; > - option.progress = renderProgress->position(); > + option.progress = (renderProgress->position() * 65536);
Where does the magic 65536 come from? Please use std::numeric_limits<int>::max() or similar.
> @@ -97,21 +57,12 @@ void RenderProgress::layout() > void RenderProgress::updateFromElement() > { > HTMLProgressElement* element = static_cast<HTMLProgressElement*>(node()); > - double position = element->position(); > - int oldPosition = m_position; > - bool canOptimize = theme()->getNumberOfPixelsForProgressPosition(position, m_position); > + double oldPosition = m_position; > + m_position = element->position(); > if (oldPosition == m_position) > return;
Could you just do if (m_position == element->position()). oldPosition does not seem to be used anywhere else. yea
Yael
Comment 7
2010-03-26 08:43:21 PDT
Landed in 56629
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug