ModifiedTime greater than InstallTime after using "Find Updates"

[nwhorton]

I am experiencing an issue with the Auto-Update functionality provided by Greasemonkey, using the Greasemonkey Firefox Add-On (version 1.8).

When I FIRST use the "Find Updates" context menu option in the User Scripts management pane in Firefox on a script with a new remote version available, it works as expected and the new version is installed.

However, after this has happened, the "Find Updates" option remains grayed out on the script, even if a new version is made available at the same remote location. Attempting to install the script "manually" by browsing to the updateUrl DOES correctly result in a prompt to install the new version, but nevertheless the "Find Updates" option is not made remains disabled.

I believe I have traced the problem to the "installTime" and "modified" attributes for the script in the config.xml file. It appears to me that upon using the "Find Updates" feature, the "modified" value ends up being greater than the "installTime" value. I believe this is because of the changes in this revision, where the "modified" value is set to the newly downloaded file's "date modified" value AFTER the installTime has already been set to a previous time.

Here is an example of what I observed in the config.xml file:

Install new script
** Sets installTime to 1363724772902
** Sets modified to 1363724677863
** Result: modified LESS THAN installTime ==> isRemoteUpdateAllowed = TRUE, "Find Updates" = ENABLED

Update to new version using Find Updates
** Sets installTime to 1363724906425 (increases)
** Sets modified to 1363724906436 (increases to a larger value)
** Result: modified GREATER THAN installTime ==> isRemoteUpdateAllowed = FALSE "Find Updates" = DISABLED

It seems to me that the "Find Updates" feature should ensure that the installTime value is recorded AFTER the "modified" value for the file has been recorded. As-is, it appears that the installTime will always be less than the modified value after performing an update, which will cause the isRemoteUpdateAllowed check to fail on every subsequent attempt to update the file.

I hope I have followed the appropriate procedure in raising this issue. Please let me know if I am off-base though, or need to provide any other information.

If I am misunderstanding the intended functionality of "Find Updates" please advise. By my understanding is that if I am only changing this file on the remote server and not ever editing locally, that the Greasemonkey Add-On should be recognizing those changes and allowing me to run Find Updates as soon as any changes are present on the remote.

[arantius]

Installing one update definitely should not stop future updates from installing. Thanks for the clear detailed bug report.

[nstepien]

I am reproducing that issue too. It breaks not only Find Updates but Check for Updates too for these 'blocked' scripts.

[arantius]

Just pushed version 1.9beta1 which should contain this fix, try the development channel at the bottom:
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/

At least for now, you'll probably need to do one manual install of any script(s) you expect to auto-update, to fix these values. Then updates should work.

[ferongr]

Is some kinds of one-time migratory fix to the attributes of existing script installs planned or considered?

[arantius]

Could be, but what exactly would it be? I don't think we have the data to tell one case from another. Mistakenly updating a script with real, important local modifications (i.e. overwriting those changes) is much worse than not updating a script that could be. Especially if the workaround is semi-obvious (just install the new version, then updates work again).

[ferongr]

If user modifications are tracked that way and not with an explicit flag,
then it can't be helped I guess.

On 25 April 2013 18:49, arantius notifications@github.com wrote:

Could be, but what exactly would it be? I don't think we have the data to
tell one case from another. Mistakenly updating a script with real,
important local modifications (i.e. overwriting those changes) is much
worse than not updating a script that could be. Especially if the
workaround is semi-obvious (just install the new version, then updates work
again).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1723#issuecomment-17015576
.

[ghost]

I think Greasemonkey should at least inform the user when an available update is being blocked by local changes. Otherwise the user misses out without even being aware of it. Maybe a notification popup or info bar once per session?