GoogleChromeLabs / chromium-bidi

Implementation of WebDriver BiDi for Chromium
https://googlechromelabs.github.io/chromium-bidi/
Apache License 2.0
89 stars 30 forks source link

BiDi+ reports incorrect Coverage data #896

Open Lightning00Blade opened 1 year ago

Lightning00Blade commented 1 year ago

When we try to use coverage in Puppeteer with BiDi+ we get extra reports as Mapper run some Script evaluation serializeCdpObject and stringifyObject. In Puppeteer we get around that by using a source comment and after tracing remove the //# sourceURL=pptr:internal A solution would be add something similar to this in Mapper and deal with the url on Puppeteer side.

Verified it work with Puppeteer if we have:

            functionDeclaration: String((obj) => {
                return String(obj);
            }) + '\n//# sourceURL=pptr:internal',
thiagowfx commented 1 year ago

This seems to be a Puppeteer issue. BiDi+ should be treated as a blackbox from its perspective.

Either way: We don't really use coverage in this repository (at least so far).

x-ref: https://github.com/GoogleChromeLabs/chromium-bidi/issues/17

Lightning00Blade commented 1 year ago

That exactly the case the problem is Mapper is creating a side affect that affects Coverage. It shouldn't do that or there should be a way to distinguish it.

PS: x-ref: https://github.com/GoogleChromeLabs/chromium-bidi/issues/17 is not relevant as its related to repository coverage and not Profiler.startPreciseCoverage or CSS.startRuleUsageTracking

Lightning00Blade commented 1 year ago

Should be solved by #1213.

thiagowfx commented 1 year ago

Do you want to close this bug as a duplicate then?

Lightning00Blade commented 1 year ago

We need to keep it. We may need to do more things to fix in all scenarios, and given its its own separate issue, its better practice imo to keep both, even if the root cause may be fixed with 1 change.