Bug 68551 - border-width: initial and border-color: initial cannot be removed via CSSOM
: border-width: initial and border-color: initial cannot be removed via CSSOM
Status: RESOLVED FIXED
: WebKit
CSS
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2011-09-21 11:28 PST by
Modified: 2012-01-09 13:14 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-09-21 11:28:19 PST
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 From 2011-12-04 08:02:55 PST -------
Created an attachment (id=117789) [details]
Proposed patch
------- Comment #2 From 2011-12-04 09:00:20 PST -------
(From update of attachment 117789 [details])
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 From 2011-12-04 11:41:34 PST -------
Created an attachment (id=117800) [details]
Patch
------- Comment #4 From 2011-12-04 18:29:41 PST -------
(From update of attachment 117800 [details])
Clearing flags on attachment: 117800

Committed r101970: <http://trac.webkit.org/changeset/101970>
------- Comment #5 From 2011-12-04 18:29:50 PST -------
All reviewed patches have been landed.  Closing bug.
------- Comment #6 From 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 From 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 From 2012-01-09 13:14:49 PST -------
So, marking RESOLVED again.