{
  "$type": "site.standard.document",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreib52f632paj2adxmq5s6auf24txj4ae3lh2retah3antfhu3ieynu"
    },
    "mimeType": "image/webp",
    "size": 9898
  },
  "description": "When you have eliminated the impossible, whatever remains, however improbable, must be the truth.",
  "path": "/posts/improbable-truth-rare-browser-bugs/",
  "publishedAt": "2012-12-13T00:00:00.000Z",
  "site": "at://did:plc:kl3s4yablm3fgnxfkn47uy5r/site.standard.publication/self",
  "tags": [
    "javascript"
  ],
  "textContent": "Over the last two weeks at Disqus we discovered two\nannoying browser bugs. Both were only happening on iOS, which reminded me the\nfamous quote from Sherlock Holmes :\n“when you have eliminated the impossible, whatever remains, however improbable,\nmust be the truth”.\n\nThe first one was a bad one. We had reports from users not being able to login\nto our system from the embedded commenting widget, but only on iOS. The\nsymptoms were even stranger:\n\nUsers were shown the login page in a popup\n\nUsers could login and the cookie was set\n\nThe popup stayed open but notified the embed about the logged in user\n\nThe embed did not recognize the logged in user until after a refresh\n\nWe started debugging and discovered that the embed actually makes a call to\nget details of the logged in user after it gets the notification from the\npopup. However, the result of the request was never processed. More so, if you\nrefreshed the popup and then closed it, it worked!\n\nWe spent many hours in the iPhone emulator, mostly due to the cumbersome nature\nof all the emulators, we discovered that if you ever opened a popup and held a\nreference to it, iOS suspends the events on the parent page but still executes\nsome of the code. So, in our case, the XHR call was being made and the\nresponse was received, but the callback was not called. The cause of our bug\nreports was this callback being responsible for closing the login popup. The\nembed was dead-locked for waiting for the request to finish to close the popup\nand the browser was waiting for the popup to close to fire the callback. As you\ncan imagine, there were no visible reports of this behavior, anywhere on the\ninternets.\n\nThe other one was even weirder: we were seeing a certain content being repeated\nexactly three times whereas it should have appended to the DOM only once. The\nintermittent nature of the problem suggested a hard-to-track race condition but\nthat turned out not to be the case. We were able to mitigate the problem\neasily by emptying the parent element before appending the content. This was\nonly a symptomatic cure though so we proceeded on our adventure to find the root\ncause.\n\nAfter many hours of debugging, which was also very cumbersome due to the\nspecific “ritual” to reproduce it consistently, we traced the problem to the\nXHR success callback getting called 3 times with readyState == 4 instead of\nonly once. The new information suggested, surprise, a race condition, but\ntracking the number of XHR objects eliminated that possibility entirely.\n\nIt turns out that the onreadystatechange event was getting fired even though\nreadyState did not change at all. Not surprisingly, since this was happening\nat the completed state, the callback was fired multiple times for the same\nrequest. A Google search revealed another poor soul who encountered the same\nissue:\nhttps://github.com/madrobby/zepto/pull/633\n\nThere it was: a weird, hard-to-reproduce browser bug breaking our product\nrandomly. After realizing this fact, we went ahead and did what we had to do:\npatched Reqwest , the XHR library we\nuse at Disqus.",
  "title": "The \"Improbable\" Truth: Rare Browser Bugs"
}