I've noticed that Gutenberg edits the <title> tag:

As an existing WordPress writer, this makes it difficult to find the tab I was writing in because I'm accustomed to searching for "Edit Post":

Just wanted to record this usability feedback.
This is important for accessibility too, as the document title is the first thing screen readers announce. Not sure what the reasoning behind this is, but at least the initial document title should be consistent with what WordPress does in the Classic Editor and say as first thing _what_ the page is about:
Edit Post ...
Edit Page ...
Edit {CPT name here} ...
It was added here: https://github.com/WordPress/gutenberg/pull/1802
Only other thought I have is: Do we really want the document title to be assigned as the post's title? Per #1737 and current editor behavior, seems "Edit Post" could work just as well. Was there any conversation or thoughts behind the choice to use post title?
cc @westonruter @aduth
If you have multiple posts open for editing in multiple tabs, having the post's title in the document title is key to be able to identify which tab contains the post you're needing to get back to editing. The post title was put at the beginning to account for browser tabs that are narrow, as in screenshot. But prefixing the title with “Edit…” would probably be a good compromise. (Or else, a ✏️ emoji perhaps? 😄)
(Or else, a ✏️ emoji perhaps? 😄)
lol. Well I understand the argumentation, however Gutenberg shouldn't deviate from what WordPress does in all the other screens. The document title should be consistent across all admin screens. Not sure adding the post title would fit in the limited space (browsers tend to truncate long titles); we should also consider the doc title has a limited _visual_ value, while it is very important for other software reading (and announcing) it.
I'm not sure we're being serious but a -1 on emoji's here, they are awesome but not in this case :)
I think it's right to go with existing WP patterns in this case. We can always iterate on them later.
I've done a very small edit which adds an 'Edit: ' to the beginning of the editor's
To better document this issue...
Gutenberg does a pretty mediocre job of rendering the document title <title>.
Specifically, when creating a new post, Gutenberg shoves the title in front of Add New Post ‹:

Then, once you've saved the post and refreshed the page, Gutenberg ends up in this state:

Because the document title can be both localized _and_ filtered with admin_title, I think we should ditch this client-side modification and only set <title> server-side.
Because the document title can be both localized _and_ filtered with
admin_title, I think we should ditch this client-side modification and only set<title>server-side.
Playing devil's advocate: If I refresh the screen at any point in time, assuming I have no unsaved changes, I expect I should be presented with an identical UI, where the browser tab is considered part of the UI. I'm thinking analogous to a pure function at the browser level. Currently this is more-or-less true.
Without client-side modification as proposed, however, I expect this will no longer be true.
Cost/benefit may still favor abandoning client-side modification, but I figured it was worth highlighting a yet-unmentioned cost.
Currently this is more-or-less true.
The current implementation is broken though?
Without client-side modification as proposed, however, I expect this will no longer be true.
If we switch back to purely server-side, then the <title> tag should remain consistent regardless of state.
To avoid the complexity of having to deal with two separate styles of document <title> (one for post-new.php and a second for post.php?post=<id>), maybe we could _always_ redirect post-new.php to post.php?post=<id> and avoid post-new.php entirely.
I'm unsure of the history for post-new.php / post.php?post=<id>, so we'd need to vet this from a back-compat perspective. I'm not aware of any immediate back-compat concerns though.
Always redirecting post-now.php to post.php has the potential for a whole host of subtle bugs that rely on the WP_Screen functionality, or the $parent_file / $submenu_file values. I would like to avoid it if possible.
Given that the <title> doesn't include the post_title, I think it's reasonable to duplicate the logic in admin-header.php to generate the "Edit Post" <title>, and swap that in when the new post is saved.
While I'm thinking of it, the other thing that needs to dynamically update is this:

Always redirecting
post-now.phptopost.phphas the potential for a whole host of subtle bugs that rely on theWP_Screenfunctionality, or the$parent_file/$submenu_filevalues. I would like to avoid it if possible.
Arguably, these bugs are already present in Gutenberg, given the editing experience starts at post-new.php and doesn't load post.php until page refresh, whereas the Classic editor opens post.php after the first save.
While I don't have a strong opinion about the final implementation, I'm not sure the information you've presented is an argument in favor of your suggested implementation. I think always redirecting is an option still worth considering.
Arguably, these bugs are already present in Gutenberg, given the editing experience starts at
post-new.phpand doesn't loadpost.phpuntil page refresh, whereas the Classic editor openspost.phpafter the first save.
This may have changed. I tested creating a new post in Gutenberg just now and the Gutenberg editor opened post.php after the first save.
Because the document title can be both localized _and_ filtered with
admin_title, I think we should ditch this client-side modification and only set<title>server-side.
Digging a little deeper, why does the ability to localize and filter admin_title matter for this? Is it because if you make a change to <title> client-side that change will be temporarily be out-of-sync until an autosave happens?
Tested and confirmed that in the Classic editor the <title> is prefaced with Edit Post while editing whereas the Gutenberg editor does not.
Classic editor:
Add New Post ‹ Site Title — WordPress.Edit Post ‹ Site Title — WordPress.Edit Post ‹ Site Title — WordPress.Edit Post ‹ Site Title — WordPress.Post Title – Site Title.Gutenberg editor:
New post | Add New Post ‹ Site Title — WordPress.Post Title | Add New Post ‹ Site Title — WordPress.Post Title | ‹ Site Title — WordPress.Post Title | ‹ Site Title — WordPress.Post Title | ‹ Site Title — WordPress.Post Title – Site Title.
Seen at http://alittletestblog.com/wp-admin/post.php?post=13826&action=edit running WordPress 4.9.6 and Gutenberg 3.1.0 using Firefox 60.0.2 on macOS 10.13.5.
I removed the Good First Issue label and added the Needs Decision label because the following should be addressed before this issue is actionable:
<title> be prefixed with Edit: or Edit Post ‹ while editing a post with Gutenberg?<title> not be changed client-side because it can be localized and filtered with admin_title?<title>?At this point, my vote would be:
Edit Post ‹ Site Title — WordPress<title> is not changed client-side.<title> can be filtered by the admin_title filter.post-new.php to post.php?post=, and maintains the same <title> between them.I think this is the simplest implementation that maintains the closest parity to Classic Editor behavior.
Gutenberg does not redirect
post-new.phptopost.php?post=
I'm not really so fond of this one, largely because I think it's a common pattern to reload the page (as an explicit user interaction, or maybe just reopening closed tabs). And if I'd started and saved a post, I'd expect a reload to bring me to that post; not a blank new post.
Would it be enough to just remove client-side title manipulations for now? I don't know that they're adding much value as it is.
I'm not really so fond of this one, largely because I think it's a common pattern to reload the page (as an explicit user interaction, or maybe just reopening closed tabs). And if I'd started and saved a post, I'd expect a reload to bring me to that post; not a blank new post.
Ah, I see that you're referring to Gutenberg's existing behavior of updating the URL after initial save. I think this behavior should persist. I was referring to forcefully redirecting post-new.php on PHP page load.
I think we should make these changes:
<title>.<title> to Edit Post ‹ Site Title — WordPress, regardless of whether the page is post-new.php or post.php?post=.I can prepare a PR
Most helpful comment
If you have multiple posts open for editing in multiple tabs, having the post's title in the document title is key to be able to identify which tab contains the post you're needing to get back to editing. The post title was put at the beginning to account for browser tabs that are narrow, as in screenshot. But prefixing the title with “Edit…” would probably be a good compromise. (Or else, a ✏️ emoji perhaps? 😄)