Cannot attach two devtools sessions to same pag/tab

[SahidMiller]

I'm not able to connect two devtools sessions using crmux.

Starting up a chrome session using the arguments chrome --remote-debugging-port=9222 --user-data-dir=Default or Brackets IDE LivePreview.

I'm able to connect to one using localhost:9223, but unable to connect again to the same tab using either another connection through localhost:9223, localhost:9222, Chrome Devtools App, or opening devtools on the page itself.

Maybe I was under the wrong impression on the functionality of the multiplexer?

To help, my end goal was to be able to be able to use another debugger while still using Brackets IDE LivePreview functionality.

[sidorares]

hi @SahidMiller ,
yes, crmux is intended to allow multiple clients to connect single Chrome Devtools protocol server. I haven't used it for a while so there might be some new incompatibilities

but unable to connect again to the same tab using either another connection through localhost:9223

could you describe exactly the steps you performed and results you see ( error logs or anything )? I never used it together with Brackets so not sure if there is anything special in related to how Brackets is using chrome connection

[SahidMiller]

Hi, thanks for the quick response @sidorares. The brackets thing is just my end goal, no need to worry about that.

The basic test I'm running is launching chrome with the following args --remote-debugging-port=9222 --user-data-dir=Default then launch crmux right after.
Then from another browser, I open two tabs to localhost:9223, the port crmux opens/listens.

From here I can use one of these to connect to any tab and debug But I cannot open a second to that same tab.

It behaves exactly the same as it would if I weren't using crmux at all, graying out and not being able to select the same tab. I've tried other means to connect like using chrome devtools app or opening a debugger right there in that tab, but either it disconnects the previous session or doesn't connect at all.

[SahidMiller]

Hm, The problem seems to be that when the tab is already in use, it doesn't return back a web webSocketDebuggerUrl which chrome-remote-interface is expecting.

[SahidMiller]

Actually think I found a fix, just used the cachedWsUrls list to modify the tabs returned for the second list. It works so far for connecting, but I'm not sure about other functionality.

EDIT: Didn't mean to close it but that works. Here's the code

        if(req.url == '/json/list'){
          upRes.on('data', function(data){
              console.log('getting data');
              if(data){
                  console.log(data);
                  var tabs = JSON.parse(data);
                  console.log(tabs);
                  tabs.map((tab) => { 
                      if(cachedWsUrls[tab.id]){
                          tab.webSocketDebuggerUrl = cachedWsUrls[tab.id].replace('9222', '9223');
                      }                                
                  });
                  res.write(JSON.stringify(tabs));
                  upRes.pipe(res);
              } else {
                  upRes.pipe(res);
              }
          });
        }else {
            upRes.pipe(res);
        }

`

Replace the body of the request callback in crmux.js Line:~65

[sidorares]

Thanks for looking into this @SahidMiller !
Would you be able to submit a pr with your changes?

Yes, because chrome only allows one debugger client per page it does not return ws address once debugger connected, that's why cachedWsUrls was there in the first place ( but looks like it wasn't used correctly )

[sidorares]

would be great to replace some other hard-coded values ( ports etc ) but I guess that's another topic

[splebel]

@sidorares I've submitted a PR to fix this on Chrome 59. I'd like to get your feedback.

[sidorares]

published as v0.0.8

[neilD2]

@SahidMiller have tried to follow steps, but chrome driver hangs and I cannot see traffic in localhost:9993, does this work for you?