Bug 93665 - Changing class attribute is not reflected in the classList property
Summary: Changing class attribute is not reflected in the classList property
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Erik Arvidsson
URL:
Keywords:
Depends on:
Blocks: 94718
  Show dependency treegraph
 
Reported: 2012-08-09 16:09 PDT by Erik Arvidsson
Modified: 2012-08-22 14:30 PDT (History)
9 users (show)

See Also:


Attachments
Patch (9.84 KB, patch)
2012-08-16 14:15 PDT, Erik Arvidsson
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-06 (388.50 KB, application/zip)
2012-08-16 15:15 PDT, WebKit Review Bot
no flags Details
Patch (13.72 KB, patch)
2012-08-22 08:55 PDT, Erik Arvidsson
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-05 (589.70 KB, application/zip)
2012-08-22 10:00 PDT, WebKit Review Bot
no flags Details
Archive of layout-test-results from gce-cr-linux-04 (610.12 KB, application/zip)
2012-08-22 10:58 PDT, WebKit Review Bot
no flags Details
Patch (13.51 KB, patch)
2012-08-22 11:52 PDT, Erik Arvidsson
no flags Details | Formatted Diff | Diff
Patch (13.48 KB, patch)
2012-08-22 12:27 PDT, Erik Arvidsson
no flags Details | Formatted Diff | Diff
Patch for landing (13.47 KB, patch)
2012-08-22 12:33 PDT, Erik Arvidsson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Arvidsson 2012-08-09 16:09:13 PDT
classList is defined in Element but setting the class attribute needs to trigger classAttributeChanged which is only available on StyledElement
Comment 1 Erik Arvidsson 2012-08-16 14:15:18 PDT
Created attachment 158898 [details]
Patch
Comment 2 WebKit Review Bot 2012-08-16 15:15:22 PDT
Comment on attachment 158898 [details]
Patch

Attachment 158898 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13516539

New failing tests:
css3/selectors3/xml/css3-modsel-139.xml
css3/selectors3/xhtml/css3-modsel-113.xml
fast/dom/getElementsByClassName/011.xml
css3/selectors3/xhtml/css3-modsel-113b.xml
fast/parser/xhtml-alternate-entities.xml
css3/selectors3/xhtml/css3-modsel-139.xml
css3/selectors3/xml/css3-modsel-139b.xml
css3/selectors3/xml/css3-modsel-113b.xml
css3/selectors3/xhtml/css3-modsel-139b.xml
css3/selectors3/xml/css3-modsel-113.xml
Comment 3 WebKit Review Bot 2012-08-16 15:15:26 PDT
Created attachment 158920 [details]
Archive of layout-test-results from gce-cr-linux-06

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-06  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 4 Erik Arvidsson 2012-08-16 15:51:49 PDT
Comment on attachment 158898 [details]
Patch

I'll look into the failures tomorrow
Comment 5 Erik Arvidsson 2012-08-22 08:55:45 PDT
Created attachment 159948 [details]
Patch
Comment 6 WebKit Review Bot 2012-08-22 10:00:00 PDT
Comment on attachment 159948 [details]
Patch

Attachment 159948 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13567305

New failing tests:
fast/parser/xhtml-alternate-entities.xml
Comment 7 WebKit Review Bot 2012-08-22 10:00:03 PDT
Created attachment 159956 [details]
Archive of layout-test-results from gce-cr-linux-05

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-05  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 8 WebKit Review Bot 2012-08-22 10:58:17 PDT
Comment on attachment 159948 [details]
Patch

Attachment 159948 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13569299

New failing tests:
fast/parser/xhtml-alternate-entities.xml
Comment 9 WebKit Review Bot 2012-08-22 10:58:20 PDT
Created attachment 159965 [details]
Archive of layout-test-results from gce-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment 10 Erik Arvidsson 2012-08-22 11:52:09 PDT
Created attachment 159983 [details]
Patch
Comment 11 Ojan Vafai 2012-08-22 12:08:23 PDT
Comment on attachment 159983 [details]
Patch

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

> Source/WebCore/dom/ClassNodeList.cpp:57
> +    // TODO: DOM4 allows getElementsByClassName to return non StyledElement.

s/TODO/FIXME
Comment 12 Ryosuke Niwa 2012-08-22 12:10:39 PDT
Comment on attachment 159983 [details]
Patch

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

> Source/WebCore/ChangeLog:9
> +        Class attribute logic needs to be moved to Element (from StyledElement)
> +        https://bugs.webkit.org/show_bug.cgi?id=93665
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        Before this change classAttributeChanged was only called for StyledElement. With this refactoring
> +        it gets called for all Elements when the class attribute changes.

Does this fix some bug or is it just a refactoring? Please clarify.
Ideally the bug title is changed to reflect whatever behavior being fixed if there is any behavior change.

> Source/WebCore/dom/ClassNodeList.cpp:57
> +    // TODO: DOM4 allows getElementsByClassName to return non StyledElement.

We use FIXME instead of TODO.
Comment 13 Ryosuke Niwa 2012-08-22 12:11:15 PDT
Comment on attachment 159983 [details]
Patch

I don't think we can land the patch as is since it's unclear whether this patch is changing the behavior or just refactoring the code.
Comment 14 Ojan Vafai 2012-08-22 12:20:50 PDT
(In reply to comment #13)
> (From update of attachment 159983 [details])
> I don't think we can land the patch as is since it's unclear whether this patch is changing the behavior or just refactoring the code.

I thought it was clear from the test that it makes classList work for svg/xml elements. You just want that clearly spelled out in the ChangeLog?
Comment 15 Ojan Vafai 2012-08-22 12:21:28 PDT
What I mean to say, it it makes setting the class attribute and then reading out the classList work for svg/xml elements.
Comment 16 Ryosuke Niwa 2012-08-22 12:24:04 PDT
(In reply to comment #14)
> (In reply to comment #13)
> > (From update of attachment 159983 [details] [details])
> > I don't think we can land the patch as is since it's unclear whether this patch is changing the behavior or just refactoring the code.
> 
> I thought it was clear from the test that it makes classList work for svg/xml elements. You just want that clearly spelled out in the ChangeLog?

Well, it wasn't clear from the bug title & the change log entry whether this was a simple refactoring with an addition of test or this was fixing some bug for which we're adding a test.
Comment 17 Erik Arvidsson 2012-08-22 12:27:53 PDT
Created attachment 159990 [details]
Patch
Comment 18 Ryosuke Niwa 2012-08-22 12:30:42 PDT
Comment on attachment 159990 [details]
Patch

You should probably use Ojan's r+ but r=me anyhow.
Comment 19 Erik Arvidsson 2012-08-22 12:33:35 PDT
Created attachment 159991 [details]
Patch for landing
Comment 20 Erik Arvidsson 2012-08-22 12:35:02 PDT
(In reply to comment #18)
> (From update of attachment 159990 [details])
> You should probably use Ojan's r+ but r=me anyhow.

You are confusing me... I  just did --reviewer "Ojan Vafai". I guess it is not a big deal but I can redo it if you really care
Comment 21 WebKit Review Bot 2012-08-22 14:19:07 PDT
Comment on attachment 159991 [details]
Patch for landing

Clearing flags on attachment: 159991

Committed r126349: <http://trac.webkit.org/changeset/126349>
Comment 22 WebKit Review Bot 2012-08-22 14:19:13 PDT
All reviewed patches have been landed.  Closing bug.
Comment 23 Ryosuke Niwa 2012-08-22 14:30:41 PDT
(In reply to comment #20)
> (In reply to comment #18)
> > (From update of attachment 159990 [details] [details])
> > You should probably use Ojan's r+ but r=me anyhow.
> 
> You are confusing me... I  just did --reviewer "Ojan Vafai". I guess it is not a big deal but I can redo it if you really care

Yeah, that's what I meant to ask you :) I just set r+ on the patch for the bugzilla's sake.