Retrieve node from nodeId about devtools-protocol HOT 13 CLOSED

Is it your intention that we listen to e.g. DOM.childNodeInserted (or Removed) to keep a local representation of the DOM

this is not my intention, but that's how DOM domain historically was designed. It was optimized for the inspection (devtools elements panel) and hence backend knows what nodes it has already sent to the client, notifies client of changes to these nodes, etc.

I'd like to introduce another DOM2 domain or mode of operation that would be more appropriate for automation / scripting. In that world, nodeId would not exist, unique backendNodeId would identify node and you would be able to fetch node info by its backendNodeId. That will take some time though. For now, caching all the info on nodes as they arrive is the only option.

from devtools-protocol.

Adding on, @rbairwell it seems that you want the element instead of the ID, maybe to work on it. Like what Pavel said, the protocol was originally designed for debugging the browser. Although now with headless mode Chrome I think it is going to attract attention from test / web automation developers.

At the moment I use Runtime.evaluate and the following snippets to get the element whether via CSS selector or XPath selector - for CSS - querySelector(selector).action/property and for XPath - document.evaluate(selector,document,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,null).snapshotItem(0).method/property

I don't have expectation that more changes will come to meet the wishes of automation use cases, and I don't know Google/Chrome longterm goal in opening up headless mode, but being browser agnostic (Edge, Safari etc), it is going to shake-up the Selenium / WebdriverIO world.

from devtools-protocol.

from devtools-protocol.

@pavelfeldman to see if I'm understanding this correctly. Given that e.g. the DOM.attributeModified can return a NodeId, how would one look it up? Is it your intention that we listen to e.g. DOM.childNodeInserted (or Removed) to keep a local representation of the DOM, thus allowing us to look it up?

from devtools-protocol.

this is not my intention, but that's how DOM domain historically was designed.

Sorry, saying it was your intention was perhaps a bad choice of words, I meant from the perspective of the protocol.

Anyway, thanks for the reply, it makes sense and definitely cleared it up for me. Also, looking forward to someday having DOM2, or the like 😄!

from devtools-protocol.

Is the DOM.resolveNode what you want？ get the Node with the given nodeId
https://chromedevtools.github.io/devtools-protocol/tot/DOM/#method-resolveNode

from devtools-protocol.

• f
  but how to get the cssSelectors or Xpath via Chrome devTools Protocol?

from devtools-protocol.

Not sure what is meant by how to 'get', because CSS selectors and XPath selectors are normally 'given' to Chrome to tell it which element to automate on. For me I use Runtime.evaluate and the JS code in my above comment to act on elements using CSS or XPath selectors accordingly.

from devtools-protocol.

Not sure what is meant by how to 'get', because CSS selectors and XPath selectors are normally 'given' to Chrome to tell it which element to automate on. For me I use Runtime.evaluate and the JS code in my above comment to act on elements using CSS or XPath selectors accordingly.

I mean How to generate the css selectol by chrome devtools Protocol？ I can suscribe InspectNodeRequestedEvent when I sended the message SetInspectModeCommand to do Inspect，I can get the nodeid after I do inspect，but I want to get the css selectors of the node I clicked,so how can I do to generate the css selectors by the nodeId??

from devtools-protocol.

This repository is related to Chrome DevTools Protocol, but does not track issues regarding its definition or implementation. If you want to file an issue for the Chrome DevTools Protocol, please open an issue on https://crbug.com under component: Platform>DevTools>Platform. Thanks in advance!

from devtools-protocol.

• f
  but how to get the cssSelectors or Xpath via Chrome devTools Protocol?

hello. Did you find the answer? I am also looking for the same question

from devtools-protocol.

Maybe need to write logic to generate base on attributes present and test iteratively until something unique is found?

Copying @sanjayselectorshub (creator of SelectorsHub and ChroPath) -
on this interesting question on how to get XPath from a specified web element

from devtools-protocol.

This repository is related to Chrome DevTools Protocol, but does not track issues regarding its definition or implementation. If you want to file an issue for the Chrome DevTools Protocol, please open an issue on https://crbug.com under component: Platform>DevTools>Platform. Thanks in advance!

@TimvdLippe Sorry, so you are confirming that current Chrome DevTools Protocol does not provide for finding an id, aren't you?

Present DOM domain serves the 'inspection' goal, not scripting or
automation

@pavelfeldman That's also quite surprising, when you consider that Selenium WebDriver is mainly used for Web Automation and Selenium WebDriver offers Selenium Locators.

So, my question to you (@TimvdLippe @pavelfeldman etc...) boils down to asking whether Selenium Locators are not based on Chrome DevTools Protocol, whilst - on the opposite - e.g. sendKeys is based on the Input.dispatchKeyEvent of Chrome DevTools Protocol. Notice - in this counter-example (of sendKeys) - that a Runtime.evaluate - assigning a value to an input element - would not work the same (for security reasons, I assume, the event would not be trusted etc...).
In other words, does the driver.findElement(By.id actually translate into a Runtime.evaluate of Chrome DevTools Protocol, as we all are thinking (see also the above comment)? Thank you in advance for this confirmation!

Edit - Note
Well (in the meantime, while I am seeking confirmation by myself...), looking at py implementation, they seem to call a FIND_ELEMENT command of the remote WebDriver

return self.execute(Command.FIND_ELEMENT, {"using": by, "value": value})["value"]

So, we have a findElement in the JsonWireProtocol, but (oddly enough) not in Chrome DevTools Protocol, correct?

Ehm, this is the implementation of findElement in the WebDriver code, right? I guess it works based on the fact that one has previously fetched all the nodes. And they explicitly mention the querySelector (!), hence I believe this is the confirmation I was looking for.

/**
 * Finds the first descendant element (excluding `root`) that matches the filter
 * function, using depth first search. Prefer using `querySelector` if the
 * matching criteria can be expressed as a CSS selector.
 *
 * @param {!Element | !Document} root
 * @param {function(!Element): boolean} pred Filter function.
 * @return {?Element} First matching element or null if there is none.
 */
goog.dom.findElement = function(root, pred) {
  'use strict';
  var stack = goog.dom.getChildrenReverse_(root);
  while (stack.length > 0) {
    var next = stack.pop();
    if (pred(next)) return next;
    for (var c = next.lastElementChild; c; c = c.previousElementSibling) {
      stack.push(c);
    }
  }
  return null;
};

from devtools-protocol.