On Tuesday, October 2, 2012 11:06:50 PM UTC-7, pfeldman wrote:
> When you send DOM.getDocument, you get a number of DOM.setChildNodes in
> return. They should include the children of the document node (I think we
> push nodes 2 levels deep upon getDocument). That's why subsequent calls
> to DOM.requestChildNodes(documentNodeId) results in no setChildNodes -
> backend remembers that it has been sending those children to you
> already. In order to get all the events, you need to traverse entire DOM
> and hence become aware of all of the nodes.
> But I wonder if you should use DOM domain for your task. DOM domain API is
> for visualizing DOM only, that's why it is structured in such an unusual
> way. There are other ways of getting that info such as: listening to
> Timeline events or registering your own JavaScript listeners using Runtime
> domain and emitting signals using console or using some other ways.
> Could you share what kind of problem you are solving so that we could help
> better?
> Regards
> Pavel
> On Wed, Oct 3, 2012 at 9:28 AM, <t...@yieldmetrics.com <javascript:>>wrote:
>> My app is communicating with Chrome v22 via the remote debugging
>> websocket interface. I have no problem handling events in the Network and
>> Debugger domains however I can't for the life of me trigger any events to
>> fire in the DOM domain.
>> The documentation states, *"It is important that client receives DOM
>> events only for the nodes that are known to the client."* Is there a
>> way to register for these events? I can retrieve the document just fine
>> (DOM.getDocument), resolve the document's nodeId to a javascript object,
>> and then retrieve that object's property list. Furthermore, I can make
>> calls to DOM.requestChildNodes with that same nodeId. But none of this
>> triggers any of the DOM events to fire (in particular I would expect to see
>> the DOM.setChildNodes event.)
>> Any pointers here would be appreciated.
>> Thanks,
>> Tom
