Jump to content

Ashley Gittins

Level 2
  • Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral

About Ashley Gittins

Profile Information

  • Subscription
  1. My web client bumped to v6.8.0 a few days ago (plus I also upgraded to Chrome 80.0.3987.163) and it has been fine since. *shrugs*
  2. Has there been a regression? I have just started noticing this on my system. I'm using evernote web client v6.7.1 on Google chrome 79.0.3945.130 (on debian linux). Placing the mouse pointer at the top or bottom of a note text area initiates scrolling, as per the above reports. It may have been happening for a while without my noticing, as I use keyboard shortcuts mostly, so the mouse usually only traverses those regions when leaving the tab or if I'm doing formatting. Super frustrating, naturally.
  3. Take a look at https://discussion.evernote.com/topic/102215-option-to-disable-the-message-you-are-leaving-evernote-on-external-links/ (basically: if you're using chrome, you can use tampermonkey to add a userscript that will automatically click past the page for you). Tampermonkey I think is available for most browsers, so it should solve your problem - certainly works well for me on Chrome (on linux).
  4. Oh, also @Scott T., just wanted to say it's very encouraging to see some proactive engagement happening here in the forums. I hope it's indicative of a brighter path ahead for Evernote. 👍
  5. That's well worth trying - but do consider that you might lose nested list indenting if you do - there's a bug with the older web client and some browsers, so keep that in mind if you are a heavy user of indented lists (it only seems to affect notes that you edit while using the old version, so if you're only editing a test note it won't affect your other notes). FWIW, I switched to the older version recently (more so because the new one wouldn't load at all for me for about a week) but I switched back as soon as I could due to the list formatting issue. I didn't experience this reload issue in that time, but I am only seeing it quite rarely now. FWIW, my notes tend to be around 10KB, and this issue is now only occurring very infrequently for me (maybe once in the last week).
  6. Can't talk for Jeshi of course, but when it happened to me it was a single tab only. Your description sounds similar to the circumstances surrounding the old duplicate notes issue, which i haven't experienced for a while - perhaps there was a fix for that which is now causing this (thinking of xhr requests arriving out-of-sequence at the server). I have other extensions running (incl adblocker) but can't replicate this issue reliably enough to rule them out easily as i am rarely getting the error myself now.
  7. I use the web client every day and yes, I've started seeing this happening, I think in the last week or so. I think it's only ever lost the very last few seconds of stuff I've entered but it is worrying. Sometimes I've been switching between other apps and come back to find the error, and not been entirely confident that the last thing was still there 😕
  8. I went into some detail in my 2006 post linked just above. To reiterate, possibly more clearly... :-) Include a session-specific hash and a sequence number in each XHR update sent by the browser At the server: only ever create a duplicate note if "last-edited-by-hash" does NOT match the new update's session hash (ie, two concurrent apps/tabs: user is on their own) If an update arrives out-of-order (ie, has a lower sequence than last-edited-by), discard it (since we already have a more recent edit applied). If they do shard updates (ie, they send the changed parts of the note back to the server, which I'm pretty sure they do) then track sequences at the shard-level rather than the document level. If shards don't have fixed or deterministic boundaries this might be non-trivial. There are performance issues to consider in doing this (it requires an aspect of "state" at the backend which can cause scalability issues), but it should be possible to manage that either with a key-value cache (like, say, Redis) with TTLs or at the near-DB level (since the db will have enough info to make the choice locally without a round-trip). It could also be solved by having the browser collect timestamped acknowledgements and intelligently submitting overriding edits if it sees out-of-order applications but that would be pretty kludgy. There are plenty of web apps where this problem doesn't happen (google docs, anyone?). It is not some magical problem with cloud services that we just have to put up with - it is something every XHR-heavy web service has to deal with and (perhaps to varying degrees), most do - it's simply a bug and evernote are failing to fix it. Maybe it's more complicated because of something in their architecture (or politics), but they've shown little sign of actively working on the issue so occam's razor suggests that for whatever reason, they simply don't care "enough". The first year or so perhaps they were banking on the new web interface fixing it. Maybe the new web interface isn't as maintainable as they hoped, or they're having trouble deploying incremental improvements. Maybe the percentage of paying users who use the web interface is too low to prioritise corner cases like this. I'd suggest they think about potential paying users who try out the web interface first before installing a native client - the admittedly small handful of posters in this thread who were paying clients that then dropped their subscriptions would be indicative of a wider number of lost customers. Perhaps that number of customers just isn't economically significant, hard to say. I could easily be missing something that makes this issue less trivial, but then I've only had a few years to ponder it and can only do so from the outside :-)
  9. Yep, I let my subscription lapse, too.
  10. Unfortunately this issue has existed since 2014 and Evernote have shown very little interest in resolving it. I posted a rough overview of what seemed to be causing it in 2015 here And then in 2016 a more detailed description of the process and possible solutions here The short version is that I think xhr requests are arriving out of order and the backend blindly applies them in the order it receives them. If you're on wifi your connection might be quietly reconnecting in the background, that was a problem I was having with the Realtek Linux drivers at the time.
  11. I'm confused, why would an update to webclipper resolve an issue with evernote-web (a separate product) which (at least in my case) wasn't even installed on my browser when I was having the issue?
  12. This issue is getting ridiculously old and remains frustrating. I don't know if nobody's simply taken the time to look at it or if none who looked at it have clicked as to what's going on. My theory is that as changes are made and XHR requests are sent from the browser to https://www.evernote.com/shard/s136/enweb/notestore/ext via focusclient-0.js, some of those requests are getting through out-of-order. Eg, request #1 is sent, but for whatever reason (single lost packet, wifi dropout, sunspots) it doesn't get through straight away and sits in a retry/retransmission buffer somewhere in the network stack. User is still typing, so a new save point is triggered, let's say request #2. The gods smile upon this XHR request and it goes through and gets committed. Some milliseconds later, request #1 gets its second wind, and finds it's way through to the evernote servers. Now it arrives like some time-traveller, holding an edit to an old version of the note. It seems that the backend logic by whatever means handles this by creating a duplicate of the note (perhaps with intent for it to be flagged as a conflict). If this is what's happening (and frankly, evernote have shown zero ability to demonstrate that they have a clue what's happening so please feel free to elucidate) then perhaps the answer is to keep a client-side counter for shard submissions that it increments every time it sends to notestore/ext and submits along with the note data. On the backend, the server should check the last received counter that matches the note-id and session (whatever means you use to track the user's current session) and if the newly received counter is less than the one last received, discard the update (since it was obviously delayed and has been received out-of-order). Now if you are submitting partial note data (as hinted by the "shard" term) then perhaps there needs to be a way to identify the shard range as well, so it only rejects old updates that relate to a specific portion of the note. I find it hard to understand why this hasn't been thought through, is it that much more complicated than the above?
  13. I've been getting this regularly since putting in a new wifi nic on my desktop, although I have also had it happen sporadically over the last year or so. Currently Chrome 41.0.2272.89 64bit on Linux. My wifi has been glitching out and it seems if I'm editing a note at the time I'll get a heap of duplicated notes. No conflicts, just duplications. The oldest ones seem to be the most up to date (hinting that the later dupes are actually from earlier save attempts so were perhaps on a stack or queue). Also these are pre-existing notes that had been saved in previous sessions, not new notes. By the way, to save sitting through 4mins of video to find out - Jody's issue ended up being what looks like a misconfiguration of the scansnap software (import folder defined twice in configuration) so not related to the OP's bug report. Nancy it might be worth noting that a lot of these duplicates appear to be identical at least in the note body - if what you say is true and the note conflict path is being triggered it might be worth making the conflict detection a bit smarter - eg, if other note == this note, no conflict. For that reason I suspect it's not actually the conflict resolution codepath that is being triggered, but simply network retries that are being a bit stupid about whether they are still valid or not.
  • Create New...