1641382 - Runalyze "Save" button has the wrong background.

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Comment 1

[Eric Rescorla (:ekr)]

STR:

1. Log into https://runalyze.com/
2. Create a workout
3. Edit the workout.
4. The save button at the bottom of the lightboxed overlay will be invisible (it's actually a white "Save" on a very light beige background).

Expected results:
The Save button will have background #012E38

Actual results:
The Save button has background #fofoc0

Comment 2

[Eric Rescorla (:ekr)]

Attachment: Firefox Nightly

Comment 3

[Eric Rescorla (:ekr)]

Attachment: Screen Shot 2020-05-27 at 3.25.04 PM.png

Comment 4

[Eric Rescorla (:ekr)]

The second image is Chrome Release.

Comment 5

[Eric Rescorla (:ekr)]

I haven't spent too much time on this, but the proximal issue appears to be that in Firefox we are getting the color for:

input:read-only, input:disabled, input:read-only {
background-color: #f0f0e0;
}

Whereas in Chrome we ge:

input[type=submit] {
border: 0;
background-color: #012e38;
color: #e6eaeb!important;
padding: 8px 12px!important;
cursor: pointer;
font-size: 11px;
min-width: 100px;
box-shadow: 0 2px 2px 0 rgba(0,0,0,.14), 0 3px 1px -2px rgba(0,0,0,.2), 0 1px 5px 0 rgba(0,0,0,.12);
}

There is also a

.button:hover, input[type="submit"]:hover {
background-color: #1a5664;
color: #cde1e6 !important;
}

This does work properly in both Firefox in Chrome, so perhaps it's somehow interfering with the bare input[type="submit"] being processed? I wasn't able to induce our dev tools to show me the non-hover version because as soon as I select the button I get the hover version so I'm slightly guessing here.

Comment 6

[Mike Taylor [:miketaylr]]

Interesting, this is likely due to Bug 312971 landing recently (as it does not reproduce in Dev Edition).

For the rule in https://c2.runalyze.com/assets/css/runalyze-forms.less
(actually @ https://c2.runalyze.com/assets/css/runalyze-style.css?v=4.121.2)

input:disabled,
input:read-only,
input:-moz-read-only {
	background-color: #f0f0e0;
}

Presumably that rule didn't apply pre-312971 because it failed to parse the selector due to us not supporting unprefixed :read-only, and it doesn't apply in Chrome because they don't support :-moz-read-only. But now we support both, so the rule is valid.

Comment 7

[Mike Taylor [:miketaylr]]

Probably outreach is the right thing here, I'll see if I can find someone who works on the site.

The recommended fix is deleting that selector.

Comment 8

[Eric Rescorla (:ekr)]

Thanks to gl, here is the CSS on Firefox with hover disabled

element {
}
input:read-only, input:disabled, input:read-only {
background-color: #f0f0e0;
}

.button, input[type="submit"] {
border: 0;
background-color: #012e38;
color: #e6eaeb !important;
padding: 8px 12px !important;
cursor: pointer;
font-size: 11px;
min-width: 100px;
box-shadow: 0 2px 2px 0 rgba(0,0,0,.14),0 3px 1px -2px rgba(0,0,0,.2),0 1px 5px 0 rgba(0,0,0,.12);
}

So it looks like in Chrome .button, input[type="submit"] { is taking priority over input:read-only, input:disabled, input:read-only { and in Firefox vice vesa.

Comment 9

[Eric Rescorla (:ekr)]

[e-mail]

Comment 10

[Karl Dubost💡 :karlcow]

Reduced test case.
https://codepen.io/webcompat/pen/dyYEBOo?editors=1100

Safari has the same rendering than firefox.

it can be summarized to

  <input type="submit" value="Save">

<style>
    input {
      background-color: rgb(1, 46, 56);
      color: rgb(230, 234, 235) !important;
    }

    
    input:read-only {
      background-color: rgb(240, 240, 224);
    }
</style>

while :read-only is processed by Firefox and Safari, Chrome seems to ignore it.

seems related to https://bugs.chromium.org/p/chromium/issues/detail?id=939143
and https://bugzilla.mozilla.org/show_bug.cgi?id=620766

Comment 11

[Mike Taylor [:miketaylr]]

(sent a message to the founder/web developer on LinkedIn)

Comment 12

[Mike Taylor [:miketaylr]]

Got a reply, they're going to remove the rule.

Comment 13

[Mike Taylor [:miketaylr]]

Attachment: Save button -- fixed

Comment 14

[Mike Taylor [:miketaylr]]

This is fixed now.