DOM APIs UseCounter should work on web workers
Categories
(Core :: DOM: Core & HTML, enhancement, P2)
Tracking
()
People
(Reporter: nsm, Assigned: edgar)
References
(Blocks 2 open bugs)
Details
Attachments
(5 files, 1 obsolete file)
Updated•6 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
•
|
||
Bug 1410468 is for the Javascript telemetry on workers, this bug is for DOM API use counters on workers.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Liz, we've worked with Product team to put this into Q4 plan. We probably won't make it in 70.
Comment 4•5 years ago
|
||
OK, thanks for letting me know.
Comment 6•5 years ago
|
||
After we're done with other Fission work, we can be switch to this work.
Assignee | ||
Comment 7•5 years ago
|
||
For the DOM APIs use counters on window, we have:
USE_COUNTER2_*_DOCUMENT
andUSE_COUNTER2_*_PAGE
: to record the APIs usages of documents and pages.CONTENT_DOCUMENTS_DESTROYED
.CONTENT_DOCUMENTS_DESTROYED
andTOP_LEVEL_CONTENT_DOCUMENTS_DESTROYED
: telemetry uses as the denominator.
For the use counters on worker, IMHO, we should have separated data for different types of worker, so I plan to add:
USE_COUNTER2_*_DEDICATEDWORKER
,USE_COUNTER2_*_SHAREDWORKER
andUSE_COUNTER2_*_SERVICEWORKER
: the APIs usage for each type of worker.DEDICATEDWORKER_DESTROYED
,SHAREDWORKER_DESTROYED
andSERVICEWORKER_DESTROYED
: As the denominator.
But if we think it is not necessary to distinguish the worker type, then we could just add USE_COUNTER2_*_WORKER
and WORKER_DESTROYED
. What do you think? Thanks.
Comment 8•5 years ago
|
||
Not really my code, but in general I think gathering more specific information is better than less specific information. So we should have separate sets of use counters for each worker type, IMHO.
Comment 9•5 years ago
|
||
I'd prefer separate counters by worker type, yes, as long as it does not slow down the bindings code too much.
Comment 10•5 years ago
|
||
Sorry for the slow response. I don't understand workers deeply but the thing that I think would be interesting to understand for webcompat is how many pages use workers that used a given API, for the kinds of workers (if any?) that are controlled by a single page. Is that reasonable?
Assignee | ||
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
Assignee | ||
Comment 13•5 years ago
|
||
Assignee | ||
Comment 14•5 years ago
|
||
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
•
|
||
Assignee | ||
Comment 17•5 years ago
|
||
(In reply to Tim Smith 👨🔬 [:tdsmith] from comment #10)
Sorry for the slow response. I don't understand workers deeply but the thing that I think would be interesting to understand for webcompat is how many pages use workers that used a given API, for the kinds of workers (if any?) that are controlled by a single page. Is that reasonable?
Yes, I think it is reasonable to record such information for the worker that is controlled by a single page, i.e dedicated worker. Especially if a page creates a lot of workers that use a given API, we could have a more accurate overview from page points of view.
Assignee | ||
Comment 18•5 years ago
|
||
Hi chutten, would you mind also take a look at the telemetry changes in part1 patch? Thank you.
Assignee | ||
Comment 19•5 years ago
|
||
Assignee | ||
Comment 20•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 21•5 years ago
|
||
Updated•5 years ago
|
Comment 22•5 years ago
|
||
Thanks!
Comment 23•5 years ago
|
||
Comment 24•5 years ago
|
||
Comment 25•5 years ago
|
||
Backed out 4 changesets (bug 1202706) for causing mochitest assertion failures on BindingUtils.cpp
Backout revision https://hg.mozilla.org/integration/autoland/rev/936f60dbf17552cf8aa929caca86774d211d9877
Failure logs: for 11 https://treeherder.mozilla.org/logviewer.html#?job_id=278523060&repo=autoland
for 7 https://treeherder.mozilla.org/logviewer.html#?job_id=278528057&repo=autoland
Edgar can you please take a look?
Assignee | ||
Comment 26•5 years ago
|
||
Comment 27•5 years ago
|
||
I confirmed with Webcompat and metrics team that it's good to let this bug ride the train from the nightly after 72 softfreeze.
Should we just move the firefox71-status to wontfix and 72-status to fixoptional?
Updated•5 years ago
|
Updated•5 years ago
|
Comment 28•5 years ago
|
||
Comment 29•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4989bb2f4f69
https://hg.mozilla.org/mozilla-central/rev/9eeb03a503fb
https://hg.mozilla.org/mozilla-central/rev/95b8b6b94213
https://hg.mozilla.org/mozilla-central/rev/2dfc53add3de
Updated•5 years ago
|
Description
•