[wp-trac] [WordPress Trac] #31634: Minor UI improvements to bulk editing

[WordPress Trac]

#31634: Minor UI improvements to bulk editing
-----------------------------------+--------------------------------
 Reporter:  siobhan                |       Owner:  afercia
     Type:  enhancement            |      Status:  assigned
 Priority:  normal                 |   Milestone:  Future Release
Component:  Quick/Bulk Edit        |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch ux-feedback  |     Focuses:  ui, accessibility
-----------------------------------+--------------------------------

Comment (by afercia):

 Re: the issue with the different implementation of the onchange event
 across browsers, seems something changed in Firefox between version 48 and
 49. In Firefox 48, the onchange event doesn't fire when using only the
 keyboard. In Firefox 49 does fire. To me, this seems a regression in
 Firefox and I've just opened a ticked on bugzilla, see
 https://bugzilla.mozilla.org/show_bug.cgi?id=1350700

 Worth considering that MDN still refers to the implementation Firefox used
 to have in the last 15 years or so :) See: https://developer.mozilla.org
 /en-US/docs/Web/Events/change
 > For example, keyboard navigation in <select> elements never fires a
 change event in Gecko until the user hits Enter or switches the focus away
 from the <select> (see bug 126379).

 I'd recommend to wait for a reply on the bugzilla ticket before making any
 decisions here.

 Other than this, the onchange event on select elements is tricky and there
 are other edge cases that can still be reproduced, both in Firefox for Mac
 or Win. For example, using Firefox 52.0.1 on a Mac:
 - apply the latest patch
 - go in the Posts screen
 - check a couple post checkboxes
 - using only the keyboard, focus the Bulk Edit select
 - press the Down Arrow key to open the select
 - press again the Down Arrow to select "Edit"
 - with the select still open, press the Tab key
 result: focus moves to the "dates" select and the Apply button gets
 skipped.

 Worth reminding the select elements behaviour varies depending on the
 platform and the browser used. On Windows for example, using the Down
 Arrow key doesn't open the select.

 '''Other considerations:'''
 (some of them are from previous comments)

 The Apply button should be enabled when at least two posts are selected,
 since doing a bulk action for only one post does not make much sense.

 The issue about the Plugins screen mentioned in comment 19 doesn't happen
 any longer since Shiny Updates has been introduced in core; however, it
 still happens on the Users screen. To reproduce:
 - select two users for deletion
 - select "Delete" from the dropdown
 - click Apply
 - you're now in a "Delete Users" screen
 - press your browser's back button
 - users are still selected, the dropdown is still on "Delete" but the
 Apply button is disabled

 Consider to give better feedback for screen reader users about what to
 expect and what happens, for example add some explanation, something along
 the lines of "bulk actions will be available when selections are made from
 the table below"

 @sagarprajapati thanks for the patch! A few things:
 When there's no support for JavaScript, the Apply button will be always
 disabled thus users won't be able to submit any action. This is something
 that was missed in the previous patches too :) The disabled state should
 be set via JS and not in the HTML.

 This part won't work in the Plugins screen after a plugin search:

 {{{
 $body.on( 'change', '#bulk-action-selector-top, #bulk-action-selector-
 bottom', function( event ) {
         actions.not( this ).val( this.value );
         setApplyButton( event );
 });
 }}}

 When doing a plugin search, the table gets re-injected via JS so the
 select elements are new objects while `actions` still refers to the select
 elements that were in the page on DOM ready. Result: the select are not
 synced and the buttons are still disabled, see screenshot below:

 [[Image(https://cldup.com/JC10yzHcUg.png)]]

 The patch would need some [https://make.wordpress.org/core/handbook/best-
 practices/coding-standards/javascript/ JS coding standards]. I'd suggest
 to run `jshint` which is very handy to check for syntax typos and so on.
 For example, you can run:
 `grunt jshint:core --file=common.js` to check a single file.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31634#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform