Unable to reproduce this issue on reported version 64.0.3282.140 on Mac 10.13.3 with below steps.

1. Navigated to https://en.wikipedia.org/wiki/Main_Page >> Opened devtools coverage tab and started recording. -- observed unused bytes tab
2. Now clicked on Arts link in same page -- observed different number in unused bytes for css files.
3. Now clicked on History section in same page and observed different values. Attaching screencasts of both M-60 and M-64 behaviors.

@Reporter: Could you please check the video and let us know if we miss anything. Also please elaborate the expected and Actual behaviors with video if possible. This would help in triaging the issue in a better way.

Thanks!

Deleted: 811983 in M60.mp4 4.2 MB

	811983 in M60.mp4 4.2 MB View Download

Deleted: 811983 in M64.mp4 5.4 MB

	811983 in M64.mp4 5.4 MB View Download

Ok, I'm attaching a video now. Here's what happens in the video:

1) I'm on reddit.com and I press refresh/record in the devtools coverage tab. On page load, it shows 307171 bytes of unused CSS in the file https://www.redditstatic.com
/reddit.54jL119pPdI.css. I click on the "report" button, which then creates more dom nodes that then use more CSS selectors, which reduces the unused bytes of CSS from 307171 to 286152.
2) After closing the report modal I had opened, I then navigate to the comments section of the first front page link. This page also uses the same CSS file, https://www.redditstatic.com
/reddit.54jL119pPdI.css. It shows 298044 bytes of unused CSS in this file. Already there is a problem. If the tool were recording across page views, the unused CSS for this file would be at most 286152 (the value from the previous page), but now it has jumped up to 298044.
3) I then navigate back to the first page, the reddit.com root. Now the same CSS file shows 307229 bytes of unused code. Again, it should be 286152 at most, because that's what it was early in the recording process. [What I forgot to show in the video is one additional step. I click on the record button to stop recording, and the unused code for that CSS file stays at 307229]

What seems to be happening is that Coverage is recording (as shown in step 1, when I click the report button on the page), but that any time you navigate to a new page, the old recording is destroyed and a fresh recording begins. This does not seem to be same as the behavior of the coverage tool when it was released in Chrome 59. In Chrome 59, when you clicked to stop recording, it would show you all the CSS and JS files you encountered across pageviews, and it was smart enough to combine its results for a CSS/JS file that was the same on both pages.

This makes the tool much less useful for me in my current job, as I have some CSS files that are used in multiple pages, and it would be very helpful for me to be able to see which CSS code isn't being used at all by recording a runthrough of the site and looking at the results. This isn't possible when Coverage recording resets on each new page load. 

I understand that it would be best for me to serve the minimum CSS possible on a per-page basis and have only page-specific CSS (which the tool is still useful for), but given the current architecture of the website I'm working on, that's not easy to do yet, and if I can kill all the code first that is NEVER used, then I can start moving towards separating CSS into page-specific files. Recording coverage across page views would be a big help in killing that never-used code.

Additionally, it would be amazing if I could export the results of a Coverage recording into a file. That's a feature request <3.

N.B. I made some mistakes in my initial bug report. 1) In my hypothetical example where I say "at LEAST 5kb", I should have said "at MOST 5kb". 2) when I said "does the record button actually do anything?" I wasn't thinking about things correctly, so you can disregard that.

Deleted: devtoolscoverage3.mp4 3.4 MB

	devtoolscoverage3.mp4 3.4 MB View Download

Thank you for providing more feedback. Adding requester "sindhu.chelamcherla@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As per comment#3, rechecked the issue on M-59 builds and coverage analysis is different there. Till 60.0.3091.0 we are getting analysis only after ending the recording. But from 60.0.3093.0 to latest M-66 coverage analysis changes as mentioned in comment#0 and comment#3. Hence this issue is reproducible on reported version 64.0.3282.140, latest beta 65.0.3325.51 and latest canary 66.0.3347.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

Good Build: 60.0.3091.0
Bad Build: 60.0.3093.0

Unable to provide per-revision bisect as we are seeing "[Errno 2] No such file or directory" error. Hence providing chromium bisect.

You are probably looking for a change made after 469843 (known good), but no later than 469887 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/ce36c5acc6e27a75e8fa455c92277de713922ac0..3ba7b83974443ba8324d704117743c7ae463d4ed

Suspecting https://codereview.chromium.org/2865573003 from changelog.

@caseq: As per changelog this seems to be intended. Please check the above comments and help in triaging this further.

Thanks!

I can repro this.

 Issue 876475  has been merged into this issue.