1179045 - desktop runtime browser debugger chrome test failing because chromeDebugger, consoleActor, profilerActor properties of tablist are missing

Status: RESOLVED FIXED

(Firefox Graveyard :: Webapp Runtime, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

Attachment: stop checking for chromeDebugger, consoleActor, profilerActor properties

The browser debugger chrome test is failing because the properties of the tablist object that the client gets from the server have changed, and they no longer include chromeDebugger, consoleActor, profilerActor, which it expects.

I'm not sure why this is happening, since those properties are still listed in volcan.js as "specializations" of the "tablist" type that listTabs returns.  Perhaps it's a bug.  Or perhaps the DevTools code has changed in some intentional way to exclude those properties.

Here's a patch that optimistically removes checks for those properties, assuming they're no longer supposed to be present.  Requesting review from Marco for the code change and Feedback from Joe Walker, who can hopefully redirect the request to the right person on his team (or within DevTools generally) to tell us if this is the right thing to do!

Comment 1

[Myk Melez [:myk] [@mykmelez]]

This shouldn't affect any tests that run in continuous integration, but here's a try run for mochitest-other on the off chance that there's a toolkit/webapps/ test affected by this change:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a703fe170da

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 8628019 [details] [diff] [review]
stop checking for chromeDebugger, consoleActor, profilerActor properties

past just replied to a question I asked about this issue in IRC:

12:25:06 AM - past: myk: the protocol has changed a bit and in order to access the global-scoped actors the client needs to send a getProcess request first
12:25:37 AM - past: instead of relying on the global-scoped actors being present in the getTabs response

So the change to simply remove the three property checks is reasonable, since here we only want to test that the remote debugger server is running and responds to queries.  It isn't particularly useful to test that the response looks precisely a certain way (and in fact can be harmful, since it makes the test more brittle and prone to failure, as in this case).

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0470aed61cdb

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0470aed61cdb