Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore 'change' events that didn't originate in the viewer (issue 8915) #8919

Merged
merged 1 commit into from
Sep 17, 2017
Merged

Ignore 'change' events that didn't originate in the viewer (issue 8915) #8919

merged 1 commit into from
Sep 17, 2017

Conversation

Snuffleupagus
Copy link
Collaborator

Rather that registering a 'change' event listener on the window, which will thus (unnecessarily) fire in a number of other situations such as e.g. when the user changes the pageNumber or the current search term, we could/should just register it directly on the dynamically created fileInput DOM element instead.
I can see no really compelling reason why we actually need to listen for file changes on the window itself, and this way we're also able to keep the fileInput related code confined to one part of the code which should aid readability.
Furthermore, in custom deployments, there's less risk that we're going to interfere with "outside" code this way.

Finally, preprocessor guards were added to the webViewerOpenFile function, since that code doesn't make sense in e.g. the extension builds.

Fixes #8915.

Rather that registering a 'change' event listener on the `window`, which will thus (unnecessarily) fire in *a number* of other situations such as e.g. when the user changes the pageNumber or the current search term, we could/should just register it directly on the dynamically created `fileInput` DOM element instead.
I can see no really compelling reason why we actually need to listen for `file` changes on the `window` itself, and this way we're also able to keep the `fileInput` related code confined to one part of the code which should aid readability.
Furthermore, in custom deployments, there's less risk that we're going to interfere with "outside" code this way.

Finally, preprocessor guards were added to the `webViewerOpenFile` function, since that code doesn't make sense in e.g. the extension builds.
@Snuffleupagus
Copy link
Collaborator Author

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/72cc47020b8cdbb/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/72cc47020b8cdbb/output.txt

Total script time: 2.52 mins

Published

@timvandermeij timvandermeij merged commit c84c23c into mozilla:master Sep 17, 2017
@timvandermeij
Copy link
Contributor

Thank you for fixing this!

@Snuffleupagus Snuffleupagus deleted the issue-8915 branch September 17, 2017 13:39
movsb pushed a commit to movsb/pdf.js that referenced this pull request Jul 14, 2018
Ignore 'change' events that didn't originate in the viewer (issue 8915)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants