1. 09 Jun, 2016 2 commits
    • Nick Stenning's avatar
      Use document fingerprint, not URL, as primary URI for PDFs · c4ad6cdc
      Nick Stenning authored
      Consider the following situation:
      
      - A PDF with fingerprint (F) exists at multiple URLs (U1, U2, ...)
      - A user visits the PDF at U1 and annotates it
      - A second user visits the PDF at U2
      
      Prior to this commit, due to the way document equivalence for PDFs
      functions, the annotations made at U1 will not be loaded, because the
      initial search is made for U2 only.
      
      (If the second user subsequently makes annotations at U2, and then
      reloads the page, the annotations made at U1 will then show up, as the
      association between U2 and F will have been made).
      
      This commit improves the situation here by treating the PDF fingerprint
      as the "primary URI" for the document, much as we treat <link
      rel="canonical"> URLs as "primary" if we find them in an HTML page.
      
      This means that the initial search will be made for the fingerprint F,
      which will match the annotations made at U1.
      
      For more, see:
      
        https://trello.com/c/DVUemKwi/329-use-pdf-fingerprint-as-primary-search-uri-for-pdfs
      c4ad6cdc
    • Sheetal Umesh Kumar's avatar
      Move PDF metadata extraction into a separate service · 533b5f4b
      Sheetal Umesh Kumar authored
      In order to make it easier to change the document metadata retrieved for
      PDFs, this commit moves the code responsible for extracting that
      metadata into a separate (tested) service.
      
      We also remove our reliance on the `PDFViewerApplication.loading` which
      was removed from the bundled version of PDF.js in August 2015. Instead
      we simply check to see if `PDFViewerApplication.documentFingerprint` is
      available. If not, we listen for the first 'documentload' event before
      extracting metadata from the `PDFViewerApplication`.
      533b5f4b
  2. 07 Jun, 2016 3 commits
  3. 06 Jun, 2016 3 commits
    • Robert Knight's avatar
      Implement new design for hovered conversation threads (#3376) · a3f910d3
      Robert Knight authored
      * Implement new design for hovered conversation threads
      
      Implement the new design for hovered replies from
      https://trello.com/c/aXCXxzx2 .
      
      The most visible effect is that conversation threads have a grey
      background when hovered.
      
      In the process of implementing the new styling, there is some cleanup
      of the CSS:
      
       * Use `--reply`/`--top-reply` modifier classes on <annotation> and
         <annotation-thread> elements to style annotations, top-level replies
         and nested replies differently. This makes the CSS simpler and
         reduces the risk of unexpected side effects that come with descendant
         selectors.
      
       * Rename `thread` CSS classes to match the name of the component
         that they are used in, `annotation-thread`.
      
      * Move 'annotation-unavailable-message' styling to app.scss
      
      This class is used in the root template (viewer.html) not the
      <annotation-thread> component.
      
      * Darken expand/collapse toggle arrow only when annotation itself is hovered
      
      Darken the expand/collapse arrow when an annotation is hovered but not
      when its replies are hovered.
      
      * Remove no-op CSS class
      
      The `clear: both` styling had no effect because <annotation-thread>
      is now using flexbox rather than floats for layout.
      
      * Do not show 'Hide replies' link for replies
      
      For replies there were two different ways to collapse the annotation
      card, the expand/collapse toggle arrow and the 'Hide replies' link.
      
      Removing the 'Hide replies' link avoids having two ways to do the same
      thing and makes the cards look cleaner.
      
      * Remove the light grey background for hovered replies
      
      Following design review, remove the grey background for hovered replies.
      
      * Make rendering of dashed lines to the left of replies better in Chrome
      
      Previously the dashed line started at the top of the <annotation-thread>
      component and the top part was covered up by the thread expand/collapse
      toggle.
      
      In Chrome the alignment of dashes within a dashed border varies as the
      height of the element changes [1]. Therefore depending on the height of
      the reply, this could result in the visible part of the line below the
      collapse/expand toggle starting at either a gap or dash in the line.
      
      By instead moving the dashed line to a separate element which is
      positioned beneath the expand/collapse toggle, the first visible dash in
      the reply line always appears in the same place and is aligned correctly
      with the annotation content to its right.
      
      [1] See http://www.impressivewebs.com/comparison-css-border-style/
          for a visual representation of why this is done.
      a3f910d3
    • Robert Knight's avatar
      Add integration test for anchoring (#3377) · d6f1a7ec
      Robert Knight authored
      This adds an integration test for anchoring of annotations loaded
      into the annotator guest via the sidebar.
      
      This was extracted from https://github.com/hypothesis/h/pull/3313
      
      The test case for nested annotations has been marked as an expected
      failure until a better resolution for #3278 has been found.
      d6f1a7ec
    • Robert Knight's avatar
      Merge pull request #3402 from hypothesis/fix-phantom-404s · 24495385
      Robert Knight authored
      Fix distracting 404s in karma/phantom test output
      24495385
  4. 03 Jun, 2016 4 commits
  5. 02 Jun, 2016 5 commits
  6. 01 Jun, 2016 10 commits
  7. 31 May, 2016 1 commit
  8. 30 May, 2016 11 commits
  9. 27 May, 2016 1 commit