Steps to reproduce

1. Browse to: https://via.hypothes.is/bibliobs.nouvelobs.com/paroles-d-haiti/20100121.BIB4760/tout-bouge-autour-de-moi.html
2. Select text and annotate.

Expected behaviour

Editor should appear.

Actual behaviour

Clicking annotate does not launch the editor.

Browser/system information

Version:
0.44.0
User agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36
URL:
http://bibliobs.nouvelobs.com/paroles-d-haiti/20100121.BIB4760/tout-bouge-autour-de-moi.html
Username:
dwhly
Date:
26 Sep 2016 06:53:05 -0700

Additional details

It appears that there is another js app running that is responsive to selection events and there may be a conflict.

Console shows this error: "nobs;manifest.js?_t=1474889101:2 Uncaught TypeError: Cannot read property 'preventDefault' of undefined"

handleCommand @ hypothes.is/assets/client/scripts/injector.bundle.js?bb3e58:422
r @ nobs;manifest.js?_t=1474889101:2
(anonymous function) @ nobs;manifest.js?_t=1474889101:2

This zendesk ticket: https://hypothesis.zendesk.com/inbox/conversations/639

@jeremydean

Steps to reproduce

1. Go here: https://hypothes.is/users/dwhly/search?q=uri%3Ahttps%3A%2F%2Fmyhealthonline.sutterhealth.org%2Fmho%2Finside.asp%3Fmode%3Dlabdetail%26orderid%3D2
2. Click on the document to expand

Expected behaviour

The card should be wider

Actual behaviour

It's narrow.

Browser/system information

Chrome

Steps to reproduce

1. Visit https://www.theguardian.com/environment/2016/aug/02/environment-climate-change-records-broken-international-report and activate production Chrome extension
2. Check error console

Anchoring of an annotation containing the body "melting in summer" fails with this error in the console:

es6.promise.js:127 Unhandled promise rejection TypeError: Cannot read property 'nodeType' of undefined
    at Object.Util.getFirstTextNodeNotBefore (chrome-extension://pnnolcckhgcenejopdkchlggkhidmogi/public/scripts/injector.bundle.js?30ac63:4104:14)
    at BrowserRange.Range.BrowserRange.BrowserRange.normalize (chrome-extension://pnnolcckhgcenejopdkchlggkhidmogi/public/scripts/injector.bundle.js?30ac63:4475:24)
    at chrome-extension://pnnolcckhgcenejopdkchlggkhidmogi/public/scripts/injector.bundle.js?30ac63:1366:29
    at chrome-extension://pnnolcckhgcenejopdkchlggkhidmogi/public/scripts/injector.bundle.js?30ac63:1072:24(anonymous function) @ es6.promise.js:127
es6.promise.js:127 Unhandled promise rejection TypeError: Cannot read property 'nodeType' of undefined(…)(anonymous function) @ es6.promise.js:127

Browser

Chrome v52.0.2716.0

Interestingly I don't see this error when visiting the same page with Via.

Steps to reproduce

1. Visit a direct link when not logged in to Hypothesis

Expected behaviour

Client should establish a WebSocket connection to wss://hypothes.is/ws

Actual behaviour

Client will in most cases fail to establish a WebSocket connection

Browser/system information

Firefox v50

Additional details

This happens because if the user is not logged in, the sidebar only connects when it is opened. If however the sidebar is already open by the time that the request for the user's session data completes, the "sidebarOpened" event will not be received by WidgetController and hence the sidebar will not connect.

Steps to reproduce

1. Select text and click to annotate midway down on a reasonably well annotated page, like this: https://via.hypothes.is/https://www.commonsense.org/education/privacy/blog/digital-redlining-access-privacy
2. Wait for someone else to make an annotation on the page while the editor is open

Expected behaviour

My editor should stay put, so I can compose my annotation

Actual behaviour

It jumps around, occasionally scrolling out of view

Browser/system information

Modern chrome, via.

Additional details

Video: https://drive.google.com/file/d/0B0yW-dSdEYAcM1BWMTZUUGpRWVk/view

cc @jeremydean

Steps to reproduce

1. Go here: http://ccc.coastal.edu/index.php/task/102-badge-3-2/

Expected behaviour

Sidebar displays normally

Actual behaviour

Issues with sidebar icons

Browser/system information

Chrome

1. While logged out, create a highlight.
2. Still logged out, create another highlight.

Result: creating the second highlight deletes the first.

Expected: the way this used to work was:

• You could create as many highlights as you want while logged out
• These would stack up as multiple "You must be signed in to create annotations" cards in the sidebar which you wouldn't see because the sidebar is closed
• If you have the sidebar open while you're highlighting don't worry - it'll close itself! :)
• When you do finally sign in all your highlights are saved to the server
• But if you browse to another page or close the window or tab all your highlights are silently deleted

Here I double click on the word "annotating". The highlight is the wrong size (it's the size of the word "bug"). When I then click to make an annotation, the annotation then gets "bug" not "annotating" as its target text.

(This looks like it might be an issue with selecting text in PDF.js)

Steps to reproduce

1. Given an account for which the orphans_tab feature flag is enabled, activate the H client on a long PDF with many annotations
2. Open the sidebar as soon as possible and observe the Annotations and Orphans tab

Observed behavior: Many annotations initially appear in the Orphans tab and then "move" to the Annotations tab one-by-one.

Background

Annotations can take several seconds to anchor in long PDFs, because anchoring annotations involves rendering pages of a PDF to text which can be slow.

While annotations are anchoring, the sidebar does not display them - since it is unknown whether they should appear in the Annotations or Orphans tab. After 500ms however, annotations that are still anchoring are automatically marked (at least temporarily) as orphans. This ensures that annotations are eventually displayed in the sidebar if an error occurs during anchoring in the page (eg. due to a bug in the client or problems caused by the page's own JS or DOM structure).

On long PDFs, the result is that annotations may initially appear in the Orphans tab, then transfer one-by-one to the Annotations tab as anchoring completes.

Possible solutions

1. Increase the anchoring timeout if the connected document is a PDF. This would result in annotations not appearing in the UI at all until they have been anchored, but would at least avoid them appearing in the wrong tab.
2. Display both Annotations and Orphans in the Annotations tab in PDFs to avoid them moving between tabs while anchoring completes. Orphans are still displayed with a struck-through quote to indicate that they have not been located in the document. This would result in all annotations displaying in the Annotations tab instantly, but there would be a visual cue indicating whether an annotation can be scrolled to by clicking it
3. Pretend that annotations always anchor in PDFs. This means always display them like an anchored annotation, even if they have not been located yet. This would result in all annotations displaying in the Annotations tab instantly, but would provide no visual cue as to whether clicking on an annotation will scroll to it

Steps to reproduce

1. Create tag pages:85
2. Try to create tag pages:8

Expected behaviour

I can create the tag pages:8 if pages:85 is a remembered tag

Actual behaviour

It always becomes pages:85

Additional details

http://jonudell.net/h/tag-pages8-vs-pages85.mp4

Steps to reproduce

1. Highlight to annotate
2. write the notes
3. click on "Public" to save

Expected behaviour

The annotation get saved and stays there after the page has been refreshed.

Actual behaviour

"Saving..." shows up on the lower right corner of the annotation and stays there. Only the latest annotation can be selected if there are multiple annotations. Sometimes It goes back to the edit mode on the latest annotation. These annotations are considered to be drafts and warning shows up when trying to log out.

Browser/system information

Google Chrome: Version 53.0.2785.101 m (64-bit), Windows 10
hypothesis/client commit-id: 26327ae
hypothesis/h commit-id: 5774a2489d656c5937f40205e90e2581d9489478
client is trying to save from another domain. The CORS is resolved using nginx on the server.
client is authenticated but it throws 401 Unauthorized error on trying to request : '/api/token'. This is an known issue for cross domain as per the comment in the source code.

I could not reproduce the behavior on a dev environment where client is linked to h and running on port 3000

Steps to reproduce

1. Create an annotation at the start of a paragraph.
2. Triple-click to select the whole paragraph and click annotate.
3. [Observe no editor -- the annotation is apparently in the orphans tab.] Switch to another group.
4. [Observe annotation editor.] Switch back to prior group.
5. [Observe annotation editor.] Complete and save annotation.
6. [Observe annotation in "page notes" tab.]

Expected behaviour

I'd expect:

• the selection on the page (in blue) to reflect the selected text of the annotation -- in this case it appears the annotation has no selection
• the visibility of the editor shouldn't change when switching groups
• the orphan/non-orphan status shouldn't change when switching groups
• the annotation/page note classification shouldn't change when saving an annotation

Actual behaviour

Here's a screencast of me following the above steps using client master:

Browser/system information

• Version: 0.42.0
• User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2859.0 Safari/537.36
• URL: https://localhost:5000/docs/help
• Username: foo
• Date: 15 Sep 2016 12:07:05 +0200

Screencast

http://jonudell.net/h/browser-a-kills-in-progress-annotation-in-browser-b.mp4

Setup:

• Left browser: user jonudell, chrome extension
• Right browser: user judell, chrome (incognito) / via (NB: incognito is crucial to ensure that you don't end up as the same user in both windows)
• Doc: http://cdn.nmc.org/media/2016-nmc-horizon-report-he-EN.pdf
• Group: https://hypothes.is/groups/1LxDv3K9/test-group
• Orphans: Feature flag turned off for everybody, for now.

Behavior:

• judell has an annotation in progress
• jonudell creates an annotation
• judell's in-progress annotation is destroyed.

Steps to reproduce

1. Go to an annotation in the sidebar on a desktop/laptop computer
2. Hover over the timestamp.

Expected behaviour

It used to be that the full date and time would be shown on hover. This is useful for telling time of day for instance.

Actual behaviour

Nothing.

Browser/system information

Chrome / extension.

Steps to reproduce:

1. Navigate to a group on the page which has one orphaned annotation.
2. Click on the edit button for that card
3. Make a change to the text and save.

Expected behaviour:

The changes against that orphaned annotation are saved.
The orphans tab stays selected.

Actual behaviour:

The changes against that orphaned annotation are saved.
The annotations tab is selected.

Browser:

Tested on Chrome

Additional details:

The update action for an annotation is a remove followed by an add. So, while editing the last orphaned annotation for a page, when the old annotation is removed, before it is replaced with the new(edited) one, the orphans count decreases to zero, satisfying this condition in annotation-ui.js:

if (selectedTab === uiConstants.TAB_ORPHANS &&
  countIf(annots, metadata.isOrphan) === 0) {
  selectedTab = uiConstants.TAB_ANNOTATIONS;
}

The solution is probably to add an action in annotation-ui.js for UPDATE_ANNOTATIONS.

Steps to reproduce

1. Activate Hypothesis on a page
2. Severely throttle the network connection (enough that you can perform step 4 before the network request triggered by step 3 has completed)
3. Select a piece of text and click 'Highlight' to create a highlight
4. Select a different piece of text and click 'Highlight' to create a second highlight. (You can tell if the highlight created at step 3 has been saved to the server yet by looking at whether Reply/Edit actions are displayed underneath it in the sidebar)

Expected behaviour

The highlight created in step 3 should continue to exist after step 4

Actual behaviour

The highlight created in step 3 is removed in step 4

Browser/system information

Tested with Chrome v55 and Hypothesis v0.46

Steps to reproduce

1. Activate H on https://hypothesis.zendesk.com/attachments/token/KBAIRHKeCC5gWpSvK7s0sVqvM/?name=John-Steiner%2BMahn1996_Vygotsky.pdf
2. Select text
3. Wait

Expected behaviour

Adder pops up promptly

Actual behaviour

Adder can take a looong time to appear. But as per the screencast attached to #117, that behavior seems intermittent.

Browser/system information

Tell us which browser, browser version, and operating system you were using when
you encountered this issue.

Additional details

The doc is a scanned/OCRd PDF.

Here's my info, not sure about the user who reported this has but have asked her to provide the same for her system.

Version: 0.46.0
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 URL: https://hypothesis.zendesk.com/inbox/conversations/671

Suggestion: any annotation that matched the search at the time when the search was first made should remain in the search results until the search query is changed, even if edits to the annotation mean that it no longer matches the search.

(Note: you can also see this separate issue in the gif above.)

Expected behaviour

Visiting http://www.jneurosci.org/content/34/27/8976.long, as a member of a group that has annotated that doc, I should see annotations made there.

Actual behaviour

I don't.

Additional details

Consider this annotation created on that doc in the group:

{
    "updated": "2016-02-03T22:16:57.450959+00:00",
    "group": "5,..4",
    "target": [{
        "source": "http://www.jneurosci.org/content/34/27/8976.long"
    }],
    "uri": "http://www.jneurosci.org/content/34/27/8976.long",
    "document": {
        "title": ["Exercise Modulates Chloride Homeostasis after Spinal Cord Injury"]
    },
    "id": "AVKpNb1svTW_3w8Lytlo"
}

This API query finds the annotations (assuming use of a token belonging to a group member):

https://hypothes.is/api/search?limit=200&offset=0&uri=http://www.jneurosci.org/content/34/27/8976.long&_separate_replies=true

But this is the API query actually made by the H client:

https://hypothes.is/api/search?_separate_replies=true&group=5JPw23D4&limit=200&offset=0&order=asc&sort=created&uri=http%3A%2F%2Fjneurosci.org%2Fcontent%2F34%2F27%2F897

The client, with http://www.jneurosci.org/content/34/27/8976.long in its address bar, is looking up http://www.jneurosci.org/content/34/27/8976, not http://www.jneurosci.org/content/34/27/8976.long, and finding nothing.

Why?

I suspect because the doc contains:

<link rel="canonical" href="/content/34/27/8976" />

I'm aware that we made this server-side change https://github.com/hypothesis/h/blob/7f842ae3343df859cafa33a951d5e0508f0f304f/src/memex/storage.py#L227 to be more conservative about URI expansion. But that happened long before 2016-02-03. And in any case, this is a question about client behavior.

Here I am at http://www.jneurosci.org/content/34/27/8976.long posting an annotation, the uri in the payload is http://www.jneurosci.org/content/34/27/8976.

Is that derived from <link rel="canonical" href="/content/34/27/8976" />? Is that a change since the example annotation above was posted on 2016-02-03?

I suppose it's possible that jneurosci.org changed their rel="canonical" policy between then and now, but it seems unlikely, what they have now is what I'd expect. In which case, have we created a discontinuity? . If so, I guess resolving that would be a job for yet-to-be-created tools for viewing and perhaps modifying the doc alias table.

1. Create a new annotation, but don't save it and don't enter any text or tags.
2. Create another new annotation.

Expected: Annotation 1 should be deleted, I should see annotation 2 in the sidebar.

Actual: Annotation 1 is deleted but I do not see annotation 2 in the sidebar.

Second version of the same bug:

1. Create a new annotation, this time do enter some text and tags into it, but don't save it
2. Create another new annotation

Expected: I think the expected behaviour in this case is that I should see both annotations 1 and 2 in the sidebar?

Actual: annotation 1 is deleted, I see only annotation 2 in the sidebar.

The first issue bisects to this commit 1832a97 and I suspect the second issue is just another symptom of the same bug

Expected behaviour

Type asdf
Select it
Hit the Bold button
It becomes (asterisk)(asterisk)asdf(asterisk)(asterisk)
Hit Preview
It should be bold.

Actual behaviour

It isn't.

Other info

Note: I'm writing (asterisk)(asterisk)asdf(asterisk)(asterisk) here to indicate the text because if I actually put it here GitHub will bold it.

Manually typing (asterisk)(asterisk)asdf(asterisk)(asterisk) does work.

Browser/system information

Version:0.46.0
User agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
URL:https://www.postgresql.org/docs/9.0/static/functions-matching.html
Username:judell
Date:13 Oct 2016 14:47:39 -0700

Steps to reproduce

1. Go to http://jonudell.net/h/mueller_01.pdf
2. Select the word "Chomsky", and only that word, in the first paragraph. Note that making this selection precisely requires fine mouse control to avoid selecting the whole paragraph
3. Click the "Annotate" button

Expected behaviour

The word "Chomsky" should be highlighted and a new annotation should be created.

Actual behaviour

No new annotation is created. An error appears in the dev console:

Uncaught TypeError: Cannot read property 'classList' of null
    at getNodeTextLayer (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:683:24)
    at Object.exports.describe (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:934:20)
    at getSelectors (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:1526:29)
    at Array.map (native)
    at PdfSidebar.module.exports.Guest.createAnnotation (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:1550:36)
    at PdfSidebar.module.exports.Sidebar.createAnnotation (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:3043:40)
    at Object.onAnnotate (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:1179:14)
at Adder.handleCommand (chrome-extension://bjfhmglciegochdpefhhlphglcehbmek/public/scripts/injector.bundle.js?bb3e58:426:15)

Browser/system information

Chrome v54.0.2816.0
Hypothesis v0.44

Steps to reproduce

1. create an annotation
2. refresh page (see the count reflect number of annotations on the page)
3. open sidebar and delete/add annotation

Expected behaviour

The count would properly update the new number of annotations

Actual behaviour

Count is not changing in response to this

Steps to reproduce

1. Go to example.com, select the 'Public' group and switch to the Page Notes tab, where Jon has helpfully posted several hundred notes
2. Create a new page note, which should appear at the bottom of the sidebar, and enter some text
3. Scroll to the top of the sidebar
4. Switch to a private group

Expected
Page note moves to private group

Actual
Page note remains public

Notes
Since we now only create <annotation> components for annotations that are actually in/near the viewport, we no longer listen for GROUP_FOCUSED or BEFORE_ANNOTATION_CREATED events for annotations that are off-screen, resulting in the group not being updated.

The fix is to move this logic out of the <annotation> component. Ideally if the current focused group was a piece of state in the Redux store and GROUP_FOCUSED was an action, then the handler for that action could update this state.

The console error is:

Uncaught (in promise) TypeError: Cannot read property 'nodeType' of undefined(…)

It happens here in annotator.js:

Util.getFirstTextNodeNotBefore = function(n) {
var result;
--> switch (n.nodeType) {

Version: 0.41.0
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
URL: http://www.nytimes.com/2016/04/17/magazine/the-minecraft-generation.html
Username: judell
Date: 13 Sep 2016 08:28:42 -0700

Here I double-click on the word "annotating". The highlight is far too small for some reason. Then when I annotate, it creates an annotation with no target text.

(This looks like it might be a bug with selecting text in PDF.js.)

Steps to reproduce

1. Create an annotation with the following markdown content: Hello <a href="http://www.google.com">Google</a>
2. Click the link in the Chrome extension

Expected behaviour

The link should open in a top-level tab, preferably a new tab rather than the current one so it doesn't lose the user's position in the sidebar

Actual behaviour

The content of the sidebar disappears and the console displays an error message either about failing to load mixed content (if the link is HTTP and the current URL is HTTPS) or same-origin restrictions for iframes (if the link's protocol is HTTPS)

Browser/system information

Tested in Chrome v52

Steps to reproduce

1. Go here: https://via.hypothes.is/https://www.commonsense.org/education/privacy/blog/digital-redlining-access-privacy
2. Scroll midway down the page, so that there are a fair number of annotations above you.
3. Select text, click "Annotate"

Expected behaviour

The sidebar should open and scroll to an open editor

Actual behaviour

The sidebar opens and remains fixed at the top of the cards showing. The open editor does exist, but must be scrolled into view.

Browser/system information

Via + Recent chrome

Additional details

Steps to reproduce

1. In Chrome, open a PDF like this one: http://docdrop.org/pdf/Bullets-rEMN9.pdf/
2. Doubleclick to select the first word in a paragraph after a line break, or a bulleted list
3. Click Annotate

Expected behaviour

The sidebar should open

Actual behaviour

It does not.

The console reports the following error:
hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:595 Uncaught TypeError: Cannot read property 'classList' of nullgetNodeTextLayer @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:595exports.describe @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:846getSelectors @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:1431module.exports.Guest.createAnnotation @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:1455module.exports.Sidebar.createAnnotation @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:2975module.exports.Guest.onAdderClick @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:1658(anonymous function) @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:3878closure @ hypothes.is/assets/client/scripts/injector.bundle.js?5c352c:4268dispatch @ hypothes.is/assets/client/scripts/jquery.bundle.js?aa4179:4642elemData.handle @ hypothes.is/assets/client/scripts/jquery.bundle.js?aa4179:4310

Browser/system information

Chrome

Additional details

I believe this may have been previously reported, but I cannot find the bug.

I've highlighted the things that I think are either implementation or design buts in bold:

1. When you first activate h there's a button called "New Page Note" on the sidebar.

2. If you highlight some text, this turns into a "New Annotation" button.

3. If you click on this "New Annotation" button, instead of using the "Annotate" button in the popup, then it creates a new annotation in the sidebar but the popup doesn't disappear. At this point clicking on the "Annotate" button in the popup makes the popup disappear, but nothing else happens.

4. Continuing... You can now edit your new annotation in the sidebar. But notice that the "New Page Note" button is still saying "New Annotation". At this point, while you have your new unsaved annotation in the sidebar and haven't typed any text into it yet, if you click on the "New Annotation" button then two things will happen: 1. The "New Annotation" button will turn back into the "New Page Note" button. 2. The target (selected) text of your new annotation will disappear.

   (I suspect that what actually happens is we delete the annotation and replace it with a new page note, another unintended consequence of the recent feature that when you create a new annotation we delete any empty unsaved annotations to prevent the user from getting confused by having multiple new annotations open at once.)

5. Now that your annotation has been turned into a page note and you still haven't typed anything in the annotation, clicking on the "New Page Note" button just does nothing.

6. Now type some text into your new page note, and then click the "New Page Note" button again. This time it will add a new page note. But if you then click it again, it will again do nothing. Type some text into your second new page note and then click the "New Page Note" button again and it'll add a new page note, and so on...

7. Okay, cancel all of the open page notes and annotations and start again. Create a new annotation. The "New Page Note" button turns into the "New Annotation" button. Cancel your new annotation without saving it. The "New Page Note" button still says "New Annotation" but clicking on it creates a new page note.

Steps to reproduce

1. Go to https://hypothes.is/stream
2. Leave the tab open for a while

Expected behaviour

We resume seeing the list of items that were displayed before leaving

Actual behaviour

Browser/system information

Chrome Latest

Additional details

Doing some investigating, @nickstenning found that we create this result when the web socket receives updates, real-time replies, to annotations that exist on the server but are not in the current user's list of items.

Here I double-click on the word "annotating". The highlight is far too small for some reason. The adder popup does not appear.

Steps to reproduce

1. Click here: https://hyp.is/JdFEBHt7Eeaa3t8X5vHvgQ/notes.wtk.io/2016/09/15/replies

Expected behaviour

Cards should sit within sidebar panel

Actual behaviour

Right side of card hangs over

Browser/system information

About this version
Version:
0.43.0
User agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
URL:
https://notes.wtk.io/2016/09/15/replies
Username:
dwhly
Date:
16 Sep 2016 08:41:46 -0700

Additional details

This appears to correspond to the presence of the URL in the card. The pathology begins when the sidebar is shrunk below the width of the URL.

1. Sign in
2. Focus group Foo (not Public)
3. Log out
4. Create a new annotation (you'll get a "You must sign in to create annotations" card)
5. Sign in

-> The focused group will be the one you lost had focused when you were last logged in: Foo. But the annotation's Post button will say Public, and if you save it, it'll be saved to Public.

Steps to reproduce

1. Install Chrome plugin
2. Use/wait for a while
3. After a while when plugin is activated the user is logged out
4. If a login is attemted from the extension, an error is displayed "Session is invalid"

Expected behaviour

Login should be possible (or simply persists from last login)

Actual behaviour

Can't login

Browser/system information

Same issue happens both in Windows/Chrome and Linux/Chromium

This is not an issue with incorrect login/password - they work on hypothesis.io website.
Tried changing password/restarting/reinstalling plugin, nothing helps.
Issue since about ~week.

Some LaTeX commands do not work in the annotations:

• $a+b=c$ not rendered (but another option \(a+b=c\) works fine)

• \(\mathbb R\) does not work

• \( \# \) does not work

Steps to reproduce

1. Go to example.com
2. Activate Hypothesis (using the extension), wait for the sidebar to appear
3. De-activate Hypothesis

Expected behaviour

Any elements added to the body of the document when Hypothesis is activated should be removed when it is de-activated

Actual behaviour

An 'annotator-notice' div is added to the page which is later never removed.

Additional details

This <div> is empty and I think it relates to a feature of annotator that we don't use, so should never be added to the page at all.

Steps to reproduce

1. Browse to: https://via.hypothes.is/http://www.dailymail.co.uk/news/article-3974846/Stunning-new-data-indicates-El-Nino-drove-record-highs-global-temperatures-suggesting-rise-not-man-emissions.html
2. Open sidebar.

Expected behaviour

Annotations should be in proper location sort order

Actual behaviour

They're not.

Browser/system information

Via / Chrome

Checkout this snippet for a demo.
Uncomment out the embed script to see the embedded sidebar activate.

https://jsfiddle.net/sean_roberts/4gnbz2y2/

Expected behaviour

No visual changes to the website

Actual behaviour

the adder having visibility hidden still keeps the positioning in the dom adding an invisible padding to the bottom of the page.

Steps to reproduce

1. Post this link into a new annotation and save the annotation: https://youtu.be/nffPZ1kLDHM?t=95

Expected behaviour

Video begins at the 95-second mark

Actual behaviour

Video begins at the 0-second mark

The default sort order for annotations is to sort by location in the document. For Page Notes, this doesn't make sense and the ideal sort order hasn't been specified, so it is whatever happens to come out of the implementation.

Now for the fun part: In the implementation, Page Notes are sorted by location, but the value Number.POSITIVE_INFINITY is used as the value of the location for all notes. Since:

1. In JavaScript Number.POSITIVE_INFINITY < Number.POSITIVE_INFINITY is false
2. The sort function passed to Array.sort() always returns 0 due to (1)
3. Stability of Array.sort() is implementation defined (stable in IE, Firefox, unstable in Chrome [1])
4. There is no guarantee of the order in which Page Notes are stored in the app state anyway

This means that the order in which page notes are sorted is unpredictable.

[1] Compare the result of [1,2,3,4,5,6,7,8,9,10,11].sort(() => 0) in Chrome and Firefox

Note: This will not be easily reproducible until #94 is fixed.

The logic which removes new, empty annotations does not run unless the annotation is in or near the viewport and thus has a corresponding <annotation> component instantiated for it. Therefore if a new empty annotation is a long way offscreen, it will not get removed if another new annotation is created.

Steps to reproduce:

1. In a page with many annotations, create a new annotation at the top of the page but do not save it
2. Create a new annotation at the bottom of the page

Expected:
Annotation created in step (1) is removed

Actual:
Annotation created in step (1) is not removed

Notes

Now that the state of annotations being edited is maintained entirely in the drafts service, we can move this logic outside of the <annotation> component and avoid this problem. In order to fix this, we just need to remove any empty drafts when a new annotation is created locally.

Steps to reproduce

1. Find a page with only a page note and no annotations
2. Pull out the sidebar

Expected behaviour

Page note tab should be selected

Actual behaviour

Empty annotation tab is selected.

Browser/system information

Any

Additional details

This was an implementation detail that was identified back in the design process, but may never have been recorded. Most definitely we shouldn't show an empty tab when there are legitimate annotations (as page notes) present (though I would argue not orphans). @conordelahunty Can I get an assist?

Possibly related to #97 , in this screencast of H you can see empty annotations appearing to revert to Edit mode when scrolling up between 0:30 and 0:40 in this video.

@jeremydean can you provide any more details of what you recall about this issue?

I've closed hypothesis/h#3836 in favor of this issue.

The doc in question is a copyrighted PDF with this fingerprint: 4451dd7e09400643ada9a3b5edfe832a. (We have several copies internally.)

Here are two screencasts that illustrate the inconsistent behavior.

http://jonudell.net/h/bethesda-with-orphans-tab.mp4

In this example the orphans tab is enabled. I select "Bethesda, Maryland" once and create a normal annotation. I delete it, reselect "Bethesda, Maryland", and now create an orphan.

http://jonudell.net/h/bethesda-without-orphans-tab.mp4

Same example with the orphans tab off (as it is for all except a few H staffers). Similar behavior except the errant annotation is neither an orphan (in that it displays as an annotation card) nor an annotation (in that it does not behave like an anchored annotation).

The second example also illustrates another pathology I see intermittently on this doc: the adder sometimes fails to open the editor.

Steps to reproduce

1. On master (Git commit >= f588f1e) create a Page Note on http://localhost:5000/docs/help
2. Go to http://localhost:5000/docs/help#annotations:<ID>

Expected behaviour

The client should select and display the Page Note

Actual behaviour

The client indicates that there is a selection but the button reads "Show all annotations" instead of "Show all notes" and does not display the page note

Notes

This broke after #116

Selecting the tab containing a direct-linked annotation currently happens when the annotation is anchored (in response to the ANNOTATIONS_SYNCED) event. Page Notes do not get anchored. We could actually select the appropriate tab at the point where the annotation is loaded into the app instead - although we may later need to change that selection if an annotation becomes an orphan.

Steps to reproduce

1. Visit this gist
2. Activate Hypothesis and highlight the HTML markup for the <img> tag
3. Click Annotate

Expected behaviour

The HTML markup highlighted appears as plain text in the quote of the annotation in the sidebar

Actual behaviour

Notes

Although the markup is not escaped, it is sanitized so only a whilelist of HTML elements can be rendered in quotes. Style and script tags in particular are removed.

Steps to reproduce

1. navigate to https://hypothes.is/docs/help
2. wait for annotator to initialize
3. Error thrown

Expected behaviour

no error

Actual behaviour

Error thrown

Uncaught (in promise) TypeError: Cannot read property 'nodeType' of undefined(…)
Util.getFirstTextNodeNotBefore @ annotator.js:228
Range.BrowserRange.BrowserRange.normalize @ annotator.js:599
(anonymous function) @ guest.coffee:218
(anonymous function) @ guest.coffee:18
n @ raven.js:250Promise.reject (async)
(anonymous function) @ guest.coffee:20n @ raven.js:250
requestAnimationFrame (async)
...

Browser/system information

Chrome 52