Difference between protocol viewer in browser and websocket connection

[Niranjan Rao]

Greetings,

Is there any difference when observing protocol events using protocol viewer functionality in the browser vs events we get when connected to websocket?

My websocket client is inundated with events like DOM.inlineStyleInvalidated, but if I observe protocol monitor for same browser - same instance, same site, I don't see those events displayed.

It's possible site is changing something, but trying to figure out why the difference. In protocol monitor viewer I see other DOM events, so it's likely that DOM is enabled in the viewer though I explicitly did not enable it.

Regards,

Niranjan

--
Niranjan Rao | Sr.Architect
he/his
Paymentus
Paymentus Corporation The Real-Time Bill Payment Company^TM

860 Hillview Court Suite 220 Milpitas CA 95035
www.paymentus.com

[Paul Irish]

Short answer:  there's not a huge difference.

As you already know, you only receive events for the domains that are enabled. 

DevTools frontend enables quite a lot of domains, though many only under certain conditions.

So in Protocol Viewer you're seeing the CDP traffic of everything the frontend has enabled.

Sidenote: There are some events that are only emitted after calling some (non-enable) method, like Page.setLifecycleEventsEnabled, but I don't see any reason why DOM.inlineStyleInvalidated is special like that.

I don't have a guess for your case, other than the page content is quite different.  Your browser's adblocker/extensions, viewport size, headlessness etc can influence the page runtime a lot.

G'luck!

--
You received this message because you are subscribed to the Google Groups "chrome-debugging-protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-debugging-p...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chrome-debugging-protocol/a38130ed-de0e-48b1-aa8c-c1dca87c5bcf%40paymentus.com.

[Niranjan Rao]

Thank you for the answer, but it was same browser instance/window . My tool fires the browser and listens to the events. I opened the devtools window in the tool fired browser window to check the protocol messages

So everything except enabling domains has to be same but leads to my further confusion. As I see other DOM events such as childNodeInserted in the protocol monitor window, I am thinking that protocol monitor has enabled DOM domain but then I've mystery at my hands.

Regards,

Niranjan

On 4/3/24 12:24, Paul Irish wrote:

Short answer: there's not a huge difference. As you already know, you only receive events for the domains that are enabled. DevTools frontend enables quite a lot of domains, though many only under certain conditions. So in Protocol Viewer

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

 

ZjQcmQRYFpfptBannerEnd

[Niranjan Rao]

Performed some experiments. It seems to be related with CSS.enable. If I enable it, I see similar messages in protocol monitor of the browser also. It's not clear to me how CSS.enable results into extra DOM.childNodeCountUpdated  messages.

Regards,

Niranjan

On 4/3/24 12:24, Paul Irish wrote:

Short answer: there's not a huge difference. As you already know, you only receive events for the domains that are enabled. DevTools frontend enables quite a lot of domains, though many only under certain conditions. So in Protocol Viewer

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

 

ZjQcmQRYFpfptBannerEnd

[Andrey Kosyakov]

Hi Niranjan,

If I understand correctly, you've got a CDP client of your own talking to chrome via a websocket? If so, whatever you observe in the protocol monitor is going to be different compared to the traffic you see over the websocket -- the former will show the front-end session, while the latter will show the session of your client. The two would be largely independent (we maintain a set of DevTools agents for each session and most state, including what instrumentations are enabled, is per agent instance).

DOM.inlineStyleInvalidated in particular is only supposed to be emitted for DOM nodes that we've sent to the client (usually via something like DOM.{getDocument,requestChildNodes,pushNode*ToFrontend} etc), I don't think we would push a node to the client unless it was explicitly requested. A CSS domain can only be enabled if the DOM agent has previously been enabled, so I think you probably enable DOM already. However, as stated above, it will take more than just enabling the DOM agent to start receiving the events.

As for what you see in the protocol monitor -- since the front-end obviously enables DOM agent and requests its document and top-level nodes as soon as you open the Elements panel, the set of events you observe in the protocol monitor is determined by what you're looking at in the Elements panel (e.g. expanding the DOM tree will likely cause additional events).

Best regards,

Andrey.

To view this discussion on the web visit https://groups.google.com/d/msgid/chrome-debugging-protocol/6f932030-5c7d-4285-b75a-8f3f677249db%40paymentus.com.