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?

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?

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.

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… ? )

Talked this over with dgozman and we agree on this basic approach:

• use current day copy of the protocol
• filter out everything that's experimental or deprecated (incl domains)
• ship as 1.2 (stable)
• remove 1.1

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.

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.

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:

• show redirected items in their old domains with label "deprecated" or
• stop generating broken links (create-search-index.js).

It would be nice to support service worker to make protocol viewer available offline.

Check what this is all about:

and fix it.

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.

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 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.

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

Will need @pavelfeldman's help

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!

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:

• when there is no page reload user may miss that page jumped to the right section,
• when search result is at the very bottom of the page it won't be shown right under the header (where you would expect it to be).

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

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"

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"
  }
}

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).

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.

Happens only for params.

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.

With a little time it could look much better. Any suggestions for a API reference style to be inspired from?

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.

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

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:

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

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.

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)

I'd be great to be able to navigate through the search results with arrow keys (and select elements by hitting enter).

Related to #4: "Pull latest protocol.json from Blink"

We could deprecate these pages

• https://developer.chrome.com/devtools/docs/protocol/tot/index this one is definitely useless, especially now.
• https://developer.chrome.com/devtools/docs/protocol/1.1/index
• https://developer.chrome.com/devtools/docs/protocol/1.0/index
• https://developer.chrome.com/devtools/docs/protocol/0.1/index

And use this viewer here for all of them.

in repo

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

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.

@dgozman :

Entries marked "hidden" are meant to change at any time. I'd mark non-hidden entries with "stable" sign or something.

Oftentimes, 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.

What's the official name for the remote debugging protocol used by Chrome? The variants I've seen a few places:

1. Chrome Debugger Protocol.
2. Chrome Debugging Protocol.
3. Chrome Remote Debugging Protocol.

I'm confused. 😕

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.

In the new (lovely) design, when you explore an area like "CSS" that has a relatively short string length, something weird happens with the navigation width. Looks like you are using flexbox +width:100% that might cause some funkyness.

What steps will reproduce the problem?

1. Open https://chromedevtools.github.io/devtools-protocol/ with Firefox (57.0, Debian)

What is the expected result?

The documentation shows up.

What happens instead of that?

A blank page.
In the console, there is TypeError: this._meta.byKey is not a function

After clicking the search button, an additional request is made for Roboto.

See:
https://dl.dropboxusercontent.com/u/8989748/font.mov

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.

What steps will reproduce the problem?

1. Start up a Chrome headless instance without seccomp (see below for Docker images)
2. Get websocket link with the /json endpoint.
3. Connect to Chrome instance in Node via [email protected]

What is the expected result?

The connection is successfully made.

What happens instead of that?

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.

Actual:

1. Go to https://chromedevtools.github.io/debugger-protocol-viewer/ScreenOrientation/,
2. The animation domain is shown.

Expected:

1. Go to https://chromedevtools.github.io/debugger-protocol-viewer/ScreenOrientation/
2. ScreenOrientation domain is shown.

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.

Lets make sure this doesn't go stale.

We should also indicate the blink/chrome version this represents.

So, on every update:

• grab the protocol.json source
• grab date of most recent repo commit,
• grab the blink & chromium version numbers.

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.

To reproduce:

• go to https://chromedevtools.github.io/debugger-protocol-viewer/1-1/DOMDebugger/
• click on the DOM.NodeId

URL misses protocol version

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.

Proposal:

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 online
• debugger-protocol-viewer repo's gh-pages branch gets redirects set up. See #77
• debugger-protocol-viewer repo's master branch will now be used for the source code of this API documentation

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.