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

Return undefined instead of Dict.empty from Page.getInheritedPageProp for non-existent properties to prevent possible future bugs #8129

Merged
merged 1 commit into from
Mar 4, 2017

Conversation

Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Mar 4, 2017

This is something that I noticed while working on PR #8126, which is (more) fallout from PR #6065.

In general, it's actually not correct to return Dict.empty as the default value for non-existent properties. Please note that a prior PR, see #5957 (comment), asked for that behaviour but I don't think that's right.

Obviously for properties that are (or should) be Dicts it makes sense, however certain properties can be e.g. Strings or Arrays instead. In the latter case, returning Dict.empty is just plain wrong, and it's quite fascinating that this hasn't caused any errors in practice. (The existing validation in the various getters has actually saved us here.)

Also, when looking at this code again, it seemed unnecessary to duplicate the MAX_LOOP_COUNT check since we could just return immediately instead.

…eProp` for non-existent properties to prevent possible future bugs

*This is something that I noticed while working on PR 8126, which is (more) fallout from PR 6065.*

In general, it's actually *not* correct to return `Dict.empty` as the default value for non-existent properties. Please note that a prior PR, see #5957 (comment), asked for that behaviour but I don't think that's right.

Obviously for properties that are (or should) be `Dict`s it makes sense, however certain properties can be e.g. Strings or Arrays instead. In the latter case, returning `Dict.empty` is just plain wrong, and it's quite fascinating that this hasn't caused any errors in practice. (The existing validation in the various getters has actually saved us here.)

Also, when looking at this code again, it seemed unnecessary to duplicate the `MAX_LOOP_COUNT` check since we could just return immediately instead.
@Snuffleupagus
Copy link
Collaborator Author

/botio test

@pdfjsbot
Copy link

pdfjsbot commented Mar 4, 2017

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/223ef3835fe8c42/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Mar 4, 2017

From: Bot.io (Windows)


Received

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

Live output at: http://54.215.176.217:8877/8db480e3655da0a/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Mar 4, 2017

From: Bot.io (Windows)


Success

Full output at http://54.215.176.217:8877/8db480e3655da0a/output.txt

Total script time: 22.31 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

@pdfjsbot
Copy link

pdfjsbot commented Mar 4, 2017

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/223ef3835fe8c42/output.txt

Total script time: 28.49 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

@timvandermeij timvandermeij merged commit 4e3e97b into mozilla:master Mar 4, 2017
@timvandermeij
Copy link
Contributor

Looks good. Thank you for the fix!

@Snuffleupagus Snuffleupagus deleted the getInheritedPageProp-undefined branch March 4, 2017 15:48
movsb pushed a commit to movsb/pdf.js that referenced this pull request Jul 14, 2018
…op-undefined

Return `undefined` instead of `Dict.empty` from `Page.getInheritedPageProp` for non-existent properties to prevent possible future bugs
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