I think defaulting the service worker logging to show up in web console is closer to what developers expect. For example, see bug 1201953.

To be clear, you are talking about changing the default value of the Service Workers option in the Logging dropdown inside the webconsole? What do you think about Shared Workers, should that stay off by default?

One thing I've noticed with the existing Service Worker logging is that objects are stringified, so if I log console.log("ServiceWorker initialized", this); from the Service Worker, then in the console I end up seeing: "ServiceWorker initialized [object ServiceWorkerGlobalScope]" Still, that seems like a different bug and I think having logs show up by default makes sense.

(In reply to Brian Grinstead [:bgrins] from comment #1) > To be clear, you are talking about changing the default value of the Service > Workers option in the Logging dropdown inside the webconsole? Yes. > What do you think about Shared Workers, should that stay off by default? Sounds good to me. SharedWorker is not used much, so I can't see it causing a problem. Thanks.

Bug 1201962 - Enable service worker logging in web console by default;r=ejpbruel

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0d83ac9eed23

Comment on attachment 8672695 [details] MozReview Request: Bug 1201962 - Enable service worker logging in web console by default;r=ejpbruel Sorry for the relatively long review turnover despite this being a trivial patch. I was in Berlin this week, and thus somewhat distracted.

(In reply to Eddy Bruel [:ejpbruel] from comment #6) > Comment on attachment 8672695 [details] > MozReview Request: Bug 1201962 - Enable service worker logging in web > console by default;r=ejpbruel > > Sorry for the relatively long review turnover despite this being a trivial > patch. I was in Berlin this week, and thus somewhat distracted. No problem. I'm now wondering if we should wait to land this until Bug 1213932 is sorted out though.

I would prefer not to wait for bug 1213932. I think you are likely just observing the service worker life cycle being managed by the browser. I commented over in that bug.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2306217f454f. I think with Bug 1222617 on fx-team, this should be able to land if that turns up green, since that's the last really confusing part of viewing SW logs from the tab's console. I believe Bug 1226061 (potential weirdness on getCachedMessages on pages with frames that are controlled by a SW) is not a blocker here, since it's a limited scenario.

Marking as blocking v1 purely for tracking purposes.

Comment on attachment 8672695 [details] MozReview Request: Bug 1201962 - Enable service worker logging in web console by default;r=ejpbruel Approval Request Comment [Feature/regressing bug #]: Service workers (bug 1059784) [User impact if declined]: Messages originating from a service worker will not show up in tabs they control by default (user needs to check an option in the webconsole UI to see them). [Describe test coverage new/current, TreeHerder]: Tests for service worker logging have been added in the blocking bugs which are either on 44 or are being requested for uplift at same time. Primary tests are devtools/shared/webconsole/test/test_console_serviceworker.html and devtools/shared/webconsole/test/test_console_serviceworker_cached.html [Risks and why]: Service worker logging still has some bugs, particularly with object inspection (bug 1215120) and detecting if a message matches the page in certain cases (bug 1221772 and 1226061). Although since we're planning to ship service workers in 44, getting useful logging that works in most cases is important. [String/UUID change made/needed]:

Comment on attachment 8672695 [details] MozReview Request: Bug 1201962 - Enable service worker logging in web console by default;r=ejpbruel This is just a pref change. SW is planned for 44, taking it.