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

Ensure that we cancel any pending rendering operations when the viewer is closed (issue 7274) #7514

Merged
merged 3 commits into from
Oct 11, 2016
Merged

Ensure that we cancel any pending rendering operations when the viewer is closed (issue 7274) #7514

merged 3 commits into from
Oct 11, 2016

Conversation

Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Jul 29, 2016

Tentative PR that fixes #7274.

@yurydelendik r?


This change is Reviewable

@Snuffleupagus Snuffleupagus changed the title Ensure that we cancel any pending rendering operation when the viewer is closed (issue 7274) Ensure that we cancel any pending rendering operations when the viewer is closed (issue 7274) Jul 29, 2016
@Snuffleupagus
Copy link
Collaborator Author

@yurydelendik Review ping?

/botio-linux preview

Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good after comments are addressed. Thanks

@@ -320,6 +331,7 @@ var PDFPageView = (function PDFPageViewClosure() {
draw: function PDFPageView_draw() {
if (this.renderingState !== RenderingStates.INITIAL) {
console.error('Must be in new state before drawing');
return Promise.resolve(undefined);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has a little bit weird meaning, can we replace it with reject or cache the promise returned below?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was simply trying to bring this code in line with the existing code in PDFThumbnailView, please see https://github.com/mozilla/pdf.js/blob/master/web/pdf_thumbnail_view.js#L277.
Do you want me to change both of them to e.g. Promise.reject(...) instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Not sure if we want to change both. For pages, we fall through to start new rendering (e.g. for different scale). For thumbs, we don't care about scale or if image is set after page rendering. Maybe we just leave it without change, just add comments for intent? Or, we reject in both cases, it try to catch places when we are failing during testing?

Copy link
Collaborator Author

@Snuffleupagus Snuffleupagus Sep 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to change both. For pages, we fall through to start new rendering (e.g. for different scale). For thumbs, we don't care about scale or if image is set after page rendering.

Really good point about the differences between pages/thumbnails! After thinking about this, I'm no longer sure that we want to make too many functional changes here.

The only change I've made in the updated patch, is to add a this.reset(); call for the PDFPageView case, since I believe that we probably want to ensure that we reset various state on fall-through (to avoid weird state with e.g. multiple text/annotation layers).
Please do let me know if you don't think this is appropriate!

@@ -135,15 +135,16 @@ var PDFThumbnailViewer = (function PDFThumbnailViewerClosure() {
this.thumbnails = [];
this._pagesRotation = 0;
this._pagesRequests = [];

var container = this.container;
while (container.hasChildNodes()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.container.textContent = ''; -- I think it will be easier to read (we can prefix it with the comment about the intent)

Copy link
Collaborator Author

@Snuffleupagus Snuffleupagus Sep 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the above, I was trying to make this file use the same form as the existing code in PDFViewer, please see https://github.com/mozilla/pdf.js/blob/master/web/pdf_viewer.js#L419.
Do you want both of those files changed here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, let's change both here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated both files.

Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Can you revert change with !PRODUCTION? I'll refactor that later.

if (true) {
return;
}
//#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to keep this if to preserve functionality in the non-build viewer

…id having to manually get that information in the event handler
@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/29bc541a93a2030/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/29bc541a93a2030/output.txt

Total script time: 0.99 mins

Published

@timvandermeij
Copy link
Contributor

Merging with r=yurydelendik. Thank you for the patch!

@timvandermeij timvandermeij merged commit 8c5b925 into mozilla:master Oct 11, 2016
@Snuffleupagus Snuffleupagus deleted the viewer-abort-rendering-on-close branch October 12, 2016 10:25
movsb pushed a commit to movsb/pdf.js that referenced this pull request Jul 14, 2018
…ring-on-close

Ensure that we cancel any pending rendering operations when the viewer is closed (issue 7274)
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.

"TypeError: pageView is undefined" during pdf.js tests
4 participants