1. 29 Oct, 2015 7 commits
    • Robert Knight's avatar
      Avoid reloading whole view when focused group changes · d0099f12
      Robert Knight authored
      When the focused group changes, instead of reloading the whole
      view just unload the currently displayed annotations and then
      reload the annotations for the newly selected group(s) and
      any drafts of unsaved annotations.
      
      The only immediately 'visible' effect of the change is
      that switching groups now only results in a call to /search
      rather than network requests to fetch session state and features.
      
      In future this should make it easier to preserve state
      for the area below the top bar when switching groups.
      d0099f12
    • Nick Stenning's avatar
      Merge pull request #2684 from hypothesis/gh2675-wait_for_features · fc913bb3
      Nick Stenning authored
      Wait for feature flag data before loading sidebar view
      fc913bb3
    • Nick Stenning's avatar
      Merge pull request #2683 from hypothesis/document_link_refactor · d11c2dfa
      Nick Stenning authored
      Document link refactor
      d11c2dfa
    • Robert Knight's avatar
      Clear features cache only when logged in user changes · 4c04077d
      Robert Knight authored
      Clear the features cache only when the logged-in user changes,
      rather than on any change to session data.
      4c04077d
    • Robert Knight's avatar
      Wait for feature flag data before loading sidebar view · 7299b4d8
      Robert Knight authored
      Feature flags can affect the initial search query when
      the app loads. eg. If the groups feature is enabled then
      we will by default load annotations for the most recently
      used group, otherwise we'll load public annotations.
      
      Therefore, wait for the feature flags to be retrieved
      before loading the view.
      
      The feature flags endpoint is very fast so the behavior
      was correct most of the time previously but occassionally
      the app would load and fetch Public annotations before
      the feature data was available which would have resulted
      in fetching group annotations.
      
      At the same time, this clears the feature flag data
      when the current user changes and fixes an issue where
      switching from a non-groups enabled account to a groups-enabled
      account did not immediately update the UI.
      
      Fixes #2675
      7299b4d8
    • Nick Stenning's avatar
      Merge pull request #2688 from robertknight/groups_changed_exception · c6975968
      Nick Stenning authored
      Fix exception when GROUPS_CHANGED event is broadcast during route load
      c6975968
    • Robert Knight's avatar
      Fix exception when GROUPS_CHANGED event is broadcast during route load · e30dffdd
      Robert Knight authored
      The <group-list> directive attempted to update itself in
      response to a group change notification without triggering
      a full digest cycle by using `$scope.$apply`.
      
      This was based on the incorrect understanding that $apply only
      dirty-checks the current scope downwards. In fact, in dirty-checks
      the root scope. Additionally, the logic was pointless since
      group list/focus changes happen in response to two types of events,
      both of which are triggered in the context of $apply:
      
       * An event handler when the user selects a group
      
       * A callback from angular-websocket when a WebSocket message
         is received.
      e30dffdd
  2. 28 Oct, 2015 6 commits
  3. 27 Oct, 2015 18 commits
  4. 26 Oct, 2015 6 commits
  5. 24 Oct, 2015 1 commit
    • Robert Knight's avatar
      Fix flash of unlinked template when changing groups · fe754ac8
      Robert Knight authored
      When an app reload occurs, the 'Clear Search' and
      'Clear Selection' buttons would sometimes flash.
      
      This occurred due to an issue where the initial
      call to the watcher registered by ng-show to hide
      the buttons being invoked asynchronously in some cases.
      
      When the app's route is loaded, the following happens:
      
       1) viewer.html is compiled
       2) viewer.html is linked
       3) Watchers registered by directives during (1) and (2)
          are run. For the watchers registered by 'ng-show',
          this applies the .nghide CSS class that hides
          elements.
      
      On initial app load, 1-3 all happen synchronously in the
      same scope.$digest cycle. However, when logging in with
      an incorrect password, 1 & 2 happened in the same cycle
      but 3 happened in a separate cycle, with DOM rendering
      taking place in a flash between before the directive
      was fully ready.
      
      The GitHub issue has more detail and there is some
      connection to the 'deepCount' directive but I decided
      not to alter that here without sufficient understanding
      of the consequences.
      
      This commit fixes the issue by applying the 'nghide'
      class to the viewer.html initially and then letting
      ng-show _remove it_ when its watcher runs. This fixes
      the flash when 1-2 and 3 happen in separate digest cycles
      and has no effect if they run in the same cycle.
      
      Fixes #2642
      fe754ac8
  6. 23 Oct, 2015 2 commits