chromedevtools / debugger-protocol-viewer Goto Github PK
View Code? Open in Web Editor NEWDevTools Protocol API docs—its domains, methods, and events
Home Page: https://chromedevtools.github.io/devtools-protocol/
License: Other
DevTools Protocol API docs—its domains, methods, and events
Home Page: https://chromedevtools.github.io/devtools-protocol/
License: Other
If you trim down to show a single method in the dropdown, then try to go back to "Show method" option the results fail to load. "Show method" should probably be renamed "Show All" and be fixed so it will then show all the given methods after a single is selected.
The documentation shows up.
A blank page.
In the console, there is TypeError: this._meta.byKey is not a function
Would be ideal to have the HTML of the entire thing in place for SEO purposes.
Filters at the top would then filter things.
A cheap build process would be fine for this.
I often find myself revisiting same sections of documentation. I'd be great to keep info about previous searches and feature visited sections in the future searches.
Say, I want to build a Chrome extension, is this API just plainly available to me there? How would be able to do:
Debugger.enable()
in a chrome extension?
How about in a remote debugger outside of a chrome extension a (i.e. via Node say in a Node-Webkit app)?
I think if your documentation had a section about how to implement this API (perhaps even as the first page) it would do wonders for it.
Will need @pavelfeldman's help
paper-toolbar's animated transition is not good.
most details in here: PolymerElements/paper-scroll-header-panel#19 (comment)
also relevant: PolymerElements/paper-toolbar#27
Related to #4: "Pull latest protocol.json from Blink"
We could deprecate these pages
And use this viewer here for all of them.
The 1.0 and 1.1 protocols are actually in the blink repo so this is easy:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/&q=protocol.json&sq=package:chromium&type=cs (inspector-XX.json)
This is being tracked via this milestone:
https://github.com/ChromeDevTools/debugger-protocol-viewer/milestones/Ship%20as%20the%20new%20default%20viewer
Hello!
I'm looking for some advice about my problem.
I've got huge webpage which is in 300DPI and should be 12.5inch x 18.5x. (Its 3750px x 5550px)
By using Page.printToPDF
I need to set paper size: 39inch x 57.8inch. As I know, there is no option to change DPI property and it's constant.
My only idea was to use scale option, but it lowers quality, slightly breaks some HTML elements and PDF weight stays the same. I think its because of many high resolution images. So my idea seems to be sensless for my case.
Do you have any workaround or proper solution for such cases?
It'd be really nice if the protocol viewer showed some sample messages
{
"callFrameId": "{\"ordinal\":0,\"injectedScriptId\":2}",
"functionName": "module.exports.Router.extend.index",
"location": {
"scriptId": "34",
"lineNumber": 26642,
"columnNumber": 23
},
"scopeChain": [
{
"object": {
"type": "object",
"objectId": "{\"injectedScriptId\":2,\"id\":1}",
"className": "Object",
"description": "Object"
},
"type": "local"
},
{
"object": {
"type": "object",
"objectId": "{\"injectedScriptId\":2,\"id\":2}",
"className": "Object",
"description": "Object"
},
"type": "closure"
},
{
"object": {
"type": "object",
"objectId": "{\"injectedScriptId\":2,\"id\":3}",
"className": "Window",
"description": "Window"
},
"type": "global"
}
],
"this": {
"type": "object",
"objectId": "{\"injectedScriptId\":2,\"id\":4}",
"className": "child",
"description": "child"
}
}
Actual:
Expected:
https://chromedevtools.github.io/debugger-protocol-viewer/CSS/ currently points to the DOM domain. That's because files in the _domain
folder got out of sync with protocol.json after it was updated. These files have to be rebuilt every time protocol.json
is updated (node create-domain-files.js
).
We should have a script for updating protocol.json
to avoid these kinds of manual errors. In the first step, script should download latest protocol.json
(e.g. like this: https://github.com/cyrus-and/chrome-remote-interface/blob/master/Makefile#L7 ), in the second step domain files have to be rebuilt (node create-domain-files.js
).
Sometimes, after we click on the search result, it's not immediately clear which section is the one that we search for.
Two scenarios I've identified:
With a little time it could look much better. Any suggestions for a API reference style to be inspired from?
Currently if you want to hit a debugger; breakpoint you have to have the browser/debugger already open. It would be really cool to break without having the debugger open.
This would be particularly useful in cases where you run test scripts, spawn large number of node processes, or run into an unexpected error. Instead of having to open the browser every time you could simply open it when the debugger statement has been hit
We're currently not bundling. Doing that would make the load much faster.
But, as noted in #91 (comment), it's disabled for now because of an upstream bug.
I believe this is the upstream bug: https://github.com/Polymer/polymer-bundler/issues/611
cc @TimvdLippe
The spec for network.response in the stable(1.2) build contains the property securityState which links to Security.SecurityState for the property definition. The domain Security does not exist in 1.2 so this is a dead link.
I'm not exactly sure that this is a debugger-protocol-viewer error, but I thought I'd start here because I'm getting protocol errors.
The connection is successfully made.
When using justinribeiro/chrome-headless, I get the following error:
Protocol error (Performance.enable): 'Performance.enable' wasn't found undefined
at Session._onMessage (../../node_modules/puppeteer/node6/Connection.js:272:25)
at Connection.<anonymous> (../../node_modules/puppeteer/node6/Connection.js:150:19)
at next (native)
at step (../../node_modules/puppeteer/node6/Connection.js:113:24)
at Promise (../../node_modules/puppeteer/node6/Connection.js:131:12)
at fn (../../node_modules/puppeteer/node6/Connection.js:109:10)
at Connection._onMessage (../../node_modules/puppeteer/node6/Connection.js:133:3)
at emitOne (events.js:96:13)
at WebSocket.emit (events.js:188:7)
at Receiver._receiver.onmessage (../../node_modules/ws/lib/WebSocket.js:143:47)
at Receiver.dataMessage (../../node_modules/ws/lib/Receiver.js:389:14)
at Receiver.getData (../../node_modules/ws/lib/Receiver.js:330:12)
at Receiver.startLoop (../../node_modules/ws/lib/Receiver.js:165:16)
at Receiver.add (../../node_modules/ws/lib/Receiver.js:139:10)
at Socket._ultron.on (../../node_modules/ws/lib/WebSocket.js:139:22)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:547:20)
I thought it might be from the month-old Chrome version in the build, so I tried again with my own fresh container, chrbala/headless-chrome which uses the same dockerfile and was built with Chromium 62.0.3202.62-1. The version of Puppeteer I'm using declares that it's compatible with chromium_revision of 508693, but I'm not sure how that maps to the semantic Chromium versions.
My build had a different error:
Protocol error (Runtime.callFunctionOn): Invalid parameters objectId: string value expected
at Session._onMessage (../../node_modules/puppeteer/node6/Connection.js:272:25)
at Connection.<anonymous> (../../node_modules/puppeteer/node6/Connection.js:150:19)
at next (native)
at step (../../node_modules/puppeteer/node6/Connection.js:113:24)
at Promise (../../node_modules/puppeteer/node6/Connection.js:131:12)
at fn (../../node_modules/puppeteer/node6/Connection.js:109:10)
at Connection._onMessage (../../node_modules/puppeteer/node6/Connection.js:133:3)
at emitOne (events.js:96:13)
at WebSocket.emit (events.js:188:7)
at Receiver._receiver.onmessage (../../node_modules/ws/lib/WebSocket.js:143:47)
at Receiver.dataMessage (../../node_modules/ws/lib/Receiver.js:389:14)
at Receiver.getData (../../node_modules/ws/lib/Receiver.js:330:12)
at Receiver.startLoop (../../node_modules/ws/lib/Receiver.js:165:16)
at Receiver.add (../../node_modules/ws/lib/Receiver.js:139:10)
at Socket._ultron.on (../../node_modules/ws/lib/WebSocket.js:139:22)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:547:20)
Both of the above Docker images were built with this docker file.
Thing called "Chrome DevTools protocol" is deprecated: https://code.google.com/p/chromedevtools/wiki/ChromeDevToolsProtocol
The correct name, according to the old docs, is "Remote Debugging Protocol":
https://developer.chrome.com/devtools/docs/debugger-protocol
In the docs we are using names such as "DevTools protocol" and "Chrome DevTools debugger protocol". IMO we should consider changing that to "Remote Debugging Protocol"
Those are just for backwards compatibility, and we would like all implementations to switch to the new ones. For example, Page.getCookies should not be visible in favor of Network.getCookies.
The documentation is lacking on Page.loadEventFired it returns a parameter timestamp number
, but I cannot figure out what this number means. I'm getting numbers like 1894443.789323
which doesn't seem to be a unix epoch timestamp.
We'll need to have permalinks for things. At the very least, domains, but likely domain + method/event too.
I looked briefly at https://erikringsmuth.github.io/app-router/ and it appears the best maintained in this space. ( Not sure that polymer offers something more definitive… ? )
Discovered today that our tot was missing a few domains.
Found the bug and fixed it.
Over in merge-protocol-files, the Object.assign
didn't seem to be friendly to arrays.
So it took protocol2's 5 array items and overwrote protocol1's first five array items.
whooops.
Lets make sure this doesn't go stale.
We should also indicate the blink/chrome version this represents.
So, on every update:
Deployed as a separate site for convenience. Would prefer to augment this existing app to support multiple versions, as defined in #4. But hey.
http://chromedevtools.github.io/debugger-protocol-viewer-1.1/
https://github.com/ChromeDevTools/debugger-protocol-viewer/compare/gh-pages-1.1
@kdzwinel happy for you to take a look.
Despite the URL is properly updated with the correct hash when navigating backward/forward the history, the scroll remains at the top of the page. Not sure if this worked before.
Chrome 54.0.2840.98 on macOS.
We miss type information in the viewer. This makes it almost impossible to figure out how to use some methods e.g. DOM.higlightNode
requires higlightConfig
that has a very specific format (check it out here).
Type information is available in the protocol.json
, we are just not displaying it ATM.
The published URL of the protocol docs move to https://chromedevtools.github.io/devtools-protocol/
.
devtools-protocol
repo's master
branch continues to be the canonical*/reference location of the protocol files. it's issue tracker is used for protocol discussion.devtools-protocol
repo's gh-pages
branch will receive the source so it shows up onlinedebugger-protocol-viewer
repo's gh-pages
branch gets redirects set up. See #77debugger-protocol-viewer
repo's master
branch will now be used for the source code of this API documentationOftentimes, navigation to different domains takes a lot of time, especially on a laggy connection.
Since the whole UI is based on just two .json
files, we can load descriptors proactively and render different protocol domains instantly, without any network roundtrips.
To reproduce:
DOM.NodeId
URL misses protocol version
Currently it stands alone in its own repo, but this would make sense to integrate with the rest of the DevTools docs.
At least we need to link up https://developer.chrome.com/devtools/docs/debugger-protocol and visa versa.
@dgozman :
Entries marked "hidden" are meant to change at any time. I'd mark non-hidden entries with "stable" sign or something.
Hi,
I would like to create chrome extension to dev tool where i would like to intercept JS code of current web page before it is compiled or executed by browser ,
Actually i want to instrument JS code before it to run in browser.
Can anybody will help us , how it is possible ?
Many Thanks in advance.
I'd be great to be able to navigate through the search results with arrow keys (and select elements by hitting enter).
I've been using this viewer for some time and IMO method/event selectors are useless (while they add a significant amount of code to the project). It would be much better to remove them and have all metods/events folded by default (showing only names) with ability to expand them on click (to see description/parameters/etc.).
Also, the 'domain' menu could be changed to a flat list instead of a select.
What do you guys think?
from @linclark
It looks like Console was removed because it is deprecated, but the Log entry (which replaces some of the functionality) is still experimental, so that's not included either.
Some types, like Page.FrameResourceTree, have properties that are arrays of generic objects. Currently we do not show properties for these objects:
Proposed UI for the "second level" of properties:
Similar example: https://chromedevtools.github.io/debugger-protocol-viewer/CSS/#method-forcePseudoState (enum values missing)
A nifty feature would be to be able to filter/search. Imagine you wanna look up something with stylesheets, you type "stylesheets" and it filters the methods/events that has a name or property matching.
Would be extremely useful when looking up stuff, and should be relatively easy, as we have all the data available in protocol.json
Talked this over with dgozman and we agree on this basic approach:
It would be nice if the json/list
and json/version
endpoints were documented. I'm not sure if they belong here as it's not strictly the protocol, but it does serve a similar purpose.
We are not showing methods/events that were moved to other domain in their old domain:
However, in search results we have links to both: new and the old domain. Old domain links are broken. See 'highlightNode' that was moved from DOM to Overlay:
We should either:
from #46
the tot protocol should be a default. so i would like to keep the left navigation of the tot protocol present as you land on the site. I guess that means we have a chooser control and the chooser defaults to tot?
So a chooser above the the left navigation, right? No problemo!
It would be nice to support service worker to make protocol viewer available offline.
After clicking the search button, an additional request is made for Roboto.
by @gsouf
Hi,
When navigating on the doc hosted on github pages the left menu is not reachable and last items cannot be clicked.
See :
Expected result:
Since we added support for multiple versions of the protocol, I've been thinking about including APIs supported by the Edge Diagnostic Adapter. @paulirish is on board with this idea. @auchenberg WDYT?
Only thing that we need to make this happen is a protocol.json
file describing APIs supported by the Chrome Debugging Protocol endpoint in Edge.
What's the official name for the remote debugging protocol used by Chrome? The variants I've seen a few places:
I'm confused. 😕
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.