Annotate with anyone, anywhere. https://hypothes.is/ Contribute to hypothesis/h development by creating an account on GitHub.
All of the crashes have occurred as I’m adding one or more tags to an annotation/highlight. I haven’t experienced a crash while creating annotation text.
The crash is immediate and complete and doesn’t just take out the individual tab, but the entirety of the Chrome processes. While it’s possible that this could be a Chrome issue, I’ve not experienced any crashes with any other websites in ages. I also know that there has been some new code and UI work around the interface and the way that tags are displayed in the public H product.
My initial guess is that something may be happening within the memory/caching as H tries to pull past tags from the server to guess what I’m typing.
I’ve alternated with using Firefox and the bookmarklet and have yet to see an issue with crashes there.
I’ve experienced this crashing several times as well recently. Most recently, this morning it crashed ~~2~~ 3 times (after the first 2 times, I was unable to reproduce it for a while, but I kept trying and eventually did a 3rd time) in a row while attempting the exact same thing: when I started typing “in” in the tag search/dropdown/autocomplete (it don’t remember if it was when I stopped at “in” or when I typed a 3rd letter that never showed up), it showed a large list of matches, like this:
but then immediately froze (not only this website but all 29 other open Chrome windows also froze). The text cursor continued blinking but everything became non-responsive.
Exactly the same as @chrisaldrich:
– This only occurs when adding a tag to an annotation.
– This is with the Chrome extension (haven’t tried to reproduce with the bookmarklet)
– I don’t recall any other website that has managed to completely freeze up Chrome like this
– I never experienced this with earlier versions of this client, prior to the various changes the tag UI underwent in the last 3 or so months.
It’s getting to the point where I’m hesitant to start typing in the tag entry field for fear of it crashing. Sometimes, to be “safer”, I type out my tag search string in another field (like the Description field) and then paste it into the tag field to avoid triggering a search with too many tag matches from only searching on the first couple characters.
I suspect this issue is a result of the confluence of the following factors:
– I have added a lot of tags via Hypothesis (that’s mostly what I use it for) so when it searches for matching tags for a short substring like “in”, it probably gets back a lot of tags.
– The H client seems to starts searching immediately. I would prefer that it had a longer debounce delay and/or didn’t start searching until I had typed 3 or more characters. That would probably also help it feel less laggy when you first start typing a tag sometimes.
– I have no idea, but maybe there is some bug in the client whereby each keystroke causes exponentially more queries to be sent off or something? (I don’t know how to see network requests from extensions in Network tab.) Maybe a new callback gets added each time without clearing the previous callbacks, or calls itself recursively, or …?
– I suspect the crash occurs for a cache miss and when I’ve been unable to reproduce it, I suspect it’s because the list of tags for my search string have already been cached in the client?
I’m running:
– Hypothesis version: 1.272.0
– Chrome Version 79.0.3945.79 (Official Build) Built on Ubuntu , running on Ubuntu 18.04 (64-bit)
A similar-sounding issue was, we thought, resolved: https://github.com/hypothesis/client/issues/1606.
The interim fix was to clear localStorage of remembered tags, which was a very long list for some people. If that’s feasible for you to try, please let us know the outcome, one way or the other.
Thanks @judell . I followed your instructions at https://github.com/hypothesis/client/issues/1606#issuecomment-567226699 to delete both
hypothesis.user.tags.mapandhypothesis.user.tags.list(which apparently both had 1546 tags stored) and will report back if I’m able to reproduce it again.It does seem that the deleting tags from localStorage workaround will prevent crashes, since it apparently no longer has any list of tags to search (I thought it queried the server but now I realize it was only querying the local cache), so of course it triggers the showing of a list of suggestions almost never now (or if it does, lists only a handful of newly added tags).
But that autocompletion is a pretty important feature to me so that I can quickly reuse tags (without introducing slightly differently spelled variations). I’m not sure which problem is worse, but probably the loss of tag autocompletion/search. So I may add my tags back to
localStorageand see if I can use other workarounds to prevent crashes.On the plus side, however, it looks like this will let me prune out some of the old/misspelled tags from my list that I don’t want to show up any longer, which is something I was something I’ve been wondering how to accomplish… 🙂
@chrisaldrich – Can you confirm what version of the Hypothesis extension you have installed? You can find out by clicking the help (“?”) icon at the top of the Hypothesis annotation pane and selecting “About this version”.
@TylerRick if you have saved those local tags ( the map and the list) and you feel comfortable sharing them here, then that could help us understand how to replicate this issue or if it’s related to the data at all. Or if you don’t want to paste them here, you could send them to support@hypothes.is and just reference this ticket.
Thank you
@LMS007 Yes, I saved the local tags. I actually only saved the map because it looked like the list could be trivially derived from the map (
Object.keys(map)).I wouldn’t think that there’s anything special about my data that would contribute to reproducing this behavior, but I’m happy to share it with you if you think it could help. I sent it as an attachment to support@hypothes.is. It should be attached to ticket #7901 in Zendesk.
I haven’t yet been able to reproduce since putting my tags back in
localStorage, but I’ll post back again if I’m able to again.That seems to be the main challenge with this issue — how to consistently reproduce it.
Thanks for trying to get this figured out.
Thank you Tyler, I was also unable to reproduce it with your tag set but worth trying! I’ll keep looking for a root cause. I’m glad you saved your tags and that is interesting they are working again.
Apologies for the delay, I’ve cleared out the caches as @judell indicated and haven’t seen any issues for the last few days. I had a large number of tags, though I don’t think the number was as large as @TylerRick’s.
I feel like @TylerRick has done an excellent job of discussing the pros/cons of the user facing issues and concerns. I’m glad to know that this is where these reside so I can fix misspellings and can change the local cache to better match some of my personal website’s pre-existing taxonomies so that there is a 1-1 onto mapping of my Hypothesis tags and those on my site (or at least for the top 20% of most commonly used tags) for syndicating content more easily.
For the record, and for @robertknight’s query, below is my version information:
account: Chris Aldrich (acct:chrisaldrich@hypothes.is)userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/79.0.3945.130 Safari/537.36version: 1.272.0My recollection of the crashes is that they were typically on tags that began with the letters
in, though there were one or two instances with other short tag fragments. Almost all my data is public facing, so viewing my tags on the public instance might be illustrative.Perhaps it’s spurious, but @TylerRick and I are both sitting around the 2,000 annotation mark and may be at the upper end of the bell curve of users. Jon (~5,300) and Jeremy (~3,600) are the only people I’m aware of with more. user:esperluette may be an interesting test case given the high number of their tags that begin with the
hw-combination.The screenshot in https://github.com/hypothesis/client/issues/1689#issuecomment-575269754 seems to show that the issue was related to our attempt to use a native “ element, which we no longer do. I’m going to close the issue on that basis, but please respond if you still see it.