WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 3 months ago

#42390 new defect (bug)

TinyMCE + Edge input:focus placeholders disappear

Reported by: Cybr Owned by:
Milestone: 5.0 Priority: normal
Severity: normal Version: 4.9
Component: Administration Keywords: has-patch needs-refresh
Focuses: ui, accessibility, javascript Cc:

Description

Using EdgeHTML 15, when the TinyMCE script is present (tinymce.min.js), input placeholders disappear when focussing the field.

A good place to test this behavior is on the post/page's title input, where "Enter title here" will disappear on focus.

AFAIK, only input[type=text] and textarea are affected. input[type=password], for example, works as intended.

Attachments (1)

42390.patch (4.7 KB) - added by Cheffheid 7 months ago.
Leaves label hidden with sr-text class, adds placeholder attributes on post title field and dashboard quick post widget.

Download all attachments as: .zip

Change History (21)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 months ago

#2 @afercia
7 months ago

Worth noting "Enter title here" is not a real placeholder attribute. WordPress uses the field label element and "moves" it to make it visually appear within the field. I'm not saying this is ideal, it just worked this way for years.

#3 @afercia
7 months ago

Discussed a bit during today's accessibility bug-scrub. We think this JS trick was introduced because some years ago not all browsers supported real placeholder attributes. Today, there's the opportunity to use a real label and a real placeholder attribute. This would be more standard and would also allow to remove some JS.

#4 @afercia
7 months ago

  • Focuses administration removed
  • Milestone changed from Awaiting Review to 4.9.1

@Cheffheid
7 months ago

Leaves label hidden with sr-text class, adds placeholder attributes on post title field and dashboard quick post widget.

#5 @Cheffheid
7 months ago

  • Keywords has-patch added

First pass to help get things going. Took out the script that toggles the label into "placeholder mode" and set a proper placeholder on the post title field.

Noticed a similar script was being used on the dashboard for the Quick Draft widget on both the text input and textarea fields in it. Gone ahead and changed that too.

The "default" state for the labels seems to include the screen-reader-text class. I've left that the way it is for now to keep visual impact at a minimum.

https://cldup.com/btOJdJbbdR.gif

https://cldup.com/-0uDSFrVmq.gif

Last edited 7 months ago by Cheffheid (previous) (diff)

#6 @johnbillion
7 months ago

  • Milestone changed from 4.9.1 to 4.9.2

#7 @williampatton
5 months ago

  • Keywords needs-testing added

This ticket was mentioned in Slack in #core by williampatton. View the logs.


5 months ago

#9 @Clorith
5 months ago

  • Keywords needs-testing removed

The patch works fine in Edge for placeholders.

I will have to interject that for a minor update, we shouldn't be removing features or changing long standing behavior. It turns out that quite a few plugins have adopted the *-prompt-text approach from core, and rely on the JavaScript for this.

#10 @afercia
5 months ago

  • Keywords needs-refresh added

I'd agree this seems more something for a major release.

It turns out that quite a few plugins have adopted the *-prompt-text approach from core

Maybe the scripts could be kept and then find a way to not use them in core?

A few notes on the patch:

  • the patch didn't apply cleanly for me, needs a refresh
  • wptitlehint would need to be removed from the variable declarations at the top of the post.js file but if we keep the scripts I guess it should stay
  • the relevant CSS should be removed, but if we keep the scripts I guess it should stay too

More importantly: using the same text for both the visually hidden labels and the placeholder attributes should be avoided, as it would be redundant and not so useful for users. Currently, the same text is announced twice by screen readers:

  • in the post screen: label = Enter title here, placeholder = Enter title here
  • dashboard quick draft: label = What's on your mind?, placeholder = What's on your mind?

Maybe simplifying the label text would be enough:

  • in the post screen: label = Title, placeholder = Enter title here
  • dashboard quick draft: label = Content, placeholder = What's on your mind?

Not sure about the quick draft title, which would be announced as "Title Title". Maybe make it consistent with the post title? " Title Enter title here"?

Last edited 5 months ago by afercia (previous) (diff)

#11 @afercia
5 months ago

Hm, I see there's the enter_title_here filter... not sure what to do with it, but the title and placeholder text should be different.

#12 @afercia
5 months ago

For reference, the filter was added in [16247] see #21584, mainly for custom post types willing to change the visible "placeholder".

#13 @Cybr
5 months ago

Note that this issue affects all input fields that contain placeholders on affected pages. So, not only the #titlewrap > input field.

#14 @dd32
5 months ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

This ticket was mentioned in Slack in #core by desrosj. View the logs.


5 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


5 months ago

#17 @desrosj
5 months ago

  • Milestone changed from 4.9.3 to 4.9.4

Punting to 4.9.4.

#18 @dd32
4 months ago

  • Milestone changed from 4.9.4 to 4.9.5

Bumping, 4.9.4 has been released.

#19 @afercia
4 months ago

  • Milestone changed from 4.9.5 to 5.0

As per @Clorith 's comment I'd propose to move this ticket to 5.0.

#20 @afercia
3 months ago

Investigating a bit on the original issue, I think it's also something related to timing. There are two small pieces of JavaScript involved there: in the Add New post screen, the first JS puts focus on the title field, and the second removes the "placeholder" (actually it's the label). One of the JS is inline in the page, the other one is in an enqueued script. I think this leads to different behaviors, depending on the browser speed in parsing the page and JS and then run the related JS functions. Hardware can play a role too. This is what I see dumping some debugging text in the console when the two functions run:

IE11 (presumably slower than Edge):

https://cldup.com/YjHTj4j2pJ.png

Edge:

https://cldup.com/sbDSNdnNhs.png

Last edited 3 months ago by afercia (previous) (diff)
Note: See TracTickets for help on using tickets.