gmane.comp.mozilla.firefox.greasemonkey

Re: GM_util.hitch / window.setTimeout

jimbobmcgee — 2012-05-25T22:57:34

Will you ever expose the alternative setTimeout/clearTimeout routines that 
you had in 0.9.19 (e.g. as a GM_setTimeout method)?  
As a NoScript user, I was finally able to use setTimeout in the way that I 
expected, and I am keen to have that back...


On Thursday, May 24, 2012 11:33:25 PM UTC+1, Anthony Lieuallen wrote:

Re: Magic Password Generator

Caio Tunes — 2012-05-25T15:32:50

Because I found nowhere else to made a contact with you. It is sad to hear
you are not maintaining it anymore! Besides greasemonkey it is one of the
most useful extensions ever.

Thanks anyway :)

On Fri, May 25, 2012 at 10:03 AM, Anthony Lieuallen <arantius< at >gmail.com>wrote:

Re: < at >run-at document-start in FF12 fires script twice on Facebook.com?

Anthony Lieuallen — 2012-05-25T13:05:13


I do not see that behavior.  Try in a fresh profile:
http://wiki.greasespot.net/Troubleshooting_%28Users%29

Re: Magic Password Generator

Anthony Lieuallen — 2012-05-25T13:03:00

Why are you addressing this here?  This has nothing to do with greasemonkey.

And it's because I'm not maintaining that extension anymore.

On Thu, May 24, 2012 at 11:33 PM, Wackygoose <caiotunes< at >gmail.com> wrote:

Re: Re: < at >run-at document-start in FF12 fires script twice on Facebook.com?

Sam Larison — 2012-05-25T07:19:57

Do you experience different results using the refresh button versus
pressing enter in the URL bar?

Unless there is facebook specific code, I would venture a guess that this
can be reproduced on another site...

An idea would be saving the facebook page as HTML and uploading it
somewhere, although my guess is that won't trigger the same behavior.

On Thu, May 24, 2012 at 11:28 PM, Matt Kruse <matt< at >thekrusefamily.com>wrote:

Magic Password Generator

Wackygoose — 2012-05-25T03:33:32

Hey!

I was without a computer for sometime, then I got a new one, installed
firefox, and started installing my favorite addons. I Couldnt find
Magic Password Generator on mozilla addons anymore, only on Arantius
website. Is there any reason for this?


Thanks

Re: < at >run-at document-start in FF12 fires script twice on Facebook.com?

Matt Kruse — 2012-05-25T03:28:28

Nope, no iframes, and no multiple body tags. I've done tests, and it's
definitely firing twice on the same page.
For now, my work-around is to set a variable on unsafeWindow, and if
it's defined, I exit the script immediately.
I still have no clue as to what is different in this page that causes
it to trigger twice, and apparently not in FF3.6, but it does in FF12.

Matt



On May 24, 3:02 pm, "LWChris< at >LyricWiki" <lwch...< at >gmx.de> wrote:

level 11 camps

Becky Cooley — 2012-05-25T01:45:59

The script is sending random attacks to the new level 11 camps. I was
lucky enough to my attacks before loosing troops. Needs an update
quick.

Re: GM_util.hitch / window.setTimeout

Anthony Lieuallen — 2012-05-24T22:33:25

Caused, past tense.  In version 0.9.19, which is why .20 was rushed.

Right?

On Thu, May 24, 2012 at 4:35 PM, Sumeruter <sumeruter< at >googlemail.com> wrote:

GM_util.hitch / window.setTimeout

Sumeruter — 2012-05-24T20:35:54

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.

Re: < at >run-at document-start in FF12 fires script twice on Facebook.com?

2012-05-24T20:02:29

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?

< at >run-at document-start in FF12 fires script twice on Facebook.com?

Matt Kruse — 2012-05-24T16:16:27

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==
// < at >name        FB Test
// < at >namespace   http://userscripts.org/users/86416
// < at >include     https://www.facebook.com/
// < at >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

Re: Re: What can't you do, thanks to Greasemonkey's security sandbox?

Anthony Lieuallen — 2012-05-23T18:36:34


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
< at >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.)

Re: What can't you do, thanks to Greasemonkey's security sandbox?

Bluflonalgul — 2012-05-23T16:10:39

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 ab

What can't you do, thanks to Greasemonkey's security sandbox?

Anthony Lieuallen — 2012-05-22T18:15:44

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

Re: Auto update not working (Firefox, Mac)

mike cupcake — 2012-05-20T16:05:01


Let me know if you need anything further.

Re: Auto update not working (Firefox, Mac)

Anthony Lieuallen — 2012-05-20T15:29:54


https://github.com/greasemonkey/greasemonkey/issues/1555

Re: Auto update not working (Firefox, Mac)

mike cupcake — 2012-05-20T13:29:01

 
+ I forgot to mention:    Turned off all other plugins;   confirmed 
installurl="https://userscripts.org/scripts/source/125470.user.js"

Re: Auto update not working (Firefox, Mac)

mike cupcake — 2012-05-20T13:22:24

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.

Re: Auto update not working (Firefox, Mac)

mike cupcake — 2012-05-20T12:57:41


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

Re: Auto update not working (Firefox, Mac)

Anthony Lieuallen — 2012-05-19T23:29:33



I'd love to see more concrete information but at this point I suspect stale
caches.