Bug 53583 - Refactoring: <progress> should not use ShadowElement
Summary: Refactoring: <progress> should not use ShadowElement
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 48698 53417
  Show dependency treegraph
 
Reported: 2011-02-02 03:11 PST by Hajime Morrita
Modified: 2011-02-03 17:46 PST (History)
4 users (show)

See Also:


Attachments
Patch (13.49 KB, patch)
2011-02-02 03:36 PST, Hajime Morrita
no flags Details | Formatted Diff | Diff
Patch (13.61 KB, patch)
2011-02-02 20:22 PST, Hajime Morrita
no flags Details | Formatted Diff | Diff
Patch (21.78 KB, patch)
2011-02-02 21:59 PST, Hajime Morrita
dglazkov: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hajime Morrita 2011-02-02 03:11:57 PST
This is a part of ShadowElement removal refactoring.
Comment 1 Hajime Morrita 2011-02-02 03:36:40 PST
Created attachment 80908 [details]
Patch
Comment 2 Hajime Morrita 2011-02-02 03:37:58 PST
Hi Dimitri, could you take a look? 
This change kicks ShadowElement out from <progress>.
I'll do same for <meter> after this one.
Comment 3 WebKit Review Bot 2011-02-02 03:39:12 PST
Attachment 80908 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/update-webkit']" exit_code: 2

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.US-ASCII"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Updating OpenSource
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_US.US-ASCII"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
RA layer request failed: OPTIONS of 'http://svn.webkit.org/repository/webkit': could not connect to server (http://svn.webkit.org) at /usr/lib/git-core/git-svn line 2295

Died at Tools/Scripts/update-webkit line 132.


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Dimitri Glazkov (Google) 2011-02-02 09:21:26 PST
Comment on attachment 80908 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=80908&action=review

Can you explain a bit about the originalVisibility? I may have known but forgotten, and now confuses me. I am easily confused. Why do we need this?

> Source/WebCore/html/HTMLProgressElement.cpp:40
> +class ProgressBarValueElement : public HTMLDivElement {

This class should live in html/shadow/ProgressBarValuePartElement

> Source/WebCore/html/HTMLProgressElement.cpp:53
> +#if 0

You didn't mean to leave this in :)

> Source/WebCore/rendering/RenderIndicator.h:37
> +    virtual bool shouldHidden() = 0;

shouldBeHidden()?

> Source/WebCore/rendering/RenderProgress.cpp:102
> +    for (RenderObject* child = firstChild(); child; child = child->nextSibling())

Why is this here? Why can't we just use RenderProgress:layout()?
Comment 5 Hajime Morrita 2011-02-02 20:22:25 PST
Created attachment 81027 [details]
Patch
Comment 6 Hajime Morrita 2011-02-02 20:27:05 PST
Oops. Updated patch is not ready....
Comment 7 Hajime Morrita 2011-02-02 21:59:01 PST
Created attachment 81031 [details]
Patch
Comment 8 Hajime Morrita 2011-02-02 21:59:56 PST
Dimitori, thank you for the review!
I updated the patch.

(In reply to comment #4)
> (From update of attachment 80908 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=80908&action=review
> 
> Can you explain a bit about the originalVisibility? I may have known but forgotten, and now confuses me. I am easily confused. Why do we need this?
This is for the situation that dynamically changes the visibility. (hiding/unhiding the part element.)
Though <progress> has no such case,  <meter> has one.
I'm preparing for code sharing between <meter>and <progress>, so I'll put this here.

> 
> > Source/WebCore/html/HTMLProgressElement.cpp:40
> > +class ProgressBarValueElement : public HTMLDivElement {
> 
> This class should live in html/shadow/ProgressBarValuePartElement
Moved to there.

> 
> > Source/WebCore/html/HTMLProgressElement.cpp:53
> > +#if 0
> 
> You didn't mean to leave this in :)
>
Oops. Removed.
 
> > Source/WebCore/rendering/RenderIndicator.h:37
> > +    virtual bool shouldHidden() = 0;
> 
> shouldBeHidden()?
Sure. Renamed.

> 
> > Source/WebCore/rendering/RenderProgress.cpp:102
> > +    for (RenderObject* child = firstChild(); child; child = child->nextSibling())
> 
> Why is this here? Why can't we just use RenderProgress:layout()?
This is because RenderProgress shares layout() with RenderMeter via RenderIndicator superclass.
I'm going to migrate the layout code of both and remove layoutAsPart() at that change.
Comment 9 Dimitri Glazkov (Google) 2011-02-03 13:16:33 PST
Comment on attachment 81031 [details]
Patch

ok.
Comment 10 Dominic Cooney 2011-02-03 16:03:38 PST
It looks like patch 81031 mis-spells ProgressBarValueElement.h in GNUmakefile.am and WebCore.gypi (ProgressBarValuElement.h c.f. ProgressBarValueElement.h in WebCore.xcodeproj.)
Comment 11 Hajime Morrita 2011-02-03 17:43:24 PST
(In reply to comment #10)
> It looks like patch 81031 mis-spells ProgressBarValueElement.h in GNUmakefile.am and WebCore.gypi (ProgressBarValuElement.h c.f. ProgressBarValueElement.h in WebCore.xcodeproj.)
oh, thanks for finding this! I'll fix it before landing.
Comment 12 Hajime Morrita 2011-02-03 17:46:16 PST
Committed r77578: <http://trac.webkit.org/changeset/77578>