jscher2000 Author

Re: @ngudger2021:
Maybe something along these lines:

var blurred = document.querySelectorAll('img[src*="~"]'); // tilde anywhere in file name or path for (var counter=0; counter<blurred.length; counter++){ var badname = blurred[counter].src; var goodname=badname.substr(0, badname.indexOf("~")) + badname.substr(badname.lastIndexOf(".")); blurred[counter].src=goodname; }


Re: @jscher2000:
Hmm, I don't see a way to edit that last post. Just to clarify, sites still can query the plugins connection by individual plugin name; this preference only affects the easiest way to gather the list.


Firefox has a hidden preference named plugins.enumerable_names that defaults to * meaning that websites can enumerate the entire plugins collection. You can edit this preference to limit what sites can find, which may make your browser appear less unique.

For example:

Open a tab to this test page to see what shows up in normal enumeration (keep open for later comparison): https://jeffersonscher.com/res/jstest.php

Then select and copy this string: Adobe Acrobat,Shockwave Flash,Silverlight Plug-In

In a new tab open about:config, double-click the plugins.enumerable_names preference, and paste that in place of the * and OK your change.

Then in a new tab, launch the test page again and compare the difference with the previous test results. The new page should only find the specified plugins using simple enumeration.


Re: @DevinJB:
You can use your browser's inspector (Inspect Element) feature to dive into the structure of the page and figure out how to extract the desired value. In particular, you will need to determine the most reliable selector (this could be a unique id attribute, or you may need to stack various tags and class names). https://developer.mozilla.org/docs/Web/Guide/API/DOM/Locating_DOM_elements_using_selectors

But... the second part is a problem. User scripts cannot write to the file system, just as web pages cannot write to the file system. If that is essential, you would need to write an add-on or separate program that has more privileged access to the system. If you are not limited to saving a file, you can stash data in local DOM storage, or in Greasemonkey preference data, or in a cloud (by posting to a server under your control).



Re: @RyanGittins:
It is bizarre compared with 16 installs from MonkeyGuts and 12 installs from GreasyFork over the same time period, and no obvious chatter in Google. Maybe it got hot on Facebook somewhere?

Or it count be a counting problem. I assume each site takes a different approach to how it discounts duplicate installs, and the formula might need to be reviewed.


Re: @Computerexpert:
One issue is: there is a typo (missing closing quotation mark on the property name) in this line:

$(this).closest('li.li').css("background-color,"yellow");

Re: @cuzi:
Thanks for asking this. I want to propagate some preference changes across open tabs of a web app (no userscript) without the user having to reload from the server, and needed to look into this.

In modern browsers (unfortunately, I also need to support IE8), I should in theory be able to use an event listener on local storage to share data between tabs/windows. Because it's my site, I don't have to worry about private information leaking to the site, but if that is a concern for what you are passing, then local storage would not be the ideal approach. I suppose in that situation you could increment a counter (or otherwise signal the other pages) to trigger a GM_getValue().

Here are some discussions of using local storage in this manner (I have not tried to implement it):


Re: @Marti:

I didn't intend to suggest that my hackish code might be of any value for the site. I seriously doubt it would be.

But I think I disagree with you on the BSD 3-clause license: it has long been considered GPL-compatible and I can't think of any reason for that to have changed with version 3.




Re: @Marti:

Don't get me wrong, I appreciate the updates. I'm just trying to stay on top of things in an efficient manner to provide good customer service.

In the USO days, these are what I used:

(1) Email notifications for discussion posts on my scripts. That might have been a relatively recent feature: the earliest one I found in my deleted messages was from 4/5/2013 (subject line starts with Posting:). I'm not so bored at work that I want an immediate email notification of a post. I wouldn't mind checking:

(2) A page called "Discussions on your scripts" at http://userscripts.org/home/comments that was handy for monitoring new and updated topics across all my scripts. In the context of this site, this does seem to be a kind of discussion filter. I'm not sure if there is a specific issue open for it. #199 seems related but not focused on the logged-in user's scripts in particular. I may be missing other issues; I find GitHub a little bewildering.


Re: @Marti:

Regarding


"More query options will be available at a future date."

is any other information available? Is input or voting relevant?

Not sure it's a relevant point of comparison, but in the time I've gotten six "Feedback" discussions (five with substantive issues) at Greasy Fork on a script hosted on both sites, I have had zero "Issues" submitted here. I'm puzzled by this and want to make sure I'm not missing something.



Any chance this is in process already? If not, it would save a lot of clicking.


Re: @Marti:
Happy to hear it's working for you.

Liking is like a very easy form of feedback; not so informative for the author, but any feedback is better than none.


It is a difficult question to answer, since you do not need to register to use the script. Upon installation or first run, the script makes a request to my webserver for a file (either an image or a script). I keep track of those requests.

This is the information I have for 2014, for installations from Greasy Fork, OpenUserJS, and userscripts.org combined:

1/1/2014-3/31/2014: estimated 7,642 new and upgrade installations

4/1/2014-6/30/2014: estimated 3,400 new and upgrade installations

This script had a lot of external links to userscripts.org which are now broken, which may explain the significant drop in installations.


It is a difficult question to answer, since you do not need to register to use the script. Upon installation or first run, the script makes a request to my webserver for a file (either an image or a script). I keep track of those requests.

This is the information I have for 2014, for installations from Greasy Fork, OpenUserJS, and userscripts.org combined:

1/1/2014-3/31/2014: estimated 405 new and upgrade installations

4/1/2014-6/30/2014: estimated 456 new and upgrade installations

Obviously the installation count for the script on this site is seriously inflated.


It is a difficult question to answer, since you do not need to register to use the script. Upon installation or first run, the script makes a request to my webserver for a file (either an image or a script). I keep track of those requests.

This is the information I have for 2014, for installations from Greasy Fork, OpenUserJS, and userscripts.org combined:

1/1/2014-3/31/2014: estimated 265 new and upgrade installations

4/1/2014-6/30/2014: estimated 330 new and upgrade installations

Obviously the installation count for the script on this site is seriously inflated.


I log the requests for my @require script and see fewer requests on my server than are indicated by the install count here, in some cases far fewer. In order from the oldest to newest, the difference is:

  • Script #1 (05/20): 250 vs. 42
  • Script #2 (05/20): 275 vs. 123
  • Script #3 (05/25): 220 vs. 206

Not really a big deal, but puzzling.


Thanks, sizzle.

(I know in theory I can check the source. But I can assure you there was no way I could answer my own question on this.)


Regarding login methods:

I am not especially conversant with OAuth, but I know I can de-authorize the connection on Google's end from this page:

https://security.google.com/settings/security/permissions

Do I need to be concerned that OpenUserJS.org has retained anything that could ever compromise my Google account? If not, then I don't see any harm retaining it. Simply knowing I once used a Gmail address for signin doesn't seem to be a big problem.



Thanks!

Learning GitHub looks to be beyond me right now, but I think if I want the ability to see past versions I will need to learn it sooner or later.


I'm having a little difficulty getting around... Has anyone created any documentation that would help orient scriptwrights who want to move scripts here from userscripts.org?