search

testing-library / testing-playground

Simple and complete DOM testing playground that encourage good testing practices.
https://testing-playground.com
MIT License
783 stars 62 forks source link

contentScript.js: Element is inaccessible. #330

Closed mateuszpigula-sp closed 3 years ago

mateuszpigula-sp commented 3 years ago

Bug Report 🐛

image

I see a mentioned warning which weights down the browser. How do I know extension causes the problem? I turned off all extensions => no warning, turned on only Testing Library => warning

To Reproduce ✔️

I have a problem with this as it happens really independently. I hope someone has the same problem (or solution).

Expected behavior 🤔

No warning, no slowing down the browser.

Your Environment 💻

--- Edit --- Funny, I just updated Chrome to Version 88.0.4324.182, and no warning but I am not removing this ticket if anyone has the same problem.

smeijer commented 3 years ago

Without steps to reproduce, and a "resolved problem" by updating your browser, I don't see what I can do about this.

So I'm closing this ticket for the time being. But I'm happy to reopen when someone can provide me the "steps to reproduce".

Thanks for filing the issue.

kentcdodds commented 3 years ago

I'm seeing this as well. I've seen it on a bunch of sites. This was the latest one: https://www.prisma.io/docs/concepts/components/prisma-client/relation-queries

I'm not actively using Testing Playground on that page so I wouldn't expect to get any warnings or anything.

smeijer commented 3 years ago

I guess we didn't hold off with the dom-testing-library update :sweat_smile: https://github.com/testing-library/dom-testing-library/issues/785

I've pushed a new version to the chrome store that silences the console.warn by stubbing it out (9efc41a18a9b06e15c19e12c82028c8c30cdadd9). We might be able to fix this in a better way once https://github.com/testing-library/dom-testing-library/pull/950 has been merged.

smeijer commented 3 years ago

It does bother me that it logs errors during page load, as it shouldn't be doing anything at that time. I'll take a look at that later.

Leaving a note for future work, as it's 2:10 AM here, and I'm closing down.

It's a bit weird and hard to debug, as the problem doesn't always occur. BUT..., the log statement seems to be printed because Chrome selects the body element when opening the devtools or loading a page while having the devools open (I'm not sure yet).

That selection triggers the onSelectionChanged in the contentScript, which rightfully checks for the best queries to populate the suggestions in the SidePanel at the Elements tab.

https://github.com/testing-library/testing-playground/blob/9efc41a18a9b06e15c19e12c82028c8c30cdadd9/devtools/src/content-script/contentScript.js#L66-L68

2:30 AM - Need more debugging, even tho there is only 1 selection event, there are multiple warnings:

image

I've logged the elements, and it seems that basically every inaccessible element is logged. In case of the Google home page, it might get caused by the dialog overlay? Again, not sure yet. I'll update this as more info comes.

smeijer commented 3 years ago

GOT IT!

It's a single selection, but it's directly on the <body> element. And :drum: ... all selections also trigger the getSnapshot method, here:

https://github.com/testing-library/testing-playground/blob/171f367195ef0f9adadc6685882deb36a366daa2/src/lib/queryAdvise.js#L119

If the document is large, that might become an expensive operation. Hence the slowing down of the browser from OP.

Problem found. Now onto the solution, but not this night. Signing off :grimacing:

smeijer commented 3 years ago

I've shipped a second update, fixing the underlying issue (059963046844645aa9a910e8e013f07bbc902bfb). Thanks for reporting this problem! It had a bigger impact than I at first expected.

kentcdodds commented 3 years ago

Sweet!