Closed Bug 423732 Opened 17 years ago Closed 17 years ago

Can we grep addon source code for uses of mozIJSSubScriptLoader.loadSubScript

Categories

(addons.mozilla.org Graveyard :: Administration, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mfinkle, Assigned: clouserw)

Details

Attachments

(1 file, 1 obsolete file)

A security bug fix on trunk has caused mozIJSSubScriptLoader.loadSubScript to only accept chrome:// URLs We'd like to see the impact of the change, especially if we move it to branch, on addons in AMO.
One addon you're going to miss on AMO: http://mozilla.zeniko.ch/userchrome.js.html (and my users are already complaining at http://forums.mozillazine.org/viewtopic.php?p=3299905#3299905 ;-)).
OS: Mac OS X → All
Hardware: PC → All
Prefbar also stopped working. Used to work fine whit a bumped maxVersion. PrefBar - http://prefbar.mozdev.org/
Best I can do is an rsync of the add-ons from the end of January. I filed bug 423803 to put the rsync on a cron job for the future. Grep is currently running.
Assignee: nobody → clouserw
grep -r "mozIJSSubScriptLoader.loadSubScript" * returned nothing. I see that userchrome.js is using the string "mozIJSSubScriptLoader).loadSubScript" Please give me the exact string you want to search for. Thanks. :)
"loadSubScript"
Attached file grep -r "loadSubScript" * > 423732.out (obsolete) (deleted) —
grep for a best-guess on the latest versions of the add-ons.
Not sure if grep is picking up all extensions, my extensions Local Install, Link Wrapper and Splash use "loadSubScript" to do manual imports of preference settings.
How about: grep -r -6 "loadSubScript" * ? A lot of the info I want seems to be on the following line in many extensions.
(In reply to comment #7) > Not sure if grep is picking up all extensions, my extensions Local Install, > Link Wrapper and Splash use "loadSubScript" to do manual imports of preference > settings. > Looks like it's using an older version (Splash 1.2.2). I can try to update the files tonight.
I rsync'd the files to a faster machine and updated the files to the latest ones I have. From a previous bug we know the dates on the files are unreliable so my best guess methadology is `ls | tail -n2 | head -n1` to get the latest add-on. That makes the assumption the add-on's name never changes and the versions are consistent and in order. If someone has a better idea, I'm happy to hear it. (this pulls Splash 2.0.0.1, btw). Boris - new grep coming up.
Aaahhh, the new box makes this so much faster.
Attachment #310418 - Attachment is obsolete: true
Is it just me or are these pretty old files? I see, for example, ChatZilla 0.9.79, but not .81 ? Does this matter?
(In reply to comment #12) > Is it just me or are these pretty old files? I see, for example, ChatZilla > 0.9.79, but not .81 ? Does this matter? > Like I said, the results are subject to: 1) The rsync is from the end of January 2) The version guesser I talked about above
glad to see splash and link wrapper getting represented in the grep, just scratching my head on Local Install not being picked up, that's the one that originated my export/import settings logic, tia.
(In reply to comment #14) > glad to see splash and link wrapper getting represented in the grep, just > scratching my head on Local Install not being picked up, that's the one that > originated my export/import settings logic, tia. > Version 1 and 2 were named "mr_tech's..." and the newer versions are named "mr_tech..." Unfortunately, this breaks the best guess algorithm - it chose version 2.0.1.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Component: Add-ons → Administration
QA Contact: add-ons → administration
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: