Bugzilla

This is one of those: "devtools could technically do this right now without ServiceWorker backend changes, but the right thing is a ServiceWorker backend change".

I think the syntax errors are getting emitted in the parent process right now as a ConsoleEvent by [ConsoleUtils::ReportForServiceWorkerScopeInternal](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/console/ConsoleUtils.cpp#55) and are emitting stuff to "@mozilla.org/consoleAPI-storage;1" with an inner window ID of "ServiceWorker" and an outer window ID of the ServiceWorker scope.

I see handling for this case in [ConsoleAPIListener.isMessageRelevant](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/devtools/server/actors/webconsole/listeners/console-api.js#120).

I assume the situation is that this worked under child-intercept because the ServiceWorkerManager emitting the console message, the listening actor, and the window lived in the same process.  Now the ServiceWorkerManager and the console message live in the parent and the listening actor and its window live in a content process.  Unless the devtools actors are propagating the messages?

It seems like the place where the semantics mismatch is happening is at [ServiceWorkerManager::ReportToAllClients](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/serviceworkers/ServiceWorkerManager.cpp#1406).  Under parent-intercept, the thing ServiceWorkers should be doing is should be finding all the matching clients and sending the error down to them where they can report it in their process.  This seems appropriate given the idea that a user should be able to open devtools after a bad thing has happened and see the bad thing.  This would presumably require no devtools changes, although I haven't 100% processed what's going on.

I think we probably also need to add test coverage, as it's likely we don't have it and that's how we missed it as part of the sw-e10s devtools steps.

Unfortunately, given the imminent holidays, this might not something that makes 73 unless it gets uplifted early in the cycle.

This is one of those: "devtools could technically do this right now without ServiceWorker backend changes, but the right thing is a ServiceWorker backend change".

I think the syntax errors are getting emitted in the parent process right now as a ConsoleEvent by [ConsoleUtils::ReportForServiceWorkerScopeInternal](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/console/ConsoleUtils.cpp#55) and are emitting stuff to "@mozilla.org/consoleAPI-storage;1" with an inner window ID of "ServiceWorker" and an outer window ID of the ServiceWorker scope.

I see handling for this case in [ConsoleAPIListener.isMessageRelevant](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/devtools/server/actors/webconsole/listeners/console-api.js#120).

I assume the situation is that this worked under child-intercept because the ServiceWorkerManager emitting the console message, the listening actor, and the window lived in the same process.  Now the ServiceWorkerManager and the console message live in the parent and the listening actor and its window live in a content process.  Unless the devtools actors are propagating the messages?

It seems like the place where the semantics mismatch is happening is at [ServiceWorkerManager::ReportToAllClients](https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/serviceworkers/ServiceWorkerManager.cpp#1406).  Under parent-intercept, the thing ServiceWorkers should be doing is should be finding all the matching clients and sending the error down to them where they can report it in their process.  This seems appropriate given the idea that a user should be able to open devtools after a bad thing has happened and see the bad thing.  This would presumably require no devtools changes, although I haven't 100% processed what's going on.

I think we probably also need to add test coverage, as it's likely we don't have it and that's how we missed it as part of the sw-e10s devtools steps.

Unfortunately, given the imminent holidays, this might not make it into 73 unless it gets uplifted early in the cycle.