TronLink message handlers not properly guarded against unexpected messages
for the most of the time, and on other pages, the .data bears either a object, or a string, all are safe to dereference for .isTronLink
but on WP.PL sites, .data does not exist in the message object, causing js crash
I don't know what causes CPU spin, but it looks like an attempt to re-deliver that message (which crashes again, and tries again, and again)
Here you can see that t.data is undefined, message is certainly coming from the WP webpage (origin, etc), and the contentScript will crash on the n.isTronLink (and similar below) because n is not checked against null/undefined.
I was able to diagnose and trace it, but it took me:
(a) several weeks to stop blaming Chrome and notice that the problem is only related to WP
(b) and then several days to stop blaming WP and notice it's a problem with some of my local extensions
(c) and then, icing on the cake, I finally got irritated enough and it took about 3hrs to properly attribute problem to TronLink and debug&find the case
(btw. not an easy thing to do with the DeveloperTools constantly crashing due to CPU/MEM bottleneck).
It's not important that I wasted time, it's important how long it make take to notice things when you're just using the browser, and it's safe to assume that I'm on the furhter end of those more tech-savvy users of TronLink. For those less, it will be an unknown problem out of the blue sky.
At this moment, TronLink prevents normal browsing of WP pages, and also may cause problems with other pages where there are ad frames from WP. And any other page that dares to send a message with unset data field. Having such a tab opened causes a very high CPU usage, browser because less and less responsive, with no easily discoverable cause from the user's perspective, who may perceive it as a instability of the browser itself.
For those reasons, it'd call this bug a critical one.
Where:
What happens:
Most probable cause(s):
.databears either a object, or a string, all are safe to dereference for.isTronLink.datadoes not exist in the message object, causing js crashHere you can see that
t.datais undefined, message is certainly coming from the WP webpage (origin, etc), and thecontentScriptwill crash on then.isTronLink(and similar below) becausenis not checked against null/undefined.I was able to diagnose and trace it, but it took me:
(a) several weeks to stop blaming Chrome and notice that the problem is only related to WP
(b) and then several days to stop blaming WP and notice it's a problem with some of my local extensions
(c) and then, icing on the cake, I finally got irritated enough and it took about 3hrs to properly attribute problem to TronLink and debug&find the case
(btw. not an easy thing to do with the DeveloperTools constantly crashing due to CPU/MEM bottleneck).
It's not important that I wasted time, it's important how long it make take to notice things when you're just using the browser, and it's safe to assume that I'm on the furhter end of those more tech-savvy users of TronLink. For those less, it will be an unknown problem out of the blue sky.
At this moment, TronLink prevents normal browsing of WP pages, and also may cause problems with other pages where there are ad frames from WP. And any other page that dares to send a message with unset
datafield. Having such a tab opened causes a very high CPU usage, browser because less and less responsive, with no easily discoverable cause from the user's perspective, who may perceive it as a instability of the browser itself.For those reasons, it'd call this bug a critical one.