Currently, TelemetryEnvironment calls into XPCOM methods that perform main-thread I/O to collect configuration info such as the DirectWrite version. This is undesirable since it causes main thread jank. We will likely add additional measurements which require file I/O. Telemetry should be either 1) fetching these measurements itself, off the main thread (using use a PromiseWorker & ctypes) or 2) the underlying code should be refactored to fetch the data off the main thread and return the data asynchronously.

There's a couple of other options: 3) put the file-reading functionality in C++ and expose it to a PromiserWorker via WebIDL instead of using ctypes, and 4) extend AsyncFetchTelemetryData to return this info. I'll leave the decision up to the implementer.

We temporarily removed DWriteVersion in bug 1137404 to fix the perf hit, we want to readd that after fixing this here.

Was this a problem because it was happening during startup, or would it be a lesser problem if it was to happen (the same, main thread i/o blocking way) some time after the startup?

We don't want any heavy stuff on the main thread (unless we know the browser is idle -- but we can't rely on that here). We especially don't want heavy stuff on the main thread during startup (i.e. a critical path).

Hi Georg, I would like to take up this bug. Can yo please provide me some pointers?

I don't think this makes for a good starter bug, lets check for other mentored bugs.