All right, so I've read through those threads, and I can understand
pretty well why this decision was made (and that it was indeed *made*,
not merely blundered into by accident ;-)). It makes a lot of sense.
However, I'm not seeing the workaround you mentioned.
In point of fact, my script requires something very like the failure
mode mentioned in the second thread, as you've probably noticed: I'm
spinning off a long-running task from inside the page itself (for
various reasons, which I'll probably re-examine; they may not be enough
to warrant this kind of enormous effort), and needing to get results
when the task is done (e.g. time taken and other basic stats). I need to
re-examine why I am in fact injecting functions and waiting for
callbacks; I believe the original reason was for performance, but I'm
not at all sure it's worth this much effort.
Still, performance is a big issue here; my script is O(n) [gag, I know],
and can easily reach the hundreds of milliseconds range on a large page
with a few tens of thousands of nodes (e.g. W3C standards pages).
Statistics are mostly performance-related, for diagnosing problems.
Taking a deep breath, stepping back, and looking at the whole project, I
can see several possible solutions:
1. Drop the statistics-logging. Possible, somewhat annoying, trivial.
1a) Only use statistics logging on my own machine, and use
unsafeWindow or similar kludgy [and VERY DANGEROUS!!!] hack, enabled by
a config setting.
2. Rework back to a previous design, and skip the entire injection
mechanism entirely. I'll have to check performance and other impacts of
this solution.
3. Find some other workaround, such as the one you mentioned, that
allows me to keep logging and injecting, but without using unsafeWindow.
I have gotten (1a) to work, pretty much, so I may be able to just use
that. I'd still greatly appreciate knowing what the workaround was, though.
P.S. At several points in the threads, upgrading to FF3beta was
mentioned as a way for userscript authors to avoid the problems
introduced by call-chain analysis and so forth, (apparently) without
suffering security holes. What happened to that, and why would that have
worked?
Anthony Lieuallen wrote:
> On 8/2/2009 9:29 PM, cc wrote:
>
>> Digging into the GM source code, it sure looks like it was a deliberate
>> choice (which I'd rather like to hear the reasoning behind; I can't
>> myself quite figure it out).
>>
>
> In reverse-chronological but less-to-more-useful order:
> http://groups.google.com/group/greasemonkey-dev/t/3eee8cfb32677bf1
> http://groups.google.com/group/greasemonkey-dev/t/68a9fc3101cfdade
> http://groups.google.com/group/greasemonkey-dev/t/933ecdb307c4386d
>
> Note that the links here provide a direct and (mostly) straightforward
> workaround, though it certainly could be easier to find.
>
>
> >
>
> ____________________________________________________________________________________
> Super simple small business
> invoicing for Mac OS X.
> http://click.lavabit.com/?pub=78&ad=1&url=aHR0cDovL3RoZS1kcmVhbS5jby51ay9pbnZvbGVyLw==
> ____________________________________________________________________________________
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
