Error connecting when using 'iOS WebKit Debug Proxy' #59

dchristian-ias · 2016-10-28T23:57:25Z

Hi there,

I am currently running into errors when trying to connect the chrome-remote-interface module to the debug server running on 'http://localhost:9222/' when it has been started with the iOS WebKit Debug Proxy.

I feel this might be a compatibility issue but just wanted to confirm that I am not missing anything obvious here, since to my understanding the iOS WebKit Debug Proxy uses the Chrome Remote Debugging Protocol and therefore the chrome-remote-interface should be able to connect. Also confirming that I can open the Dev Tools Frontend Url and see the proper network requests from my local iPhone simulator being emitted, so I know that this part is working as expected.

When running this code:

var chrome = require('chrome-remote-interface')

var url = 'https://github.com/'
var options = {
    chooseTab: function(tabs) {
      var targetTab = tabs.filter(function(tab) {
        return tab.url == url
      })

      if(targetTab.length) {
        return tabs.indexOf(targetTab[0])
      } 

      return 0
    }
  }

chrome(options, function(client) {

  console.log('Connected!');

  client.Page.enable();

  client.once('ready', function () {
      client.Page.navigate({
        'url': 'https://github.com'
      });
  });
}).on('error', function(err) {
  console.error('Cannot connect to IOS:');
  console.log(err);
});

I get this error (with no other console messages, it does not make it to the callback):

[Error: <html><title>Error 404 (Not Found)</title>
<p><b>404.</b> <ins>That's an error.</ins>
<p>The requested URL <code>/json/list</code> was not found.
</html>]

I seems the root of the issue is that the debug server for iwdp returns a 404 error when visiting route 'json/list'.

My main question is, should iwdp be providing the route 'json/list' for the chrome-remote-interface to be able to connect, or am I missing something else in setting up this connection?

Thanks again for your help here.

The text was updated successfully, but these errors were encountered:

cyrus-and · 2016-10-29T00:19:50Z

Thanks for reporting this in a such accurate way. I always wanted to give IWDP a try but I'm not an iOS user/developer. If you succeed in doing so I can add it to the list of supported implementations.

My main question is, should iwdp be providing the route 'json/list' for the chrome-remote-interface to be able to connect, or am I missing something else in setting up this connection?

No, it is not mandatory but it's the default. chooseTab will lookup /json/list only when a function is provided. You can directly pass the WebSocket URL, for example:

var options = {
    chooseTab: 'ws://localhost:9222/devtools/page/d1ec5032-ee90-4820-bc75-1f6f007edfe8'
}

cyrus-and · 2016-10-29T00:27:19Z

I could make an exception just for IWDP and fetch /json instead of /json/list or even just fetch /json in any case, but I think it would make much more sense to file an issue against IWDP to request the /json/list endpoint. I can do it, if the rest works.

cyrus-and · 2016-10-29T01:12:26Z

I've forked IWDP and added that trivial change, if you can compile it yourself try cloning my json-list branch. If everything works I will send a PR.

dchristian-ias · 2016-10-29T02:54:25Z

Hey @cyrus-and ,

Thanks again for the help here, explicitly setting chooseTab to the WebSocket URL worked like a charm. (In my case visiting "http://localhost:9222/json" shows webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1" I believe this may be the default for IWDP if that helps anyone..).

However, some small issues still presented themselves, like when running the below code snippet:

var chrome = require('chrome-remote-interface');

var options = {
  chooseTab: 'ws://localhost:9222/devtools/page/1'
}

chrome(options, function(client) {

  console.log('Connected!');

  client.Page.enable();
  client.Profiler.enable();
  client.Profiler.start();

  client.Page.loadEventFired(function () {
    console.log('Enabled - Page Load Fired');

      client.Profiler.stop().then(function(profile) {
          console.log('Profiler Stop Fired', profile);
          client.close();
      });
  });

 client.Profiler.setSamplingInterval({ 'interval': 100 }, function () {
      client.Page.navigate({'url': 'http://example.com'});
  });

}).on('error', function(err) {
  console.error('Cannot connect to IOS:');
  console.log(err);
});

We never reach the line console.log('Profiler Stop Fired', profile);, and I believe it's due to this issue with IWDP (Also note, Profiling also hangs in the Dev Tools Frontend Url UI when using IWDP, I do not think is a chrome-remote-interface issue). Basically the Chrome DevTools protocol and the Safari Inspector protocol diverging at some point.

I guess at this point (admittedly without testing myself yet), if I had the chrome-remote-interface utilize the correct Safari Inspector Protocol should the chrome-remote-interface work as expected in this case?

I will do some more playing around with it this weekend on my end and will and let you know my findings, just wanted to hear your thoughts.

Thanks again for your help here..

cyrus-and · 2016-10-29T12:24:19Z

I guess at this point (admittedly without testing myself yet), if I had the chrome-remote-interface utilize the correct Safari Inspector Protocol should the chrome-remote-interface work as expected in this case?

From the chrome-remote-interface perspective, knowing the exact protocol is quite handy but not mandatory. The JSON descriptor is just used to build the API but remember that you can always use the raw methods for commands and events:

chrome.send('UnknownDomain.unknownCommand', params, callback);
chrome.on('UnknownEvent', callback);

Surely, it would be nice to have the proper fetcher for IWDP too. But this will require:

an updated code repository from which to fetch the latest protocol (since the implementation does not provide /json/protocol);
that IWDP provides the /json/version endpoint.

I'm confident that both points are easily achievable.

Thanks for your time.

PS you can use ```js to enable the syntax highlighting for your snippets.

cyrus-and · 2016-10-29T13:32:28Z

OK I managed to borrow an iPad and set up everything on my box, the patch works flawlessly.
Here's the PR.

cyrus-and · 2016-10-29T13:48:26Z

We never reach the line console.log('Profiler Stop Fired', profile);

Well it seems that there is no Profile domain available on Safari.

$ chrome-remote-interface -p 9223 inspect
>>> Profiler.enable()
{ error: 
   { code: -32601,
     message: '\'Profiler\' domain was not found',
     data: [ { code: -32601, message: '\'Profiler\' domain was not found' } ] } }

As you say the two protocols are clearly different, but it is quite common among implementations.

cyrus-and · 2016-10-29T14:24:46Z

The PR has been merged into master. The Safari (iOS) support is now official (54a6ad6).
Thanks!

I'm closing this issue since it was about the connection with IWDP. All the other issues you mentioned are valid, but concern the differences between the Chromium protocol and Safari's.

As a personal TODO I might consider submitting another PR for point 2, I'll keep you posted.

dchristian-ias · 2016-10-29T17:46:48Z

From the chrome-remote-interface perspective, knowing the exact protocol is quite handy but not mandatory. The JSON descriptor is just used to build the API but remember that you can always use the raw methods for commands and events

Awesome, this all makes sense, and great to know that I can use the raw methods for commands and events.

The PR has been merged into master. The Safari (iOS) support is now official (54a6ad6).

And yes, this is great news! Thanks again for being so responsive and for all of your help here!

lilili87222 · 2025-05-09T09:26:01Z

WebDebugX support new version ios

dchristian-ias changed the title ~~Error connecting to 'iOS WebKit Debug Proxy'~~ Error connecting when using 'iOS WebKit Debug Proxy' Oct 29, 2016

cyrus-and added the external issue label Oct 29, 2016

dchristian-ias closed this as completed Oct 29, 2016

dchristian-ias reopened this Oct 29, 2016

cyrus-and closed this as completed in 54a6ad6 Oct 29, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Error connecting when using 'iOS WebKit Debug Proxy' #59

Error connecting when using 'iOS WebKit Debug Proxy' #59

dchristian-ias commented Oct 28, 2016 •

edited

Loading

cyrus-and commented Oct 29, 2016 •

edited

Loading

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

dchristian-ias commented Oct 29, 2016 •

edited

Loading

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

dchristian-ias commented Oct 29, 2016

Uh oh!

lilili87222 commented May 9, 2025

Uh oh!

Error connecting when using 'iOS WebKit Debug Proxy' #59

Error connecting when using 'iOS WebKit Debug Proxy' #59

Comments

dchristian-ias commented Oct 28, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

cyrus-and commented Oct 29, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

dchristian-ias commented Oct 29, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

cyrus-and commented Oct 29, 2016

Uh oh!

dchristian-ias commented Oct 29, 2016

Uh oh!

lilili87222 commented May 9, 2025

Uh oh!

dchristian-ias commented Oct 28, 2016 •

edited

Loading

cyrus-and commented Oct 29, 2016 •

edited

Loading

dchristian-ias commented Oct 29, 2016 •

edited

Loading