Closed Bug 1472145 Opened 3 years ago Closed 3 years ago

Add telemetry to determine how frequently WebP content is incorrectly served


(Core :: ImageLib, enhancement, P3)




Tracking Status
firefox63 --- fixed


(Reporter: aosmond, Assigned: aosmond)



(Whiteboard: [gfx-noted])


(5 files)

There are a number of webcompat issues filed against bug 1294490. I would like to get a sense of how many users this is affecting today. I assume it is predominantly Fennec where websites incorrectly assume Android implies WebP support.
Assignee: nobody → aosmond
Priority: -- → P3
Whiteboard: [gfx-noted]
See Also: → WebP
chutten, FYI I want to collect this for both desktop and fennec, although I expect fennec is where the bulk of the useful data is, given the webcompat issues filed all seem to be against it.
Attachment #8988830 - Flags: review?(chutten)
Comment on attachment 8988830 [details]
Request for data collection.txt, v1


    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. Standard Telemetry mechanisms apply.

    Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. Standard Telemetry mechanisms apply.

    If the request is for permanent data collection, is there someone who will monitor the data over time?**

N/A expires in 65 (last version with recordings will be 64)

    Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under? **

Category 1 (theoretically category 2 since we record the _number_ of images loaded, but that's almost a technical detail in today's web so *shrug*)

    Is the data collection request for default-on or default-off?

Default on.

    Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

It introduces the two strings "webp" and "other". These are just category labels.

    Is the data collection covered by the existing Firefox privacy notice? 


    Does there need to be a check-in in the future to determine whether to renew the data?

Yes. :aosmond is responsible for evaluating whether to renew or remove this collection before it expires at the end of Firefox 64.

Result: datareview+
Attachment #8988830 - Flags: review?(chutten) → review+
Firefox for Android and Firefox on Desktop both fall under the Firefox Privacy Notice, so collection against either is handled the same way :)
Attachment #8988816 - Flags: review?(tnikkel) → review+
Attachment #8988817 - Flags: review?(tnikkel) → review+
Pushed by
Part 1. Add support for identifying the WebP images MIME type. r=tnikkel
Part 2. Add telemetry to track how frequently WebP images are used. r=tnikkel data-r=chutten
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Pushed by
Part 3. Initialize boolean WebP telemetry scalars to ensure accurate reporting. r=aosmond
I would very much like to uplift these two patches to beta. Otherwise we won't have any Android numbers until mid fall due to how few nightly users there are on Android.

Attachment #8991589 - Flags: review+
Just ran into this new ebook from Smashing Magazine:

Looks like FF still isn't supporting WebP:

Any ETA when it will come bundled by default in FF (desktop & mobile)?
(In reply to Mike Gifford from comment #13)
> Just ran into this new ebook from Smashing Magazine:
> Looks like FF still isn't supporting WebP:
> Any ETA when it will come bundled by default in FF (desktop & mobile)?

This bug just added some telemetry probes to collect some data on how frequently Firefox users are encountering WebP. No implementation support for WebP. Currently only data is showing on for desktop, but what I'm really hoping for are numbers on Android to help our decision making.
Why there aren't any data from Android?

I personaly install the last Firefox nightly on Android on 2018/07/25 and I navigate to

Show it should be any data by now.
You need to log in before you can comment on or make changes to this bug.