{"push_id":725974588,"size":1,"distinct_size":1,"ref":"refs/heads/hashchange-use-newURL","head":"6da37b8e5f4af14dcf73cc5ae37a60a6bc22d3bf","before":"fcb7f6138416811cb2db0ccd451b3947b768b209","commits":[{"sha":"6da37b8e5f4af14dcf73cc5ae37a60a6bc22d3bf","author":{"email":"7e09c9d3e96378bf549fc283fd6e1e5b7014cc33@robwu.nl","name":"Rob Wu"},"message":"Refactor the previous history rewriting logic\n\nWhen the user edits the URL and changes the reference fragment (hash),\nPDF.js intercepts this action, and saves the then-current history state\nin the previous history entry. This is implemented by navigating back,\nediting the history and navigating forward again.\n\nThe current logic has a flaw: It assumes that calling history.back() and\nhistory.forward() immediately updates the history state. This is however\nnot guaranteed by the web standards, which states that calling e.g.\nhistory.back \"must traverse the history by a delta -1\", which means that\nthe browser must QUEUE a task to traverse the session history, per spec:\nhttp://w3.org/TR/2011/WD-html5-20110113/history.html#dom-history-back\nhttps://html.spec.whatwg.org/multipage/browsers.html#dom-history-back\n\nFirefox and Internet Explorer deviate from the standards by immediately\nchanging the history state instead of queuing the navigation.\nWebKit derived browsers (Chrome, Opera, Safari) and Opera presto do not.\n\nThe user-visible consequence of strictly adhering to the standards in\nPDF.js can be shown as follows:\n\n1. Edit the URL.\n2. Append #page=2 for example.\n3. Press Enter.\n   -> Presto and WebKit: PDF.js reverts to the previous URL.\n   -> Gecko and Trident: PDF.js keeps the new URL, as expected.\n\nTo fix the issue, modification of the previous history item happens in\na few asynchronous steps, guided by the popstate event to detect when\nthe history navigation request has been committed.\n\n--\nSome more implementation notes:\n\nI have removed the preventDefault and stopPropagation calls, because\npopstate is not cancelable, and window is already the last target of the\nevent propagation.\n\nThe previous allowHashChange logic was hard to follow, because it did\nnot explain that hashchange will be called twice; once during the\npopstate handler for history.back() (which will reset allowHashChange),\nand again for history.forward() (where allowHashChange will be false).\nThe purpose of allowHashChange is now more explicit, by incorporating\nthe logic in the replacePreviousHistoryState helper function.","distinct":true,"url":"https://api.github.com/repos/Rob--W/pdf.js/commits/6da37b8e5f4af14dcf73cc5ae37a60a6bc22d3bf"}]}