Post submit box buttons sometimes ignore click events

[ericlewis]

I would like to begin with an apology for the vagueness of this bug.

Ever since 3.8, I've noticed buttons in the Publish meta box not accepting click events on various installs.

I haven't been able to reproduce the bug solidly, but can sometimes. Again, apologies.

I go into a post, edit some of the content, and try clicking one of the buttons. It depresses but nothing happens.

See screencast for example.

Found on Chrome 31.0.1650.63 on Mac OS X.IX

[ocean90]

Do you have any plugins active? Can you see any ​JavaScript errors?

[ericlewis]

Replying to ocean90:

Do you have any plugins active? Can you see any ​JavaScript errors?

I can reproduce this on trunk with no plugins active, no JS errors in the console. I've had this issue on the make core site, my personal site, and on a local version of trunk, so I think there's something else at play.

I think it has to do with clicking on the outer region of the button - not directly on the button text, but between the text and the edge of the button. The button still depresses, and it's clearly clickable space within the button. When I click directly on the text it goes through.

[johnbillion]

Now you mention it, I too have seen this behaviour but I usually put it down to "oh I missed that button again, but I thought I saw it depress...".

[kpdesign]

Replying to johnbillion:

Now you mention it, I too have seen this behaviour but I usually put it down to "oh I missed that button again, but I thought I saw it depress...".

I've seen the same thing, in the admin on several screens and the login screen, on make/ blogs and on my own installs, in Chrome and Firefox.

Like you, I thought I had missed it, but the button showed depressed.

[ericlewis]

[deleted]

[ericlewis]

Occurred on the "Log in" button on install.php?step=2.

Seems to be related to buttons that are actually styled anchor tags.

[nacin]

Moving for investigation.

[jaredatch]

I just wanted to say thank you for creating this ticket.

This has been happening for months since MP6, so it's nothing new, but has been driving me crazy.

I deal with a ton of installs, and it affects all of them. Often times right after initial setup when no plugins are activated. Like you mentioned, I it don't happen all of the time, but I'd say a good 10% of the clicks it seems. Enough to irk me.

Originally I thought I was losing my mind, but I've talked to half a dozen other devs who have encountered this.

Lastly, it's not limited to the post submit box. I know I've had it happen with saving menus elements (and similar) as well.

[griffinjt]

I confirm that this is a really freaking annoying issue too. Half the time I wonder why my page is not refreshing only to find out that the click event was never triggered. Happens to me in Chrome.

[ericlewis]

attachment:26700.2.mov​ is a sequel to my earlier bug reproduction video.

Looks like it happens when you click directly on the descent. I also saw the same behavior clicking directly on the ascent. (See ​Typography Line Terms)

[johnbillion]

Confirmed. There is indeed a 1px horizontal dead spot on the buttons where the descent is. I can reproduce it in Chrome on OS X but not Firefox, unless I haven't found the magic spot.

[nacin]

Replying to johnbillion:

Confirmed. There is indeed a 1px horizontal dead spot on the buttons where the descent is. I can reproduce it in Chrome on OS X but not Firefox, unless I haven't found the magic spot.

It's definitely more than this dead spot. This has been driving me crazy for both "Save Draft" and "Publish", and I'm definitely not finding a 1px dead spot every time. I'm usually clicking in the middle of the button.

[johnbillion]

I think this is due to the :active rule for the buttons which insets the button by 1px when depressed. I can't reproduce the bug with that :active rule removed. Anyone else?

Related Chrome bug: ​https://code.google.com/p/chromium/issues/detail?id=163854

[ericlewis]

So what we need to do here is change the :active state to something that does not move the button. UI team?

[johnbillion]

26700.diff​ simply removes the change to the padding (which gives the inset effect) when buttons are active. The buttons retain a visible active state due to an inset box shadow. The secondary buttons actually have a slightly more prominent active state than primary buttons do.

Thoughts?

[iammattthomas]

In 26993:

Eliminate the 1px padding adjustment on active buttons because it creates an un-clickable dead zone 1px high and spanning the entire width of the button. Modify the background color of active buttons for better contrast to make the active state more obvious.

See #26700, props johnbillion.

[iammattthomas]

26700.diff​ fixed the issue for me, but as johnbillion mentioned, .button-primary's active state was less prominent than .button-secondary. To fix that, I made the :active button background darker than the hover state, where previously they were the same color.

[helen]

This is going to force a build and a bunch of modified files in the 3.8.1 partial if merged.

[nacin]

In 26998:

Eliminate the 1px padding adjustment on active buttons because it creates an un-clickable dead zone 1px high and spanning the entire width of the button.

Merges half of [26993] to the 3.8 branch.

props johnbillion.
see #26700.

[nacin]

I *may* merge the rest of that changeset to 3.8.1. Let's see if we need a color build or not.