Created attachment 376934 [details] test case <input style="color: #c1c4c6; background: none;" required disabled type="text"/> input element like this won't set the font color properly, see attached test case
Created attachment 376939 [details] Wrong color font
It only happens if "disabled" is set too.
Root cause is here: Color RenderTheme::disabledTextColor(const Color& textColor, const Color& backgroundColor) const { // The explicit check for black is an optimization for the 99% case (black on white). // This also means that black on black will turn into grey on black when disabled. Color disabledColor; if (Color::isBlackColor(textColor) || backgroundColor.alphaAsFloat() < minDisabledColorAlphaValue || differenceSquared(textColor, Color::white) > differenceSquared(backgroundColor, Color::white)) disabledColor = textColor.light(); else disabledColor = textColor.dark(); // If there's not very much contrast between the disabled color and the background color, // just leave the text color alone. We don't want to change a good contrast color scheme so that it has really bad contrast. // If the contrast was already poor, then it doesn't do any good to change it to a different poor contrast color scheme. if (differenceSquared(disabledColor, backgroundColor) < minColorContrastValue) return textColor; return disabledColor; } background:none will create pass in a background color as rgba(0,0,0,0) which means it is totally invisible here, and differenceSquared method will only take care about the rgb color value, so it will treat the background color as black, therefore it will return a very light color. The easy fix here is if we have a user defined color, we shouldn't use this method to compute an override disabled color. However, I think the real fix here is we shouldn't relay on the text block's background, if the alpha has been set, we need somehow find the real mixed background color, and calculate the contrast.
Created attachment 377105 [details] Patch
Attachment 377105 [details] did not pass style-queue: ERROR: Source/WebCore/ChangeLog:8: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 377105 [details] Patch Attachment 377105 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12959774 New failing tests: fast/forms/input-disabled-color.html
Created attachment 377111 [details] Archive of layout-test-results from ews213 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews213 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Created attachment 378227 [details] Patch
I checked the failed layout test, input-disabled-color.html It seems like we intent to change the user specified color, when the input is disabled. I wonder if this is the correct behavior? Morden CSS design always have a specified disabled color for the input: input[disabled] { color: xxxx background: yyyy } This "disabled color adjustment" actually will make this color xxxx always inaccurate, which is bad, in my opinion, it can completely ruin the user color platte. My newly uploaded patch will disable this "disabled color adjustment" if user have set a color for the input. The disabled color adjust will now only happen for the inputs which use system color. Chrome have a similar performance like this.
Created attachment 378238 [details] Suggested performance HTML
Created attachment 378239 [details] Suggested Performance
Comment on attachment 378227 [details] Patch Attachment 378227 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/13007201 New failing tests: fast/forms/input-disabled-color.html
Created attachment 378245 [details] Archive of layout-test-results from ews213 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews213 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit