[Webkit-unassigned] [Bug 37308] [Chromium] Support HTML5 <progress> element on Windows.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37308





--- Comment #16 from TAMURA, Kent <tkent at chromium.org>  2010-04-22 04:58:03 PST ---
(In reply to comment #11)
> > > +    if (o->position() < 0)
> > 
> > I couldn't understand why this is necessary. If this is necessary, don't we
> > need to modfify RenderThemeMac as well?
> Progress bars on windows bar has an animation only when it is indeterminate.
> Progress bars on mac has animations both for determinate and for indeterminate. 
> So we need this only for Windows port.

I remember determinate progress bar on Windows is also animated. A white gloss
run from left to right.  Can you implement it?

(In reply to comment #15)
> > > +    virtual void paintProgressBar(
> > > +        WebCanvas*, int barPart, int barState, const WebRect& barRect, 
> > > +        int fillPart, int fillState, const WebRect& fillRect) {} // FIXME: make pure virtual after implementation landed.
> > >  };
> > 
> > ^^^ we should actually make any embedder implemented methods non-pure.
> > the old way was for them to be pure, but that makes it harder to change
> > the API.  the new way is to make methods like these non-pure.
> I see. So I removed the FIXME.
> We might need to export notImplemented() for such case.

Removing FIXME is worse.
In this case, you had better commit the Chromium part first, then commit this
change.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.