Thankfully, when this cropped up for me in firefox, I simply clicked through to the reviews for the addon, and a nice person had posted a link to a release a couple of revs back. Sorry, but I'm stunned that not only did this horribly broken web clipper release make it out of dev, it made it out of QA, made it to staging, and then - beyond belief - into production where millions (maybe?) of people's browser's happily autoupdated to it, and people got locked out of using webclipper thenceforth. I doubt the average user is going to even consider the auth session persistance between what seem like two separate "apps": the clipper and the website. It seems to be one way now where the website auth persistance overrides the webclipper, but not the other way around. If I log in to webclipper, provide some indication of persisting the session and updating the cookie. UX Feedback for Evernote: If you are tying the same cookie and auth session to webclipper extension and general website at least be consistent. But I guess if I am ok with website clipper staying logged in, I should be ok with evernote website staying logged in as well. I out of habit tend not to persist website logins. ![]() ![]() I can see the webclipper login and out realtime(the dot disappears and reappears), by simply logging in and out of evernote website. ![]() After tracing back steps, I realized that the webclipper started logging out after I had chose NOT to persist cookie/auth for website login, by not selecting remember me on website login. Logging in to evernote website addressed this issue with webclipper.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |