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

Modify a number of the viewer preferences, whose current default value is 0, such that they behave as expected with the view history #10502

Merged
merged 5 commits into from
Feb 4, 2019

Commits on Feb 2, 2019

  1. Change PDFSidebar.switchView to act as a wrapper for a "private" `P…

    …DFSidebar._switchView` method
    
    The new "private" method will return a boolean, indicating if the `sidebarviewchanged` event was dispatched, thus allowing some simplification of the `PDFSidebar.setInitialView` method.
    Snuffleupagus committed Feb 2, 2019
    Configuration menu
    Copy the full SHA
    dd46205 View commit details
    Browse the repository at this point in the history
  2. Modify a number of the viewer preferences, whose current default valu…

    …e is `0`, such that they behave as expected with the view history
    
    The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts.
    Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part.
    At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof.
    
    As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately.
    
    Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
    Snuffleupagus committed Feb 2, 2019
    Configuration menu
    Copy the full SHA
    6806248 View commit details
    Browse the repository at this point in the history
  3. Attempt to migrate the old showPreviousViewOnLoad/disablePageMode

    … preferences to the new `viewOnLoad` preference
    
    This patch ignores the recently added `disableOpenActionDestination` preference, since the latest PDF.js version found on the "Chrome Web Store" doesn't include it.
    Snuffleupagus committed Feb 2, 2019
    Configuration menu
    Copy the full SHA
    4d4c98d View commit details
    Browse the repository at this point in the history
  4. Move the PDFHistory initialization into a helper method in `PDFView…

    …erApplication`
    
    This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
    Snuffleupagus committed Feb 2, 2019
    Configuration menu
    Copy the full SHA
    9d83420 View commit details
    Browse the repository at this point in the history
  5. Re-factor how the "compatibility" values are specified in AppOptions

    The intention with this change is to, more clearly, highlight when the default values may possibly be overridden by "compatibility" values.
    Snuffleupagus committed Feb 2, 2019
    Configuration menu
    Copy the full SHA
    ef634b5 View commit details
    Browse the repository at this point in the history