http://blog.gmane.org/gmane.comp.mozilla.firefox.greasemonkey hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16894 <pre>Calling window.setTimeout with a string of commands as first parameter in Greasemonkey scripts causes an exception: "Invalid arguments to GM_util.hitch()." In a normal browser environment this works perfectly, and previous Greasemonkey-versions did not have this bug either. </pre> Sumeruter 2012-05-24T20:35:54 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16893 <pre>Am 24.05.2012 18:16, schrieb Matt Kruse: I could well imagine some iframe that retriggers the script because two "document-start" events are fired, maybe? Or does the page have two html or body tags? </pre> LWChris< at >LyricWiki 2012-05-24T20:02:29 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16892 <pre>After updating FF from 3.6 to the current 12, user scripts run at document-start (in certain situations) are firing twice - once at document-start as intended, then again at document-end. Sample script: // ==UserScript== // &lt; at &gt;name FB Test // &lt; at &gt;namespace http://userscripts.org/users/86416 // &lt; at &gt;include https://www.facebook.com/ // &lt; at &gt;run-at document-start // ==/UserScript== alert(document.getElementsByTagName('BODY').length); When viewing the home news feed, this alerts "0" (expected), but then also alerts "1" after the document loads. But when I log off and load the login page, it only alerts "0"! Any idea if this is a Greasemonkey bug or a FF bug? Or a quick in Facebook? I can't duplicate the same functionality on CNN.com, for example. Is Facebook doing something that causes GM to fire again? I've not yet tested other browser versions, will do that as well. Thanks! Matt Kruse </pre> Matt Kruse 2012-05-24T16:16:27 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16891 <pre> This topic is probably complex enough for its own thread. But if by "GM_ specific" you mean the privileged GM_ prefixed functions only available in current Greasemonkey, then things won't change for you (as long as you &lt; at &gt;grant the things you need). (At least, I don't intend for them to change, and would consider a release that breaks them unworthy of release.) </pre> Anthony Lieuallen 2012-05-23T18:36:34 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16890 <pre>I'm not sure that the trick we use in our GM script is relevant to your question, but I prefer to ask, just in case our script might not work well with GM 1.0. The site we plug into relies heavily on AJAX and some kind of JSOND. So we have some framework to deal with that and keep an abstraction layer over this problem, in order to ease the different insertions we handle. The main technique we use is to "hook" on a callback function of the site's javascript. For example let say that the page DOM nodes are populated by a js.SiteFillPage(data) function, from the site scripts. Our script saves this function with OriginalFunction=window.wrappedJSObject.js.SiteFillPage. Then we replace this function by our own: window.wrappedJSObject.js.SiteFillPage = function(data) { ... // checking things... window.unsafeCall(function() { OurFunctions.ProcessPage(); }); return OriginalFunction(data); } The OurFunctions.ProcessPage is our main function in our script, and it uses GM_ specific functions. As you see, to be able to use GM functions from such a call, we use this unsafeCall function: window.unsafeCall = function(fn) { if(typeof fn == 'function') window.setTimeout(fn, 0); else GM_log("Error: window.unsafeCall argument must be a Function!"); }; I would like to know what impact the 1.0 version would have on our technique, or what we could use for a stronger security. Thanks a lot for Greasemonkey :) </pre> Bluflonalgul 2012-05-23T16:10:39 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16889 <pre>I'm finally starting work in earnest on Greasemonkey 1.0. The major change is to move towards explicitly requesting access to the elevated privilege APIs that Greasemonkey has historically exposed to user scripts and, more importantly, _not_ imposing the convoluted security restrictions that make them safe, if you don't request access to them. So I'd like to start assembling a list of things that would work in standard JavaScript in the page, but break in Greasemonkey. I'd like to be sure that the changes made going forward make these things possible again. I know of a few of these things and can test for them. But I've understood the limitations for so long that I almost have a mental block for automatically not using them. So, if there's a thing that should work but breaks in Greasemonkey please let me know. This work is happening in https://github.com/greasemonkey/greasemonkey/issues/1427 </pre> Anthony Lieuallen 2012-05-22T18:15:44 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16888 <pre> Let me know if you need anything further. </pre> mike cupcake 2012-05-20T16:05:01 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16887 <pre> https://github.com/greasemonkey/greasemonkey/issues/1555 </pre> Anthony Lieuallen 2012-05-20T15:29:54 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16886 <pre> + I forgot to mention: Turned off all other plugins; confirmed installurl="https://userscripts.org/scripts/source/125470.user.js" </pre> mike cupcake 2012-05-20T13:29:01 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16885 <pre>Testing in new Mac FF profile = exact same behaviour. New profile; install GM; install script; edit script on us.o; clear FF cache; restart FF. Find Updates = nothing happens. Turn off GM Secure Updates; Find Updates = update downloads and installs fine. </pre> mike cupcake 2012-05-20T13:22:24 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16884 <pre> I've tried clearing the Mac's Firefox cache then restarting FF (repeated just now to confirm) - are there other caches involved? I'll follow the greasespot wiki advice about testing in a fresh FF profile next, I realised yesterday that as the FF profile is synced between my Mac and PC machines I've only really been testing this in one environment. Tried to find out how to log what's happening behind the scenes when I right-click/Find Updates (as there's no visible change in the AOM window), having greasemonkey.logChrome set true doesn't bring anything up in the error console; is there a way to do this? thanks again, mike </pre> mike cupcake 2012-05-20T12:57:41 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16883 <pre> I'd love to see more concrete information but at this point I suspect stale caches. </pre> Anthony Lieuallen 2012-05-19T23:29:33 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16882 <pre> Whoops, I've gone and got myself confused by some info from the us.o forum. So backing up a couple steps and re-evalutating: - the metadata check over Coral is http, this url loads fine. - The https us.o installurl loads fine when I install the script. - Nothing happens when I force an update with GM set to Secure Updates - Turning off GM Secure Updates, scripts (mine and others) autoupdate from us.o as expected, no need to force a check. - Same behaviour on two machines, Mac10.6 (gm 0.9.20) and Win7 (gm 0.9.19). I'm stumped. Agreed, that's why I said when forcing a check ;-) AOM annotation would be great. thanks, mike </pre> mike cupcake 2012-05-19T11:39:48 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16881 <pre> But that URL is specifically "http" (no S) as you posted it, no? I'd expect that not to work, coral doesn't offer HTTPS. I personally wouldn't want popups at random times because of automated update checks. But some sort of notification somewhere might be nice. I think there might be an appropriate way to annotate this in the AOM. </pre> Anthony Lieuallen 2012-05-18T19:46:24 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16880 <pre>Confirmed as a network issue, trying to load the updateurl from config.xml as https in a browser: https://userscripts.org.nyud.net/scripts/source/125470.meta.js instantly brings up a connection error, also a traceroute doesn't get anywhere. I guess either Virgin have decided to block it along with the Pirate Bay or this distribution network isn't up to much :-) It'd be useful if GM raised an alert if it gets a connection error when forcing an update check. </pre> mike cupcake 2012-05-18T17:55:55 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16879 <pre> Indeed, I'd be interested in an option (per script maybe) to turn this off So my problem seems to be down to secure updates, I reinstalled the script then made a change on us.o and confirmed the config.xml is set for HTTPS: installurl="https://userscripts.org/scripts/source/125470.user.js" updateurl="http://userscripts.org.nyud.net/scripts/source/125470.meta.js" click on the script in Firefox's list, Find Updates. Nothing happens, but if I turn off Secure Updates in GM options and repeat updates straightaway. Same behaviour on a Win7 box. Looking like this might not be an issue at my end.. ? </pre> mike cupcake 2012-05-18T15:38:51 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16878 <pre> Yes. Just reinstalling at all should make the updated/modified times match properly to allow updates. (I've got into the habit of working on changes locally then updating the But it's tough for us to know what the local changes are, so we err on the side of safety (not throwing away the potentially valuable changes that only exist on your disk). </pre> Anthony Lieuallen 2012-05-18T13:34:23 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16877 <pre> Aha found it in config.xml, located here on Mac: ~/Library/Application Support/Firefox/Profiles/[profile name]/gm_scripts/config.xml </pre> mike cupcake 2012-05-18T12:19:09 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16876 <pre> That'll work in other software besides Greasemonkey (I think?), what else makes it better? If there's more than one style to change GM_addStyle seems less cluttered, and won't this method fail if the element is created after the script has run..? </pre> mike cupcake 2012-05-18T12:02:41 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16875 <pre> On Thursday, May 17, 2012 3:58:28 PM UTC+1, Anthony Lieuallen wrote: Yes, am using this script to change the URL: http://userscripts.org/scripts/show/127520 Do you know where I can find this? I understand that if not specified in the metadata it defaults to the install URL (or in the case of us.o the meta.js) but couldn't find out how to check. AHA, this I did not know. Would explain this particular script not updating as yes I had edited it on disk. Is there a way to manually change this flag? Or I guess deleting the script, restarting Firefox and reinstalling from us.o would clear it? (I've got into the habit of working on changes locally then updating the version on us.o, and I move between a few different machines so the locally-edited flags will be spread among them for different scripts....) Thanks for the help! </pre> mike cupcake 2012-05-18T11:56:56 http://permalink.gmane.org/gmane.comp.mozilla.firefox.greasemonkey/16874 <pre>For clarification: this script was copied verbatim from another script that DOES work, with the non-relevant bits stripped out. And, to reiterate, it works fine on one server, but not another. On May 17, 4:19 pm, BillTheTailor &lt;billthetai...&lt; at &gt;gmail.com&gt; wrote: </pre> BillTheTailor 2012-05-17T21:22:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.firefox.greasemonkey