WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#35832 closed defect (bug) (fixed)

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

Reported by: xkr47 Owned by: westonruter
Milestone: 4.9 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch commit
Focuses: ui, javascript, administration Cc:

Description

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.

Attachments (2)

35832.diff (833 bytes) - added by westonruter 4 years ago.
35832.2.diff (1.7 KB) - added by westonruter 3 years ago.

Download all attachments as: .zip

Change History (22)

#1 @westonruter
4 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.5
  • Version changed from 4.4.2 to 3.4

@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.

@westonruter
4 years ago

#2 @westonruter
4 years ago

  • Owner set to westonruter
  • Status changed from new to accepted

#3 follow-up: @afercia
4 years ago

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.

#4 in reply to: ↑ 3 @westonruter
4 years ago

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

#5 follow-up: @afercia
4 years ago

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

#6 in reply to: ↑ 5 @azaozz
4 years ago

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.

Last edited 4 years ago by azaozz (previous) (diff)

#7 @westonruter
3 years ago

  • Keywords needs-patch added; has-patch removed
  • Owner westonruter deleted
  • Status changed from accepted to assigned

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.

#8 @westonruter
3 years ago

  • Milestone changed from 4.5 to Future Release

#9 @westonruter
3 years ago

Proposed removal of IE8 support in #38021.

#10 @westonruter
3 years ago

  • Milestone changed from Future Release to 4.8

@westonruter
3 years ago

#11 @westonruter
3 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to westonruter
  • Status changed from assigned to accepted

#12 @westonruter
3 years ago

  • Keywords needs-refresh added

#13 @westonruter
3 years ago

#39094 was marked as a duplicate.

This ticket was mentioned in Slack in #core-themes by westonruter. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


2 years ago

#16 @westonruter
2 years ago

  • Milestone changed from 4.8 to 4.8.1

#17 @westonruter
2 years ago

  • Milestone changed from 4.8.1 to 4.9

This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.


2 years ago

#19 @westonruter
2 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#20 @westonruter
2 years ago

  • Keywords commit added; needs-refresh removed
Note: See TracTickets for help on using tickets.