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

Tree: 19f56ec5c1

Author	SHA1	Message	Date
Jonas Jenwald	223c429357	Fix inconsistent spacing and trailing commas in objects in `web/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in in one big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/web/pdf_thumbnail_view.js b/web/pdf_thumbnail_view.js index 002dbf29..1de4e530 100644 --- a/web/pdf_thumbnail_view.js +++ b/web/pdf_thumbnail_view.js @@ -420,8 +420,8 @@ var PDFThumbnailView = (function PDFThumbnailViewClosure() { setPageLabel: function PDFThumbnailView_setPageLabel(label) { this.pageLabel = (typeof label === 'string' ? label : null); - this.l10n.get('thumb_page_title', { page: this.pageId, }, 'Page {{page}}'). - then((msg) => { + this.l10n.get('thumb_page_title', { page: this.pageId, }, + 'Page {{page}}').then((msg) => { this.anchor.title = msg; }); diff --git a/web/secondary_toolbar.js b/web/secondary_toolbar.js index 160e0410..6495fc5e 100644 --- a/web/secondary_toolbar.js +++ b/web/secondary_toolbar.js @@ -65,7 +65,8 @@ class SecondaryToolbar { { element: options.printButton, eventName: 'print', close: true, }, { element: options.downloadButton, eventName: 'download', close: true, }, { element: options.viewBookmarkButton, eventName: null, close: true, }, - { element: options.firstPageButton, eventName: 'firstpage', close: true, }, + { element: options.firstPageButton, eventName: 'firstpage', + close: true, }, { element: options.lastPageButton, eventName: 'lastpage', close: true, }, { element: options.pageRotateCwButton, eventName: 'rotatecw', close: false, }, @@ -76,7 +77,7 @@ class SecondaryToolbar { { element: options.cursorHandToolButton, eventName: 'switchcursortool', eventDetails: { tool: CursorTool.HAND, }, close: true, }, { element: options.documentPropertiesButton, - eventName: 'documentproperties', close: true, } + eventName: 'documentproperties', close: true, }, ]; this.items = { firstPage: options.firstPageButton, ```	8 years ago
Yury Delendik	5438ce9b98	Wraps mozL10n to async calls; splits firefox and generic l10n libs.	8 years ago
Tim van der Meij	26ad82f5c2	Convert the sidebar to ES6 syntax	8 years ago
Yury Delendik	8e681ce3e2	Change amd to cjs path in ES6 modules	8 years ago
Jonas Jenwald	3b35c15d42	Convert the files in the `/web` folder to ES6 modules Note that as discussed on IRC, this makes the viewer slightly slower to load only in `gulp server` mode, however the difference seem slight enough that I think it will be fine.	8 years ago
Jonas Jenwald	616e5fadff	Display a notification on the `sidebarToggle` button for PDF documents with outline/attachments A longstanding issue with the viewer is that you cannot tell if a PDF document includes an outline and/or attachments without actually opening the sidebar. This patch contains a suggested solution for that, by displaying an hide-on-interaction notification on the `sidebarToggle` button (and the relevant sidebar view buttons). Note that this was inspired by e.g. the update notification that is displayed on the menu button in Firefox. For an initial implementation, I've tried to do this in such a way that the notification isn't too distracting. Without being an UX expert, I don't think that we'd want something too in-your-face, in order to keep the viewer toolbars reasonable clean. (We probably do not want e.g. an entire notification bar in these situations, since that would take up unnecessary screen space and require actions from the user to close.) However it's certainly possible that the current notification might simply be too inconspicuous to be truly helpful to users, but we could probably iterate on that if the feature itself is deemed useful.	8 years ago
Yury Delendik	7fd3db9977	Adds EventBus.	9 years ago
Jonas Jenwald	5657d082c7	Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the viewer, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.	9 years ago
Yury Delendik	006e8fb59d	Introduces UMD headers to the web/ folder.	9 years ago
Jonas Jenwald	39cba5d25d	Remove `PDFThumbnailViewer_ensureThumbnailVisible` Functionality wise, `ensureThumbnailVisible` is essentially just a shorthand for `scrollThumbnailIntoView`. (And note that `PDFViewer` doesn't implement a `ensurePageVisible` method.) The only remaining usage of `PDFThumbnailViewer_ensureThumbnailVisible` is inside `PDFPresentationMode`, which introduces an otherwise unnecessary `PDFThumbnailViewer` dependency there. We're already relying on the `presentationmodechanged` event, in various files, to track the state of Presentation Mode. Thus we can simply listen for that event in `PDFSidebar` too, and update the thumbnails if necessary.	9 years ago
Jonas Jenwald	67a1dfcfb5	Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` and `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.	9 years ago