Skip to content
This repository has been archived by the owner on May 1, 2023. It is now read-only.

Investigate possible upstream regressions in chrome-devtools JS #13

Closed
jasta opened this issue Feb 11, 2015 · 3 comments
Closed

Investigate possible upstream regressions in chrome-devtools JS #13

jasta opened this issue Feb 11, 2015 · 3 comments
Assignees

Comments

@jasta
Copy link
Contributor

jasta commented Feb 11, 2015

Concerning bugs have been detected lately related to Chrome 40's handling of the devtools JS. This should be investigated with the upstream maintainers to ensure that the protocol is not being rev'd improperly and in a way that may leave us out in the cold in future updates.

In particular:

  1. Chrome 40's initial release broke handling of the old @161987 and @177902 versions of the WebKit Inspector UI. The Resources tab had numerous rendering bugs, blocking access to WebSQL for us.
  2. After upgrading to @188492, many bugs were detected on slow or unreliable networks. Requests would randomly disappear from the Network tab and the culprit was found to be a previously optional type field is now required in Network.requestWillBeSent and a new undocumented Network.loadingFailed paramater (also type) was added and made mandatory as well. Failure to send these fields causes the UI refresh to raise JavaScript errors.

Once Stetho is made public, we should engage upstream about these issues to understand what's happening.

@paulirish
Copy link
Contributor

The full protocol is available here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/protocol.json&q=protocol.json&sq=package:chromium&type=cs

It looks like Network.requestWillBeSent's type is still optional, but it's possible the UI makes some assumptions on its presence. That'd be a bug. We could either rev protocol or address the frontend's dependence on the type attribute. We'd welcome a contribution from ya'll for the latter.

Looking at the Network.loadingFailed type it does appear that's non-optional, and that's undocumented in 1.1.

@jasta
Copy link
Contributor Author

jasta commented Feb 19, 2015

That's really helpful, thanks. We've been using entirely the wrong protocol.json all this time :)

@paulirish
Copy link
Contributor

We've been using entirely the wrong protocol.json all this time :)

Hah. :) Does #34 sort you out then?

I've recently updated this documentation too, btw. https://developer.chrome.com/devtools/docs/debugger-protocol

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants