niiiiice! thanks.
Crucial feature! Thanks!
Cool!! This is great
Did not see. ABSolutely great like a six pack !
Just noting a bug: It seems like if you add and remove the same segment multiple times the Undelete function gets stuck in a loop and won’t move back through older segments.
Oh, right. Didn’t think about it. Thanks for reporting!
I was able to reproduce this issue for a moment, but then I’ve cleared the undelete history (in localStorage) and I’m no longer able to reproduce it. @Celia_D Do you have some steps to reproduce is regularly?
Also, try clearing the history in localStorage and see, if the problem persists.
To clear it:
- Open the Console (F12) and make sure, you’re on the Console tab.
- Paste this code:
localStorage.removeItem('delete')
and press Enter. - Refresh the page.
Warning: this will clear you’re undelete history, but that probably won’t be a problem, since it currently doesn’t work anyway.
It seemed to clear up for a moment, but then I went further back in the list and it seems like it’s still stuck. Here’s my link if you want to give it a look - neuroglancer , though maybe it won’t work for you if it’s a local issue
Unfortunately, that won’t help me. If you could get me a copy of your localStorage that could potentially help.
To do this, in the console type: localStorage.getItem('deleted')
and press Enter.
It will look similar to this:
If you’d just copy and paste here the string, that’s in blue on my screenshot, I’d be very grateful.
‘[“648518346438031583”,“76002229642969036”]’
Thank you!
Now I was able to reproduce the issue.
The problem seems to be with the shorter numbers (starting with 7 in this case). If I’m not mistaken, those numbers happen, when Neuroglancer adds a component segment ID, instead of the whole segment ID. Not sure, why it happens, but it happens, none the less.
The issue with the loop happens, because even if a user tries to manually add such shorter number as a segment ID, Neuroglancer will remove such segment automatically. So, when the addon tries to undelete such a segment, Neuroglancer removes it, addons adds it to its list and we’re in a loop.
I’ll fix the issue by checking the length of the number added to the list (hopefully, the future segment IDs won’t change in length, or they won’t be added to the undelete list. But if it was going to happen, I’ll just try to find another fix then).
In the meantime, to escape from the loop, just clear the localStorage. Just a small correction: yesterday I wrote, that the instruction is with delete
in it, but it should be deleted
(with the “d” at the end). So, the correct one is: localStorage.removeItem('deleted')
.
Great, thanks for looking into this!
Ok, now in v. 1.2 it should be fixed.
Also added a small update: if a user removes the same segment for a few times in a row without undeleting it in the meantime, the segment will be added to the undelete history only once.
v. 1.3
Looks, like Pyr has also shifted to the new format of the segIds (it used to be a custom Uint64 format, now it’s the built-in BigInt).
hmm undelete in EW2 seems to have a bug, sometimes it doesn’t appear w/o an F5/refresh.
Hmm, do you have any errors in the console?
if/when it happens again i’ll take a look and paste any I find.
ok I know how to make it happen. In FF close FF and re-open it.
even w/ refresh it doesn’t fix itself unless I delete a seg. (and then can re-add).
Ok, thanks.
In v. 1.3.1 I’ve added a 500ms delay between detecting the existence of the viewer object and an attempt to select the selectedLayer. Not sure, if it’ll help, but should.