Text isn't highlighted when editing a paragraph in latest Chrome Dev and Canary

[randomburner]

Description

Seems that from WordPress 6.4, it seems that you cannot highlight text in the editor using the latest versions of Chrome Dev or Chrome Canary - base Chrome works fine.

Step-by-step reproduction instructions

Edit Post or Page
Edit paragraph text.
Try to select text, and no background colour indicates position.

Screenshots, screen recording, code snippet

video.mp4

This video shows the issue.

Environment info

WordPress 6.4
Base 24 theme and custom themes
No plugins
Windows and MacOS Chrome Dev and Canary

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

@randomburner This is a little worrying, thanks for raising awareness! Unfortunately I couldn't download Chrome Canary (download wouldn't complete) or Chromium (download was corrupted), so I'm unable to test it.

It should probably be reported to chrome devs as I imagine it's a regression for them (https://bugs.chromium.org/p/chromium/issues/).

[randomburner]

@randomburner This is a little worrying, thanks for raising awareness! Unfortunately I couldn't download Chrome Canary (download wouldn't complete) or Chromium (download was corrupted), so I'm unable to test it.

It should probably be reported to chrome devs as I imagine it's a regression for them (https://bugs.chromium.org/p/chromium/issues/).

Cheers and have done, hopefully its nothing major.

[t-hamano]

I also tested it, but strangely, it seems like the problem only occurs on text in the block editor.

In the screencast below, I experiment with text highlighting in the content area of the block editor, sidebar text, a general web page, an element created with Codepen, the Notion editor, and more.

9f568687ccd1a8a00b122eff98673856.mp4

Environment info

• OS: Windows 11
• Browser: Chrome 121.0.6143.0（Official Build）canary （64bit）
• WordPress Version: 6.5-alpha-57120
• Gutenberg Version: 17.1.1 (Reproduced even after disabling the plugin)

[t-hamano]

Another thing I found out is that if you apply the ::selection pseudo-element as shown below, highlighting will also work on the block editor.

::selection {
	color: #fff;
	background-color: #2271b1;
}

[annezazu]

@felixarntz not sure if you can escalate but wanted to make you aware on the Chrome front.

[t-hamano]

Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1504444

[tunetheweb]

Do you have this flag enabled: chrome://flags/#enable-experimental-web-platform-features? I can repeat that with that flag, but not without it.

When I enable that flag and select some text, this CSS rule is activated from content.min.css?ver=6.4.1:

.block-editor-block-list__layout::selection {
    background: transparent;
}

That rule deliberately sets the background highlighting colour to transparent (not sure why?). But since block-editor-block-list__layout isn't used directly this hasn't caused problems until now.

However, one of the experimental features is enabling inheritance of that property which is a new standard (more details here).

So with that flag, the above rule is applied to the children - including any paragraphs added in the block editor.

Removing that rule, or overriding it as was noted in #56408 (comment), allows selection to work again.

So I guess my questions are: Why does that CSS rule exist in the first place? Should it? And, if so, do you need a new rule for children to not set this to transparent for when ::selection inheritance is supported by browsers?

BTW I work on the Chrome team with @felixarntz who made me aware of this, but I don't specifically work on CSS but was aware of ::selection issues from other issues I've seen (it's a big change to how selection has worked in the past and has caused some issues). So we may need to get someone who actually knows what they're talking about here, but hopefully that gives you some ideas of why this is happening, and whether this should be resolved in WordPress or if it indeed is a bug in Chrome, in the meantime. In my (limited) knowledge it seems like a WordPress issue affected by some up and coming changes.

[talldan]

Thanks for the insights and debugging @tunetheweb, that's immensely helpful.

This looks like the code that you highlighted -

gutenberg/packages/block-editor/src/components/block-list/content.scss

Lines 27 to 31 in 5f947ba

	// Hide selections on this element, otherwise Safari will include it stacked
	// under your actual selection.
	&::selection {
	background: transparent;
	}

There's a comment saying the rule is added to make the selection styles work in Safari. This PR should have more detail - #44148.

Lets loop in @jasmussen who worked on that.

[jasmussen]

The full context is shown in the two GIFs on this PR: #44148

Essentially the way to test if this is still needed is to comment out this change, then try and select from one paragraph, across a heading, and into another paragraph, and see if the selection looks as intended or not. From a quick test this morning, the CSS does not appear to be needed anymore, as both Chrome (stable) and Safari now appear to behave the same 🎉. Chrome:

Safari:

But I would appreciate carefully testing selecting across headings and other blocks thoroughly, especially in Safari, before merging any fixes.

[drdogbot7]

Just to clarify for regular Chrome users (not dev or canary). This very annoying issue will occur IF you have enable-experimental-web-platform-features flag enabled. I don't even remember when or why I enabled this, but it's been driving me crazy.

Thx @tunetheweb

Do you have this flag enabled: chrome://flags/#enable-experimental-web-platform-features? I can repeat that with that flag, but not without it.

[randomburner]

The full context is shown in the two GIFs on this PR: #44148

Essentially the way to test if this is still needed is to comment out this change, then try and select from one paragraph, across a heading, and into another paragraph, and see if the selection looks as intended or not. From a quick test this morning, the CSS does not appear to be needed anymore, as both Chrome (stable) and Safari now appear to behave the same 🎉. Chrome:

But I would appreciate carefully testing selecting across headings and other blocks thoroughly, especially in Safari, before merging any fixes.

We have tested removal of background: transparent in the gutenberg plugin, and i can now see the highlight across Chrome Canary, Dev, Base and also Safari

[jasmussen]

We have tested removal of background: transparent in the gutenberg plugin, and i can now see the highlight across Chrome Canary, Dev, Base and also Safari

Thank you, but just to be sure, the highlight was there in the past too, the problem was that this happened in Safari:

And it should look like this:

Can you share a screenshot of what you're seeing? I believe and hope it's fixed so it's all good, but just to be completely sure.

[randomburner]

Can you share a screenshot of what you're seeing? I believe and hope it's fixed so it's all good, but just to be completely sure.

No problems, and this is on Sonoma 14.0 & latest Safari

[jasmussen]

Promising. Thank you for testing!

I'll let others provide a green check, I cannot test it properly this morning, but it seems like the motivation for the initial hack has been addressed, so this can definitely move forward.

[progers]

The Chromium feature that caused this (https://chromestatus.com/feature/5090853643354112) will start releasing to stable-channel users Jan 16th as part of the 121 release (https://chromiumdash.appspot.com/schedule). Is it possible to rollout a WordPress change before then?

[annezazu]

@ellatrix with all of your work on the writing experience, is this something you could help with?

[ellatrix]

@annezazu This seems to be purely a styling/CSS issue, so not really :)

[randomburner]

The Chromium feature that caused this (https://chromestatus.com/feature/5090853643354112) will start releasing to stable-channel users Jan 16th as part of the 121 release (https://chromiumdash.appspot.com/schedule). Is it possible to rollout a WordPress change before then?

Looks like it will be fixed in 6.4.3?
https://core.trac.wordpress.org/query?id=59835%2C59841%2C59866%2C59892%2C59943%2C59840%2C59983

[t-hamano]

A similar issue was reported in #57283.

[talldan]

Looks like it will be fixed in 6.4.3?
https://core.trac.wordpress.org/query?id=59835%2C59841%2C59866%2C59892%2C59943%2C59840%2C59983

That just means it's milestoned for 6.4.3, but there's no fix as of yet.

I've tried to fix it in #57298, but unfortunately my testing was showing different results to the discussion here. Removing that one style didn't fix multi-block selection in chrome canary. I had to remove another style too, and that brings back the issue in Safari.

If I had to choose, this is an ok trade off, and we can look to fix the safari styles in a follow-up. The PR does need a lot of testing, I'm unfamiliar with the styles beyond what has been discussed here.

The Chromium feature that caused this (https://chromestatus.com/feature/5090853643354112) will start releasing to stable-channel users Jan 16th as part of the 121 release (https://chromiumdash.appspot.com/schedule). Is it possible to rollout a WordPress change before then?

@progers I don't think it's that simple, as while a lot of users should auto upgrade, there might be some on older versions. It's a very serious bug, so I think past versions of WordPress may also need patches. I'm concerned about users that might have auto updates switched off.

@desrosj Would be good to get your thoughts about the best course of action.

[jasmussen]

Created #57300 inspired by, and as an alternative to Dan's fix.

[maisondasilva]

If possible, test on Edge Canary, Dev and Beta to ensure the problem is resolved there too!

[progers]

@progers I don't think it's that simple, as while a lot of users should auto upgrade, there might be some on older versions. It's a very serious bug, so I think past versions of WordPress may also need patches. I'm concerned about users that might have auto updates switched off.

@talldan, thank you, that makes sense. And thank you for the quick fix!

Looping in @schenney-chromium for this.

[schenney-chromium]

I'll be moving the feature back to "experimental" in Chrome 121, which will still make it available through the flag "enable-experimental-web-platform-features" so you can test. We'll try for a roll out to stable Chrome for M122 but may end up continuing to delay depending on what breaks for you and others.

As far as I know Safari developers are working on matching the new behavior, but I have no timeline.

Note that to fix your issue while keeping in place the Safari fix, you might be able to follow this advice from the spec:

"Authors wanting multiple selections styles should use :root::selection for their document-wide selection style, since this will allow clean overriding in descendants. ::selection alone applies to every element in the tree, overriding the more specific styles of any ancestors."

You probably want the ::selection behavior as described, giving everything a default selection behavior while allowing more specific selection behavior for individual elements that need it, with no inheritance. I think this will leave Safari working as it does now, though I'm not certain.

[tistoubapt]

Hello

The problem reappeared with the latest version of Canary and the Trello site

[schenney-chromium]

Could you give me a link so I can investigate? I did verify that the link in the previous chrome bug was working correctly before relaunching, as best I could tell.

If the site works in other browsers (Safari, Firefox) I would expect it to work in Chrome Canary. Unless the site is (a) defining CSS custom properties in ::selection pseudos themselves or (b) relying on ::selection pseudos not being inherited.

(a) is a change from the previous attempt to launch highlight inheritance for ::selection, so it's most likely related to that.
(b) would have been something that was broken the last time I tried to launch this, but I did not know about to verify before launching again.

[tistoubapt]

Could you give me a link so I can investigate? I did verify that the link in the previous chrome bug was working correctly before relaunching, as best I could tell.

If the site works in other browsers (Safari, Firefox) I would expect it to work in Chrome Canary. Unless the site is (a) defining CSS custom properties in ::selection pseudos themselves or (b) relying on ::selection pseudos not being inherited.

(a) is a change from the previous attempt to launch highlight inheritance for ::selection, so it's most likely related to that. (b) would have been something that was broken the last time I tried to launch this, but I did not know about to verify before launching again.

Sure, on https://trello.com/

Not yet tested with another browser

Thanks

[schenney-chromium]

The CSS for trello.com includes div::selection { background-color: #0000; }. In chromium on linux the selection background is default, but Chrome Beta on linux it is transparent again. I think this is deliberate.

Devtools indicates this is inherited from div#trello-root.chrome.chrome-131.mac on Mac and chrome-130 linux on linux` but I think that's just an artifact of devtools. Regardless, the various chrome classes seem to indicate intent.

[tistoubapt]

Ok thanks

And normally it should work?
We have to try to reinstall the browser or is it a "bug"?

[schenney-chromium]

Oh, I see what is happening. The site was intending to disable selection painting of the div element but expecting the child <p> to continue to show the selection. So they were relying on it not inheriting. This must have broken the last time I tried to enable the change in Chrome, or maybe they have changed it since.

Adding :not(div)::selection { background-color: lightblue; } gets the selection back and is maybe what they wanted to happen, or maybe div :not(div)::selection { background-color: lightblue; } if you only want the children of divs that are not themselves divs.

So I guess someone needs to reach out to trello.com and ask them what they are intending. I'll inform Chrome DevRel about it and see what they say,

[tistoubapt]

Ok, thanks so much for your help

Not a problem coming from chromium like last time then and impacts all chromium browsers ?

[schenney-chromium]

I believe it will launch on other chromium based browsers too, and possibly all browsers. Are you affiliated with trello.com or in a position to tell them about the problem? If not I can figure out how to get the word out.

We have a blog post about this now: https://developer.chrome.com/blog/selection-styling

[tistoubapt]

Ok thanks

I have an account on Trello, I can try to contact them, telling them about this problem

[schenney-chromium]

I've contacted Trello and they have responded. A fix should be forthcoming.

[tistoubapt]

I've contected Trello too, and it's good since yesterday
I informed them

Thanks