akira/pdfjs-dist - pdfjs-dist - Gitea: Git with a cup of tea

Tree: 3dd4764158

Author	SHA1	Message	Date
Manas	a2ba1b8189	Uses editorconfig to maintain consistent coding styles Removes the following as they unnecessary /* -- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -- / / vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */	10 years ago
Rob Wu	cdea75dc39	Refactor the previous history rewriting logic When the user edits the URL and changes the reference fragment (hash), PDF.js intercepts this action, and saves the then-current history state in the previous history entry. This is implemented by navigating back, editing the history and navigating forward again. The current logic has a flaw: It assumes that calling history.back() and history.forward() immediately updates the history state. This is however not guaranteed by the web standards, which states that calling e.g. history.back "must traverse the history by a delta -1", which means that the browser must QUEUE a task to traverse the session history, per spec: http://w3.org/TR/2011/WD-html5-20110113/history.html#dom-history-back https://html.spec.whatwg.org/multipage/browsers.html#dom-history-back Firefox and Internet Explorer deviate from the standards by immediately changing the history state instead of queuing the navigation. WebKit derived browsers (Chrome, Opera, Safari) and Opera presto do not. The user-visible consequence of strictly adhering to the standards in PDF.js can be shown as follows: 1. Edit the URL. 2. Append #page=2 for example. 3. Press Enter. -> Presto and WebKit: PDF.js reverts to the previous URL. -> Gecko and Trident: PDF.js keeps the new URL, as expected. To fix the issue, modification of the previous history item happens in a few asynchronous steps, guided by the popstate event to detect when the history navigation request has been committed. -- Some more implementation notes: I have removed the preventDefault and stopPropagation calls, because popstate is not cancelable, and window is already the last target of the event propagation. The previous allowHashChange logic was hard to follow, because it did not explain that hashchange will be called twice; once during the popstate handler for history.back() (which will reset allowHashChange), and again for history.forward() (where allowHashChange will be false). The purpose of allowHashChange is now more explicit, by incorporating the logic in the replacePreviousHistoryState helper function.	10 years ago
Rob Wu	adb2f8ae21	[CRX] Add Referer request header if needed This patch adds the Referer request header to PDF requests if the original PDF request included the Referer header.	10 years ago
Yury Delendik	5cff06e52a	Refactors PDFHistory. # Conflicts: # extensions/b2g/viewer.js # web/pdf_history.js # web/pdf_viewer.component.js # web/viewer.js	10 years ago
Jonas Jenwald	2dc1af8028	Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.	10 years ago
Yury Delendik	44779f14b0	Renames and refactors PDFView to PDFViewerApplication.	11 years ago
Rob Wu	aeaf11ca43	[CRX] Fall back to sender.tab.url if !tab.url sender.url is relatively new (Chromium 29) ( https://chromiumcodereview.appspot.com/14301016 )	11 years ago
Rob Wu	8526d3c600	[CRX] Add a pageAction to omnibox showing PDF URL In Chromium extensions, the viewer's URL looks like this: chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf Furthermore, the PDF Viewer itself can also add something to the reference fragment: chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf#page=2 Consequently, it is difficult to copy a clean URL (e.g. for sharing over mail) without having to tidy-up the URL manually. This commit solves this issue by adding a button to the omnibox, which shows the clean PDF URL on click.	12 years ago
Jonas Jenwald	44725d4657	[PDFHistory] Fix "Warning: Unhandled rejection: [Exception... "The operation is insecure."" in Firefox 25	12 years ago
Jonas Jenwald	ca8e3ea06f	[PDFHistory] Fix "Warning: Unhandled rejection: [Exception... "The operation is insecure."" when opening local file	12 years ago
Jonas Jenwald	bfc66626a0	Move Presentation Mode related code from viewer.js to its own file	12 years ago
Jonas Jenwald	fc73dbe695	[PDFHistory] Prevent the history from skipping entries in certain edge cases, when specifying an initialBookmark in the hash parameters on document load	12 years ago
Rob Wu	c653bf3aff	Set URL in history.replaceState/pushState When <base href> is present, history.replaceState and history.pushState behave inconsistent with relative URLs. http://code.google.com/p/chromium/issues/detail?id=274024 Contrary to what one expect, passing '' as the URL parameter to replaceState/pushState does not associate the currently active URL with the history entry, but a path relative to <base href>. To fix the issue, explicitly associate the current active URL with the history's state.	12 years ago
Yury Delendik	fa885678df	Don't provide optional pushState parameter	12 years ago
Jonas	869c4de289	[PDFHistory] Prevent the history from getting stuck in certain edge cases	12 years ago
Jonas	d99b7753d6	Check if viewer is embedded only once and cache the result	12 years ago
Jonas	09e0c9b65d	Move PDFHistory from viewer.js to its own file	12 years ago