Suggest label over text

[kentcdodds]

Relevant code or config:

<div
  id="foo-123"
  aria-labelledby="foo-label"
> ... </div>
<label
  id="foo-label"
  for="foo-123"
>Foobar</label>

What you did:

Tried this in the Testing Playground: https://testing-playground.com/?markup=DwEwlgbgBGILwCIBmB7FBaAjAJgMwKgEMAnMQ9AG0ICMBTCi2kagT0VQyrooQD4oAdEKjAA9OAi8AUMC70Y8ZGko16BVMXbKc%2BXgDE01EmLkVeQA&query=M4YwTgphB2B0DmEAuAhAngGQIYCMIBsAVCADyQAoB6AMwHtacsxKBLASiA

What happened:

It recommends screen.getByText even though screen.getByLabelText works and should be preferred... I think.

[eps1lon]

In case this is the actual markup: Why do you want to label a generic <div /> and why do you use a label element for that?

[kentcdodds]

I got it from another person's issue and when I was showing them how to get a label to label the div I noticed this. I wouldn't recommend this, but it does seem incorrect I think.

[winterlamon]

@kentcdodds Would you consider this the correct usage in a situation where the <div> is wrapping a custom input--for example, a custom range slider--that has a text label?

[kentcdodds]

I think so, though there's a lot more that goes into making something like that accessible, but yeah, I think this is how you'd label it.

[marcosvega91]

This is a bug of testing-playground I'll move the issue there. suggestedQuery is returning the right query (getByLabelText). It seams a problem of the parser

[kentcdodds]

I think you're misreading what it's saying. What's on the left is not the suggested query. It's the code you're executing. If you change it to use getByText instead then the right side will go green for you :)

[marcosvega91]

Yes i know but the left side is autocompleted when you click on the dom element.

When you click, both right and left side are populated with suggested query taken from @testing-library/dom but the right is correct and the left is incorrect

[smeijer]

@marcosvega91 is correct. Something went wrong here.

At this moment, suggestion data comes from two sources;

1. The sandbox. The preview pane acts as a sandbox. It's an iframe with some sandbox restrictions, to block a script from escaping the iframe and inject code in the window & force a redirect to a malicious domain.

2. An in-memory frame (document.createElement('iframe')) that's never added to the DOM. This was an experiment at some moment because I thought it would be nice to run the queries in memory, without needing to add it to the DOM / create a visible element. This would also prevent malicious scripts from updating the real document.

   It turned out that this is hard! (And that's why we changed to 1.) The @testing-library/dom query results change, and thereby the suggestions changed as well. I guess it has to do with the "visibility/accessibility checks", so it is by design. But it's something I didn't foresee in the past. Or at least, I thought I solved the problems. But this ticket is proof that I missed some.

So what's happening here (screenshot above), is that the query editor gets it's data from the preview pane, while the suggestion pane runs something in the in-memory frame.

An update is on the way though. I expect to merge today or tomorrow. I've refactored some code so that all suggestions will get a single source of truth, that is the suggestion from @testing-library/dom, which is evaluated in the preview pane.

This is the closest as we can get to a real-world scenario. And also closes the gaps in behavior differences between devtool and web version. (Devtool runs against document.body)

[smeijer]

I expect to merge today or tomorrow.

Turns out, it was today. Production has been updated.