Thanks for raising the ticket! https://grafana.wikimedia.org/d/000000566/overview?viewPanel=16&orgId=1 shows the uptick for this error compared to normal in case you are interested in impact.

I think it might be this one ? https://meta.wikimedia.org/wiki/MediaWiki:Centralnotice-template-B2021_120500_en6C_dsk_p1_lg_rcr_paypal_twin2 or something loosely based on that code. offset() can return undefined for elements it cannot find.

I found a related error "TypeError: undefined is not an object (evaluating 'hash.offset().top')"

Huh, I thought we'd fixed this at some point but I guess not. It only happens for desktop large and you're correct it's when there's a fragment in the URL which can't be found: either a section that has been deleted/renamed, or a lot of the URLs appear to be MediaViewer

Thanks @Pcoombe the errors seem to have stopped now!

@Jdforrester-WMF could your changes as part of T250068 have impacted the jQuery.offset function ? Would that have rolled out this week?

Another possibility, is something went wrong in T277958 and as a result the HTML is loading but not the javascript

There's no banner changes that line up with that time. Since 16:00 UTC today, our only banners have been on English and Portuguese Wikipedias in Brazil. Here are preview links for the mobile ones:

• Large banner https://en.m.wikipedia.org/wiki/NASA?banner=B2021_0421_enBR_m_p1_lg_twin1&country=BR
• Small banner https://en.m.wikipedia.org/wiki/NASA?banner=B2021_0421_enBR_m_p2_sm_twin1&country=BR

Other than that, in the past weeks we have only been running banners on Spanish and Swedish Wikipedias.

Okay thanks for ruling that out @Pcoombe I guess that tells us at this point this does relate to the last train.

Change 683999 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/RelatedArticles@master] Hotfix: loadRelatedArticles should consider existence of container element

https://gerrit.wikimedia.org/r/683999

@phuedx @Jdrewniak my day is wrapping up but my best theory is we might have a caching problem here (but i have no idea how). I recommend we backport the above on Monday at earliest opportunity. I can replicate the error when I do the following:

$( '.read-more-container' ).remove();
var readMore = $( '.read-more-container' ).get( 0 );
mw.viewport.isElementCloseToViewport( readMore, 300 );

That said, I have not seen this in the wild and I have no idea why this would suddenly be happening at such a high rate without any changes to the RelatedArticles client and it's frustrating not knowing the answer to that. If anyone can solve this mystery I will be eternally grateful.

Change 683999 merged by jenkins-bot:

[mediawiki/extensions/RelatedArticles@master] Hotfix: loadRelatedArticles should consider existence of container element

https://gerrit.wikimedia.org/r/683999

Change 684393 had a related patch set uploaded (by Jdrewniak; author: Jdlrobson):

[mediawiki/extensions/RelatedArticles@wmf/1.37.0-wmf.3] Hotfix: loadRelatedArticles should consider existence of container element

https://gerrit.wikimedia.org/r/684393

Change 684393 merged by jenkins-bot:

[mediawiki/extensions/RelatedArticles@wmf/1.37.0-wmf.3] Hotfix: loadRelatedArticles should consider existence of container element

https://gerrit.wikimedia.org/r/684393

Mentioned in SAL (#wikimedia-operations) [2021-05-03T18:19:49Z] <urbanecm@deploy1002> Synchronized php-1.37.0-wmf.3/extensions/RelatedArticles/resources/ext.relatedArticles.readMore.bootstrap/index.js: cf9d9da3bf272d33c2d9b29d9172b1c81bfd8beb: Hotfix: loadRelatedArticles should consider existence of container element (T281547) (duration: 00m 57s)