Page MenuHomePhabricator

Uncaught TypeError: Cannot read property 'getItem' of null
Closed, ResolvedPublic


2030 errors were thrown on mobile French Wikipedia in the last 12 hrs. This is extremely high - in fact is occurring more than any other error.

The banner looks like it was turned on at 4pm UTC yesterday.

Debugging is tricky, but I strongly believe this relates to a new campaign on French Wikipedia. The error is likely preventing the banner from displaying.

This error possibly relates to:

which uses localStorage without any kind of feature detection.

Acceptance criteria

  • The bug is fixed
  • An update is made to the banner loader such that it's easier to identify errors coming from banners. I would recommend a named function e.g. insertCentralNoticeBannerHTML(); so that this appears in the stacktrace
at HTMLDocument.<anonymous>  <anonymous>:1863:41
at mightThrow  URL1:161:149
at process  URL1:161:808


Event Timeline

Jdlrobson created this task.Oct 1 2020, 9:36 PM
Restricted Application added subscribers: Masumrezarock100, Aklapper. · View Herald TranscriptOct 1 2020, 9:36 PM
Jdlrobson triaged this task as Unbreak Now! priority.Oct 1 2020, 9:36 PM

Possibly not unbreak now, but not sure as I don't know much about this banner campaign. Hopefully, someone in fundraising can confirm and update accordingly.

Given this doesn't concern production code this doesn't block the current deployment.

Restricted Application added a subscriber: Pcoombe. · View Herald TranscriptOct 1 2020, 9:36 PM
Jdlrobson added a comment.EditedOct 1 2020, 9:39 PM

I'm also seeing the error NS_ERROR_FILE_CORRUPTED: on French Wikipedia which is likely related based on the timeframe.*/logstash-2020.10.01/clienterror/?id=AXTl-f50LNRtRo5XPxEt

Pcoombe lowered the priority of this task from Unbreak Now! to High.Oct 1 2020, 10:47 PM

Thanks for spotting this @Jdlrobson. We did indeed launch our France campaign at 4pm UTC. 2000 errors is actually pretty small in the context of how many banners we're showing, but it's great that we can now catch these things. I've split out T264375: Make it easier to identify client side errors from CentralNotice banners in logs as a separate task since that will need CentralNotice work rather than just editing our banners.

For now I've just removed this particular bit of code from all our banners which are live, since none of them are actually making use of it. example diff. Leaving this task open to add proper feature detection in case we do want to use this code in other banners.

Jdlrobson updated the task description. (Show Details)Oct 1 2020, 11:39 PM

Nice! I can confirm the drop off!

Thanks for the bug fix.

I'm happy to help you setup a dashboard once we have a reliable way to detect these errors from a stack trace :)

Pcoombe closed this task as Resolved.Oct 6 2020, 8:31 PM
Pcoombe claimed this task.

I updated our banners which do use this to add some feature detection. This should deal with the NS_ERROR_FILE_CORRUPTED issue too, which appears to be a Firefox issue:

Thanks @Ejegg for the code suggestion!

if ( localStorage ) {
    try {
        // TODO: make this general for any identifier, not just 2020
        var lsName = 'CentralNoticeKV|global|impression_diet_bannercount_fundraiser_2020';
        var diet = JSON.parse( localStorage.getItem( lsName ) );
        if ( diet ) {
            var seenCount = diet.val.seenCount;
            $( '.frb-replace-seenCount' ).text( seenCount );
            $( '.frb-replace-seenCount-ordinalNum' ).text( ordinalNums[ seenCount ] );
            $( '.frb-replace-seenCount-ordinalWord' ).text( ordinalWords[ seenCount ] );
    } catch ( ex ) {
        // do nothing - localStorage is configured not to let us read it