Bugzilla

### Patch updated

The most recent test run is up at https://asuth.searchfox.org/.  My summary of key changes from #searchfox on chat.mozilla.org was:
- The coverage is now to the left of the blame bar, fixed width.
- When not hovered, coverage hits/misses are interpolated in order to reduce visual noise from transitions between uncovered lines and hits/misses.
- When hovered, it's assumed you would appreciate more detail and so we drop the interpolation; uncovered lines don't get colored. I also opted to go with a log scale for hits. Lines that get hit a lot will have increasingly darker blues in the scale.
- The accessibility changes in terms of aria-label have been implemented for both coverage and blame but I ran into bug 1668701 which is independent of my changes here when testing with NVDA.  I do still need to make it possible to use the enter key to toggle the popups off.  (That's also a pre-existing issue that's somewhat self-mooting since you can only ever have one popup up at a time, but it should be simple to fix.)

### Disk Usage
Disk usage slightly increased.  Unfortunately though we have 110G spare on "release" config.json before the patch and 102G after the patch, pre-patch we only have 19G spare on "mozilla-releases.json" which is not a sufficiently comfortable buffer so I'm going to try and get to bug 1631466 soon because it seems likely to be an easy win.  For example, the ServiceWorkerPrivate.cpp file I've been using as an example is 1.9M HTML post-patch uncompressed and gzip with default settings dropped that to 140K and brotli defaults hit 80K.  Using brotli_static the server can decompress for clients that don't report `Accept-Encoding: br`.  The question is whether it's worth also storing gzip-encoded versions as well so that an accept-encoding header that includes gzip but not br gets a similarly preocmputed experience.  We don't currently log that header in our logs, so we don't know, but my guess would be it's not an optimal use of resources (although we could enable it to cache dynamically re-encoded gzips if needed).

Indexed dirs, with pre-patch and post-patch values:
- comm-central: 40G increased to 43G
- ecma262: 140M increased to 145M
- glean: 572M increased to 579M
- kaios: 49G increased to 52G
- mozilla-build: 1.8G stayed 1.8G
- mozilla-central: 68G increased to 70G
- mozilla-mobile: 3.8G increased to 4.0G
- nss: 4.1G increased to 4.3G
- version-control-tools: 196M increased to 210M
- whatwg-html: 3.5G increased to 3.6G

1: We had 110G spare on the "release" config.json

### Patch updated

The most recent test run is up at https://asuth.searchfox.org/.  My summary of key changes from #searchfox on chat.mozilla.org was:
- The coverage is now to the left of the blame bar, fixed width.
- When not hovered, coverage hits/misses are interpolated in order to reduce visual noise from transitions between uncovered lines and hits/misses.
- When hovered, it's assumed you would appreciate more detail and so we drop the interpolation; uncovered lines don't get colored. I also opted to go with a log scale for hits. Lines that get hit a lot will have increasingly darker blues in the scale.
- The accessibility changes in terms of aria-label have been implemented for both coverage and blame but I ran into bug 1668701 which is independent of my changes here when testing with NVDA.  I do still need to make it possible to use the enter key to toggle the popups off.  (That's also a pre-existing issue that's somewhat self-mooting since you can only ever have one popup up at a time, but it should be simple to fix.)

### Disk Usage
Disk usage slightly increased.  Unfortunately though we have 110G spare on "release" config.json before the patch and 102G after the patch, pre-patch we only have 19G spare on "mozilla-releases.json" which is not a sufficiently comfortable buffer so I'm going to try and get to bug 1631466 soon because it seems likely to be an easy win.  For example, the ServiceWorkerPrivate.cpp file I've been using as an example is 1.9M HTML post-patch uncompressed and gzip with default settings dropped that to 140K and brotli defaults hit 80K.  Using brotli_static the server can decompress for clients that don't report `Accept-Encoding: br`.  The question is whether it's worth also storing gzip-encoded versions as well so that an accept-encoding header that includes gzip but not br gets a similarly preocmputed experience.  We don't currently log that header in our logs, so we don't know, but my guess would be it's not an optimal use of resources (although we could enable it to cache dynamically re-encoded gzips if needed).

Indexed dirs, with pre-patch and post-patch values:
- comm-central: 40G increased to 43G
- ecma262: 140M increased to 145M
- glean: 572M increased to 579M
- kaios: 49G increased to 52G
- mozilla-build: 1.8G stayed 1.8G
- mozilla-central: 68G increased to 70G
- mozilla-mobile: 3.8G increased to 4.0G
- nss: 4.1G increased to 4.3G
- version-control-tools: 196M increased to 210M
- whatwg-html: 3.5G increased to 3.6G

### Patch updated

The most recent test run is up at https://asuth.searchfox.org/.  My summary of key changes from #searchfox on chat.mozilla.org was:
- The coverage is now to the left of the blame bar, fixed width.
- When not hovered, coverage hits/misses are interpolated in order to reduce visual noise from transitions between uncovered lines and hits/misses.
- When hovered, it's assumed you would appreciate more detail and so we drop the interpolation; uncovered lines don't get colored. I also opted to go with a log scale for hits. Lines that get hit a lot will have increasingly darker blues in the scale.
- The accessibility changes in terms of aria-label have been implemented for both coverage and blame but I ran into bug 1668701 which is independent of my changes here when testing with NVDA.  I do still need to make it possible to use the enter key to toggle the popups off.  (That's also a pre-existing issue that's somewhat self-mooting since you can only ever have one popup up at a time, but it should be simple to fix.)

### Disk Usage
Disk usage slightly increased.  Unfortunately though we have 110G spare on "release" config.json before the patch and 102G after the patch, pre-patch we only have 19G spare on "mozilla-releases.json" which is not a sufficiently comfortable buffer so I'm going to try and get to bug 1631466 soon because it seems likely to be an easy win.  For example, the ServiceWorkerPrivate.cpp file I've been using as an example is 1.9M HTML post-patch uncompressed and gzip with default settings dropped that to 140K and brotli defaults hit 80K.  Using brotli_static the server can decompress for clients that don't report `Accept-Encoding: br`.  The question is whether it's worth also storing gzip-encoded versions as well so that an accept-encoding header that includes gzip but not br gets a similarly precomputed experience.  We don't currently log that header in our logs, so we don't know, but my guess would be it's not an optimal use of resources (although we could enable it to cache dynamically re-encoded gzips if needed).

Indexed dirs, with pre-patch and post-patch values:
- comm-central: 40G increased to 43G
- ecma262: 140M increased to 145M
- glean: 572M increased to 579M
- kaios: 49G increased to 52G
- mozilla-build: 1.8G stayed 1.8G
- mozilla-central: 68G increased to 70G
- mozilla-mobile: 3.8G increased to 4.0G
- nss: 4.1G increased to 4.3G
- version-control-tools: 196M increased to 210M
- whatwg-html: 3.5G increased to 3.6G