Bug 68551 - border-width: initial and border-color: initial cannot be removed via CSSOM
Summary: border-width: initial and border-color: initial cannot be removed via CSSOM
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-21 11:28 PDT by Aryeh Gregor
Modified: 2012-01-09 13:14 PST (History)
6 users (show)

See Also:


Attachments
Proposed patch (9.09 KB, patch)
2011-12-04 08:02 PST, Andreas Kling
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff
Patch (8.43 KB, patch)
2011-12-04 11:41 PST, Andreas Kling
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2011-09-21 11:28:19 PDT
Test case:

data:text/html,<!doctype html>
<span style="border-width: initial"></span>
<script>
var span = document.querySelector("span");
span.style.borderWidth = "";
span.style.removeProperty("border-width");
span.style.removeProperty("borderWidth");
alert(span.style.cssText);
</script>

In Chrome 15 dev, this alerts "border-width: initial; ".  Opera 11.50 does something similar.  Firefox 8.0a2 alerts the empty string, as expected.  A similar test in IE9 (it doesn't like the data URL, so I used Live DOM Viewer) also alerts the empty string.  Chrome's behavior is very unexpected.  Chrome behaves the same for border-color.  In fact, if you do

data:text/html,<!doctype html>
<span style="border: 0"></span>
<script>
var span = document.querySelector("span");
span.style.border = "";
alert(span.style.cssText);
</script>

it alerts "border-style: initial; border-color: initial; ", which suggests these two properties have some peculiar bug.
Comment 1 Andreas Kling 2011-12-04 08:02:55 PST
Created attachment 117789 [details]
Proposed patch
Comment 2 WebKit Review Bot 2011-12-04 09:00:20 PST
Comment on attachment 117789 [details]
Proposed patch

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

New failing tests:
fast/dom/HTMLMeterElement/meter-element-markup.html
fast/dom/HTMLProgressElement/progress-element-markup.html
Comment 3 Andreas Kling 2011-12-04 11:41:34 PST
Created attachment 117800 [details]
Patch
Comment 4 Andreas Kling 2011-12-04 18:29:41 PST
Comment on attachment 117800 [details]
Patch

Clearing flags on attachment: 117800

Committed r101970: <http://trac.webkit.org/changeset/101970>
Comment 5 Andreas Kling 2011-12-04 18:29:50 PST
All reviewed patches have been landed.  Closing bug.
Comment 6 Aryeh Gregor 2012-01-09 12:54:22 PST
The test-cases from comment #0 still fail in Google Chrome 17.0.963.26 (Official Build 116225) dev.  about:version reports WebKit 535.11 (@103967), and 103967 is greater than 101970.  Do the test-cases in comment #0 actually work correctly in WebKit trunk?
Comment 7 Andreas Kling 2012-01-09 13:00:45 PST
(In reply to comment #6)
> The test-cases from comment #0 still fail in Google Chrome 17.0.963.26 (Official Build 116225) dev.  about:version reports WebKit 535.11 (@103967), and 103967 is greater than 101970.  Do the test-cases in comment #0 actually work correctly in WebKit trunk?

I'm not familiar enough with the Chrome release process to know what's up with that. FWIW it works in WebKit trunk with Safari, and with the latest Chrome Canary build. :)
Comment 8 Alexey Proskuryakov 2012-01-09 13:14:49 PST
So, marking RESOLVED again.