New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 605466 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
NOT IN USE
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Ability to style up input::-webkit-datetime-edit-year-field[disabled]

Reported by rice.coo...@gmail.com, Apr 21 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Example URL:

Steps to reproduce the problem:
HTML:

    <input type=date value=1970-01-01>

    <input type=date value=1970-01-01 min=1970-01-01 max=1970-02-01>

CSS:

    input::-webkit-datetime-edit-year-field
    {
        color: green;
    }

    input::-webkit-datetime-edit-year-field[disabled]
    {
        color: red;
    }

Demo on CodePen:
http://codepen.io/marek-saji/pen/LNrwxo?editors=1100

What is the expected behavior?
Year in the first input is green and in the second one — red.

What went wrong?
Both years are green.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 50.0.2661.75  Channel: stable
OS Version: Ubuntu 15.10
Flash Version: Shockwave Flash 21.0 r0

In devtools (after enabling “Show user agent shadow DOM”) one can see that user agent styles disabled fields as follows:

input::-webkit-datetime-edit-year-field[disabled], input::-webkit-datetime-edit-month-field[disabled], input::-webkit-datetime-edit-week-field[disabled], input::-webkit-datetime-edit-day-field[disabled], input::-webkit-datetime-edit-ampm-field[disabled], input::-webkit-datetime-edit-hour-field[disabled], input::-webkit-datetime-edit-millisecond-field[disabled], input::-webkit-datetime-edit-minute-field[disabled], input::-webkit-datetime-edit-second-field[disabled] {
    color: graytext;
}

but using the same selector does not work.
 
Cc: ashej...@chromium.org
Labels: -OS-Linux -Pri-2 -Type-Compat hasbisect BlinkCSS M-52 OS-All Pri-1 Type-Bug-Regression
Owner: r...@opera.com
Status: Assigned (was: Unconfirmed)
The above issue is reproducible on All-OS (Windows (10 & 7), Mac 10.11.4 & Ubuntu 14.04) with chrome versions : 50.2661.75(Stable), 51.0.2704.22(Beta) & 52.0.2714.0(Canary).

Manual bisect info
==================
Last known Good build: 49.0.2622.0
First known Bad build: 49.0.2623.0

Narrow bisect
=============
You are probably looking for a change made after 369752 (known good), but no later than 369763 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/edd8b00aa013ef2495fcf8d52e4ceb9858ba9eef..066021ea9e12b9a87e9497a1423a0de52c0a4061


From the narrow bisect, plausible offending CL https://codereview.chromium.org/1587643004 ?
@rune: Hey, can you please check the above issue and see if it's related to your change ?

Feel free to route the above issue to concern dev, if it's not related.

Note: Marking the above issue as RB-Stable, as this needs to be fixed before M-52 goes to stable. Feel free to change accordingly.

I really appreciate your help.

Thank you!

Labels: ReleaseBlock-Stable

Comment 3 Deleted

Comment 4 by r...@opera.com, Apr 22 2016

Status: WontFix (was: Assigned)
This was an intentional change. The selector in the demo is relying on the fact that there is an element in the UA shadow tree for showing the year which uses an attribute named "disabled" to show different styles when it's editable or not. If the UA shadow implementation changed, the selector would stop working anyway. This has been discussed on blink-dev before for author added generated content in UA shadow dom with ::before/::after which is now also prohibited.

Sign in to add a comment