Paste action in text field/area context menu in theme customizer leaves Save&Publish button disabled (Firefox)

[xkr47]

Twenty Sixteen theme. No plugins activated.

If I go to Appearance -> Customize -> Site Identity and then right-click in the "Site Title" field and select Paste from the menu (having some text on the clipboard), the Save button remains greyed out and cannot be clicked. If I click it anyway, nothing happens and my changes aren't saved.

Ironically, only if I click anywhere outside both the Site Title and the Save button, the button suddenly updates and now shows "Save & Publish" and performs the expected operation when clicked.

This occurs with Firefox 40+ on both Windows and Linux platforms. It occurs both with singleline text fields and multiline text areas. It occurs with other themes too.

[westonruter]

@xkr47 Thanks for the report. I can reproduce this issue. It seems the problem is that the default element synchronizer logic for the text field is only looking for changes in response to change and keyup events. Since no keyup happens when you paste via the context menu, and since you are still focused on the field, no change happens.

The fix is to just make sure that input event is always used. See 35832.diff​ and please test.

[afercia]

Worth considering there's an ongoing effort to standardize on "input" and "keyup" and don't use "change" any more, discussion started a while ago, see 26600.

[westonruter]

Replying to afercia:

Worth considering there's an ongoing effort to standardize on "input" and "keyup" and don't use "change" any more, discussion started a while ago, see 26600.

This is great. Thanks for pointing that out. So we should let input be the base event as opposed to change, but for IE≤8 we should include keyup, cut, copy, and paste as fallbacks (or perhaps IE's propertychange event?). I wasn't aware that IE8 didn't support input, and also it looks like input is not fully supported by IE9 either (in the case of hitting backspace): ​http://caniuse.com/#feat=input-event

[afercia]

About IE 8 I wouldn't be so worried if pasting doesn't work. Worth noting, as far as I see, the "Save" button in IE 8 is always "Save & Publish" and never gets disabled?

It's always a developer's choice, but I think the point raised up on #26600 by @azaozz and I was to try to reduce the number of attached events. Personally, I'd lean towards keeping it simple and just use input and keyup.

The current situation in core is a bit inconsistent :) There are places where only input is used, thus leaving IE 8 in the dark. In other places both input and keyup are used, or even input, keyup and change together. In some places, for <input>s of type="search", the non-standard search is used in addition to the 3 ones mentioned before. There are also a couple of places where feature detection is used to attach just one event, see for example in user-profile.js and nav-menu.js

[azaozz]

Yes, would be great to standardize these events. According to caniuse.com input works quite well except in IE8. If support there is crucial we can fall back to using change. Perhaps something like:

var event = ( 'oninput' in document ) ? 'input' : 'change';
$( element ).on( event, function() ...

Of course these form elements will also need keyup for Enter and Esc. But thinking we shouldn't worry about cut, copy, and paste for old IE.

[westonruter]

Perhaps this is out of scope for this ticket, but there is also an opportunity to reduce an extra needless Ajax request for changes to widget inputs. When an input event happens on a field in a widget, all of the named form fields get submitted to the server for sanitization to obtain a hmac-verified PHP-serialized string which is then passed to the preview for rendering (this is done so that the user cannot submit arbitrary serialized PHP data, since serialized data is a security vulnerability). But at the moment an update-widget Ajax request is made for each input event and also when a change event happens. So this usually means that there are at least two Ajax requests made for each change to a field. Ideally the change event could be circumvented if it sees that an input event already sent data to the server that matches what is the current value of the field when change is triggered.

See also #33507 which would allow us to get rid of the update-widget Ajax request and dealing with serialized data.

[westonruter]

Proposed removal of IE8 support in #38021.

[westonruter]

New version of the patch needs to be extracted from which has some fixes: ​https://github.com/xwp/wp-customize-input-validity-constraints/blob/master/customize-input-validity-constraints.js

[westonruter]

#39094 was marked as a duplicate.

[westonruter]

In 41387:

Customize: Use input event instead of keyup or propertychange events when listening for changes in wp.customize.Element instances.

Ensures that a control's Element is updated in response to pasting into the field. Also fixes issue where inputs using "new" HTML5 types (like url and number) were not updating in the preview during keystrokes. The use of input was previously blocked due to needing to support IE9, but this is no longer a concern since IE<11 is no longer supported.

See #38845, #28477.
Fixes #35832.