Page MenuHomePhabricator

[M] Unable to get property 'appendChild' of undefined or null reference
Closed, DeclinedPublic

Description

https://commons.wikimedia.org/w/index.php?search=china+rocket&title=Special:MediaSearch&go=Go&type=image

~10 per day since we deployed this patch.

https://logstash.wikimedia.org/app/dashboards#/view/AXDBY8Qhh3Uj6x1zCF56?_g=h@a6c700f&_a=h@c9f6470

Message
Unable to get property 'appendChild' of undefined or null reference
Trace
at module.exports.mounted  https://commons.wikimedia.org/w/load.php?lang=en&modules=jquery%7Cjquery.ui%7Cwikibase.mediainfo.mediasearch.vue&skin=vector&version=1pnkb:458:821
at He  Unknown script code:436:225
at Yt  Unknown script code:450:197
at jt.insert  Unknown script code:445:190
at k  Unknown script code:485:739
at Anonymous function  Unknown script code:487:105
at e.prototype._update  Unknown script code:459:363
at r  Unknown script code:493:734
at fn.prototype.get  Unknown script code:451:614
at fn  Unknown script code:450:956

Event Timeline

So, we have two places in our code that call appendChild directly – in the mounted() lifecycle hook of the Dialog and CopyTextLayout components. The error seems to be pointing to one (or both) of these.

In both cases, the code is document.body.appendChild( someElement ). The error message here says "unable to get property 'appendChild' of undefined or null reference". Does that mean that document.body is not evaluating correctly? What would cause that to happen?

CBogen renamed this task from Unable to get property 'appendChild' of undefined or null reference to [M] Unable to get property 'appendChild' of undefined or null reference.Apr 7 2021, 4:44 PM

[…] In both cases, the code is document.body.appendChild( someElement ). The error message here says "unable to get property 'appendChild' of undefined or null reference". Does that mean that document.body is not evaluating correctly? What would cause that to happen?

Interesting. Yeah, in that case a conditional would seem weird since it's not clear what scenario that is supporting, or what the implied else would/could/should do instead.

Even if some serious error were to happen server-side, these elements always exist as they are implied by the HTML5 spec. E.g. if you go to data:text/html,<!DOCTYPE html>Hi in the address bar, that is a a fully valid HTML5 document and will implicitly get <html><head></head><body>Hi</body></html> around it, complete with .documentElement, .head and .body references.

Realistically, the most likely cause of these becoming undefined is a misbehaving user script or browser extension that calls document.open(). This basically re-starts the browser's document parser as if the HTML download never happened. In that case, until document.close() is called, after some .write calls, there will temporarily not be a .head or .body. As soon as .close() is called, they will exist again.

If someone's user script deleted the DOM in this way, what's to say they haven't deleted Element.prototoype.appendChild as well for good measure? It's gargage in, gargage out. Probably noise we can just ignore assuming it won't be common enough to care about in the logs. See also: T266708.

This error is still happening occasionally (48 occurrences in the last 7 days, spread pretty evenly). Not clear why it is occurring but per the ticket @Krinkle referenced, this may be something we ought to just decline and filter from the logs. I don't think the cause is anything in our code.