I've made the "upgrade script" link disappear after it's been clicked, saying "thanks for upgrading" via onclick event on the <a but I believe the text updates before the script installation is downloaded, if the user cancels install they have to refresh the page anyway, so updating the "upgrade" link with a "refresh to apply the upgrade" (if you installed it) link would have the same basic effect, also re-introducing the upgrade option after they clicked it.
Lets see though, you could do the following process: 1) download the script via xmlhttp (so that the upgrade pops up instantly, since the page ought to cache).. you might do a "please wait" in this meantime 2) navigate the user to the script URL (same url) via window.location= 3) installation should happen almost instant, so via a timeout (script dialog may even block the timeout from counting down ideally, if its anything like the glory that is alert, allowing you to detect when the dialog closes whether they pick "install" or "don't") you can then open a new tab which GM_setValue an upgraded flag to TRUE. This could be any page that runs the script, ideally a blank page you host somewhere that loads very fast. It should only set the flag IF it detects that a version number (which you also SetValue) has been modified, and it should update it to the new value. You could simply use this one "version" variable to track, however things could get confusing, although your script that loaded the upgrade (still running) could detect if the version number stored matches the version number in it's local variable. The tab can close itself. 4) at your original script a second timeout to account for the tab's loading time (started after the first fires), which GM_getValue the upgrade flag(or version) to see if the upgrade completed. You could set timeout a few times to test for upgrade but I would cap that at some number to prevent too many checks (and its a reasonable practice to increase the duration of the timeout with consecutive checks, and of course reset everything on fail). If it happens to get a TRUE value (or storedVersion > runningVersion ) then it should immediately set it to false (to prevent duplicate detection), however you will know at this time that the upgrade has been applied or not at that time and can do whatever it is that you want. that only accounts for script A however upgrading itself. If you need a script B then you can simply have them chatty cathy it up with as much innerHTML (or appends) as you want on the afore mentioned "blank page you host". If u must hide this in a div with display:none when your done testing, but if you do it right the tab ought to flash so quick no one notices unless their system is out of ram to open a tab... This will allow you to GM get and set value BETWEEN scripts which could be used to detect the upgrade/installations occurance (or lack thereof). The problem being, of course, there is a lot of extra stuff required in both scripts to actually get it to work (especially since you must consider that the scripts could execute in any order on a user's system) One could easily enough probably write a @require framework for doing something like this however, and simply @require it in both scripts to get it to work, although it would have to be somewhat tricky of a thing to get it to work under the wide variety of circumstances that one may wish to invoke it, I can't imagine it would take more than 5 hours of work. The problem is all scripts would still require an @include for this "blank page you host" unless one could somehow trick any number of scripts to run on about:blank?scriptA&scriptB, letting them share gmGet and gmSet values to share information (detect upgrades in this case), then you can detect this result on the original page. If you control all scripts the its not really a problem. Unfortunately someone may see this as a security risk although I think it would be a lot of fun personally.l On Sat, Nov 28, 2009 at 12:04 PM, Patrick Wiseman <[email protected]>wrote: > On Sat, Nov 28, 2009 at 11:41 AM, Kwah <[email protected]> wrote: > >> > >> > (I'm assuming that the script functions on the page from which the > >> > install link was selected.) > >> > >> This assumption is incorrect. It will only ever run on the next page > load. > >> > > > > I may be filling a few too many blanks with my own thoughts, but I was > under the assumption that the process would go something like this (as > opposed to the script detecting its own installation): > > > > Script A is installed > > Script A watches for new scripts being installed > > Script B gets installed, Script A detects the new script and acts > accordingly > > That's the idea, except that there is apparently no general way for > script A to watch for new scripts being installed. (Of course, if I'm > writing both, I could have B insert something in a page which A could > watch for; but I was looking for a general way to detect the script > installation event as it happens.) > > pw > > -- > > You received this message because you are subscribed to the Google Groups > "greasemonkey-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<greasemonkey-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/greasemonkey-users?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/greasemonkey-users?hl=en.
