The PickedItem component does not show up nicely

[saltnpixels]

Describe the bug

The contentPicker has some stylistic issues when used in inspector controls. It also has some html issues.

1. The class .block-editor-link-control__search-item-title is set to have white-space: nowrap; This causes the item to go offscreen and the "X" cannot be reached to remove the post from the list.
2. The items are being decoded on line 80 in PickedItem.js. if html is used in the title, that comes through decoded. Probably better to remove any html

** Fix **

In PickedItem.js on line 80, maybe we can remove the entities completely:

decodeEntities(suggestion.title)
// to
decodeEntities(suggestion.title).replace(/(<([^>]+)>)/gi, "")

The same would be done in SearchItem.js on line 38.

As for the CSS that would need to be scoped to the Inspector.

Screenshots

[tlovett1]

Can you open up a PR?

[xavortm]

I checked this on develop; now it looks like this

Tested in this setup:

<InspectorControls>
	<PanelBody>
		<ContentPicker
			onPickChange={(pickedContent) => {
				console.log(pickedContent);
			}}
			mode="post"
			label="Please select a Post or Page:"
			contentTypes={['post', 'page']}
		/>
	</PanelBody>
</InspectorControls>

I quickly checked out an older commit (before the reported issue in develop) and it is still working nicely. Would it be some browser support issue? I think the screenshot is from Chrome however...

The block-editor-link-control__search-item-title element has overflow: hidden; text-overflow: ellipsis; set to it.

No-wrap is working nicely with the text-overflow here. If it is removed, the full title can be made visible (maybe a good idea) but it will go on multiple lines then like this.

[Firestorm980]

Just doing some additional research on this one, it looks like it may have been resolved in Gutenberg via WordPress/gutenberg#33586 (comment). When I checked in a local 5.9.1 install, title text was wrapping (I think this was changed with 5.9).

As for stripping the HTML, we could put something in, but I get the feeling that it was project specific. When I pulled down the most recent code on it, it was no longer an issue due to some added conditionals checking for REST requests from the filter that introduced that additional markup. If we're OK with that being a project specific bug, we may be able to close.

[fabiankaegy]

@Firestorm980 I took a look at this also and as not able to replicate it on a current clean setup. I'm going to close if for now. Feel free to reopen if you ever encounter it again.