Reported in 3475633-zen.
Basically, in a small number of my notes, this History button is greyed out, and the alt text is History (unavailable) when I hover over it.
I鈥檝e tried a couple of things. If I create a new note in the Android version, history works on that note in the Windows app. If I create a new note in the Windows app, history is unavailable in Windows app but available in the Android app.
I would expect the History icon works/clickable for the note created with the Electron app.
The History icon greyed out when I created a note with the Electron app. But if I created a note in the Android/iOS apps, I can click on the History icon.

As reported in 3475633-zen
Reproduced with the following device
The history icon is grayed out when the app has no revisions to revert. It grabs history when changing notes. We can improve this by making sure that after a note is open for a certain period of time we grab the history anyway, but so far we have limited this to keep things simple in the code and prevent thrashing the network with requests for note history as it operates differently than the rest of the data in Simplenote.
That is, either there are no revisions or the app hasn't requested them. In the meantime, try switching to another note and back and you should find that the history loads. This change was introduced to eliminate some of the confusion when opening the history panel while revisions were still loading.
Thanks for taking a look, @dmsnell! I tried editing the note I created on the Electron app with the Android app yesterday and switched back to view the note on the Electron app, the History icon still greyed out. When I looked at it again today, I can click on the History icon and see the revisions.
However, the behavior of the History icon is different in the Android and macOS apps. I can access the History icon soon after the note was created. Will this change be implemented on the other apps so it won't cause confusion to the users with the inconsistency of the behaviors among the apps?
Will this change be implemented on the other apps so it won't cause confusion to the users with the inconsistency of the behaviors among the apps?
Not likely. What's more likely is what I mentioned, that the web/Electron app will poll the history soon after loading a note so that the history icon lights up without needing to switch.
same here on Linux client too
It's greyed out on the web version too on my end.
@dmsnell Just clarifying that the issue with disabled history button is expected to be gone after switching to another note or app relaunch?
What I currently see with 2.6.0-beta2 is that history is still unavailable after these actions, but available for the same note in native and Android.
Let me know if you would like to see the account with this note.
@pachlava this app currently only shows the history button when it's aware of revisions for a note. to illustrate, if we had the same behavior as the mobile apps where the button is always enabled then in these cases what I would expect to happen is that you'd click on the button and then there would be no revisions.
I'm saying that any problem with the button is likely a failure to fetch the revisions so we may need to look at the network activity and see what's going on.
disabled history button is expected to be gone after switching to another note or app relaunch?
I'm not sure where an app relaunch came into view but switching to another note and then back will prompt the app to attempt a fetch again. If there are revisions for a note then they should persist across app sessions but if you relaunch the app I don't believe it will affect them.
The action that triggers revision fetching is specifically switching notes.
A viable fix to some of the flakey behavior here is to detect when revisions aren't available for the currently-opened note and also when the fetch has not been attempted (and resulted in a failure) so that we can send an additional fetch.
Truly fixing revisions needs API work on the Simperium backend not likely to be addressed any time soon.
Let me know if you would like to see the account with this note.
That's not necessary; it'd be more helpful to know:
@dmsnell Please see the attached video (had to compress a bit due to size, sorry). I'm talking about the case when history is not only enabled on other platforms, but also is functional, of course. At the moment it looks like Electron app has an easily reproducible issue with history:
Please let me know if I should create a bug. Thank you!
thanks @pachlava for following up. no need to spend effort to try and convince me of the behavior you're seeing - I believed you when you first mentioned it. as I mentioned above though if we want to figure out what's wrong we're going to need to see why the app isn't fetching the revisions (thanks for flipping to another note and back).
At the moment it looks like Electron app has an easily reproducible issue with history:
seeing as how the other note in the video _does_ have a working history button I'm missing what the easy steps are. did you see any console errors?
do you need help looking at the WebSocket to see if the revisions are being sent?
did you find that restarting the app makes the history button start working? I'm still curious where an app restart came into the picture.
@dmsnell
do you need help looking at the WebSocket to see if the revisions are being sent?
I've taken a look at the WebSocket and from what I see, for the cases of disabled history button, the revisions themselves are not being sent, however the number of revisions for current note is stored correctly in 'sv' property. Switching between notes does not change the situation. What might help (not always) is reloading the page, in that case the revisions will be sent once the note is selected for viewing.
This does not change the situation in whole. From the perspective of the user (and I'm in a position of a user during beta testing), the history for a new note is not accessible in Web/Electron, but accessible right after creation for all other platforms. Users will not care about the reasons behind the button being disabled, they will care about the fact that they can't use history. Since we have tests that explicitly underline that history should be accessible in that case, I'm in a situation when I will consider this test failed, leading me to a question - if a bug should be posted for this?
I understand that there are technical reasons for history to work exactly as it works currently. But in that case we should decide if we change the tests, or we change something in history fetching.
I'm still curious where an app restart came into the picture.
Since I was testing this in Electron app initially, one of the steps that looked natural to try, after seeing that switching notes does not help, is trying re-login, and trying app restart. I'm not saying that app restart should or should not result is history being fetched. I was just saying that this is something that I tried.
@pachlava we're clearly talking past each other. in no way am I trying to dismiss you. I understand this is a bug. this issue itself is the bug report so I don't know where else you would want to post something.
I'm trying to provide help to fix it and that requires understanding why it's broken. even if the user doesn't care why we still have to figure out why if we want to fix it.
for now I'm going to step away from this ticket and let someone else take it; my intention was to help diagnose the issue and provide guidance on how to fix it. I thought you were trying to help replicate it and that's why I responded to your comments and asked for your help. if you or someone else wants further help from me then ping me in Slack - I'm happy to provide assistance.
I'm sorry if I gave the impressions that I was trying to argue with you.
@dmsnell
I'm sorry for the situation, it definitely was the case when we were talking past each other. Our previous discussion here gave me the wrong impression that I'm asked for more technical details because there was not enough proof of the issue reproducibility. Now I understand that you were trying to help me to see the issue cause - and I'm thankful for that. This thread definitely helped me to understand better how history works. This was unusual for me, since I was used to the more one-sided communication, where my 'part' ended on the issue description, and the underlying cause was examined by developers with no feedback to me. Thank you once again!
This is a bug we should resolve. Let's get the primary bug resolved and then determine if there are additional UI changes that we need to make.
This appears to be an issue of revisions not being fetched properly. I am all for never greying out the button and then fetching revisions as they click the revisions panel open.
@pachlava We will let you know when we have something for you to test.