-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Focus title if title is empty #9608
Conversation
@@ -244,12 +244,12 @@ export const settings = { | |||
} ); | |||
} ); | |||
|
|||
// this checks for languages that do not typically have square brackets on their keyboards | |||
// Check for languages that do not have square brackets on their keyboards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes are largely unrelated, but I forget why I found this file when working on this patch and just wanted to tidy things up. Sorry 😉
test/e2e/specs/new-post.test.js
Outdated
newPost, | ||
} from '../support/utils'; | ||
|
||
describe( 'new post', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For maintenance sake, what sorts of things would we expect to exist here? Would it make sense to consolidate this with what we already have in hello.test.js
. I don't have a strong preference for the direction of consolidation, but there does appear to be overlap in the realm of "things we expect from the initial state of the editor".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, fair enough. I'll propose renaming hello.test.js
though, because that wasn't clear to me as the "new editor state" test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll propose renaming hello.test.js though, because that wasn't clear to me as the "new editor state" test suite.
Yep, I'd agree on that one 😄
@@ -1,6 +1,7 @@ | |||
/** | |||
* External dependencies | |||
*/ | |||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to import from react
. There's createRef
available from @wordpress/element
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth considering ESLint rule error'ing on react
import. It shouldn't be present anywhere (save for tests, I suppose).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, right, sorry 'bout that.
Changes made, good for another look! |
// If there is a post title and it's empty, we should focus the title so | ||
// the user can start typing the title right away. | ||
if ( ! this.props.title || ! this.props.title.length ) { | ||
this.textareaRef.current.textarea.focus(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will have another maybe "unwanted" side effect? If you switch to code mode and you switch back to editor without touching the title, it will be autofocused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah shoot, good call. I was thinking "we don't re-mount the title after we render the editor, right?" But I guess we do, I'll handle this more robustly. 👍
Shouldn't this be the same component, and thus not unmounted when switching modes? |
It seems the layout of the editor is changed "above" the title component so things are re-rendered. That's probably a legit bug but it might be beyond this one. 😄 |
// If there is a post title and it's empty, we should focus the title so | ||
// the user can start typing the title right away. | ||
if ( ! this.props.title || ! this.props.title.length ) { | ||
this.textareaRef.current.textarea.focus(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can Textarea
receive an autoFocus
prop to simplify the implementation?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea#attr-autofocus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it supports passing through other props given it's not a stock <Textarea>
, but I'll have a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can and that actually worked well, but Puppeteer doesn't seem to like it. I'm just working on figuring out why and then this'll be good to go and less complicated.
Okay! Improvements made; this now uses autofocus and behaves a lot better. All set for another review. |
a901273
to
9de29e3
Compare
@@ -36,6 +36,7 @@ class PostTitle extends Component { | |||
this.onUnselect = this.onUnselect.bind( this ); | |||
this.onKeyDown = this.onKeyDown.bind( this ); | |||
this.redirectHistory = this.redirectHistory.bind( this ); | |||
this.textareaRef = createRef(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused, should remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, good catch!
focus the title on new post so the author can start typing | ||
right away, without needing to click anything. | ||
*/ | ||
autofocus={ this.props.isPostEmpty ? 'autofocus' : undefined } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't React warn about this usage, since we're assigning the attribute, not the DOM property autoFocus
(capitalized "F")? With the latter, I'd also expect this to be passed as a boolean, i.e.
autoFocus={ this.props.isPostEmpty }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see a warning, also I meant to assign the attribute… will React do some magic and assign a value to a DOM attribute if passed like that?! 😱
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related: https://reactjs.org/blog/2017/09/08/dom-attributes-in-react-16.html
Notably:
Note that you should still use the canonical React naming for known attributes:
// Yes, please <div tabIndex="-1" /> // Warning: Invalid DOM property `tabindex`. Did you mean `tabIndex`? <div tabindex="-1" />
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed that one, cool!
9de29e3
to
13b6d43
Compare
Set for another review, sorry 'bout the delay! Thanks for the info on DOM attributes! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
I'm a little wary of the unintended remounts triggering focus grabs, but if anything it would be good for those to be surfaced (as disruptive as they might be) since the unintentionally surrounding this possibility should itself be considered a bug worth addressing.
A small thing, but it was a bit jarring for me to see the additional visual effect of the focused title (the border) when loading the editor. This is, of course, expected as a result of the title being auto-focused, though in the broader sense maybe we don't want to have such a heavy first impression. Worth iterating if it's sensed to be problematic.
Fair enough, I could see the focus style being tweaked is the post is in the same state that enables Unrelated, but that's some Chrome theme you have there. ✨ |
I tested and focus automatically goes to the title on new posts, but that does not happen for pre-existing published or draft posts with an empty title. Is this the intended behavior? Tested with Firefox 62.0, Safari 11.1.2, and Chrome 69.0.3497.92 on macOS 10.13.6. |
That's the intended behaviour, yes. The idea is that any existing post that's been saved without a title was done so intentionally, so we don't focus the title in that case. It would probably be nice if we eventually focused the last block on an existing page, but that's another issue 😄 For now nothing should be focused on an existing post. |
Since I just encountered it in an unrelated fix, what should be the expected behavior for a new post with a non-empty title, either via |
My take: since the demo post is a new post that has not yet been saved (bit of an edge case), so I think it's fine that auto-focus works for the title in that case. |
I'd like to propose to reconsider this for the demo post, if no objections? I'd tend to think the demo post should serve to familiarize with the whole UI. Skipping all the UI that's before the post title doesn't help screen reader users in discovering the features in the top bar. Actually, I'm not even sure if the demo post is meant to stay after merge, but what about checking explicitly if the post is empty? Something like |
Ah, that's a really good point @afercia. I'm not sure it's staying either but before I thought that edge case of focusing the title on the demo was fine because I wanted to err toward simple code. As it serves as an introduction to the editor, not focusing it seems good. I mean, on the other hand, it means the intro to the editor won't focus the title like a new post would, but then a post like the demo page that had been saved wouldn't focus either. 🤷♂️ So yeah, I think that's a good point and we shouldn't focus it if a title is present. 👍 I've filed: #10601 to track it. |
Description
Focuses the title when empty. Fixes #3828.
How has this been tested?
Tested locally in Firefox and Chrome for Mac; IE 11 and Edge in Windows.
Added an E2E test as well.
Screenshots