89016 - User JavaScripts on page load (build Greasemonkey/Scriptish script support into the add-ons manager)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement)

Description

[Ben Bucksch (:BenB)]

It would be cool for a user to have the option to modify each page that gets
displayed in the browser. The user could write/specify a JavaScript that
accesses and modifies the DOM to rewrite the page to the user's wishes.

Applications are nearly endless:
- Implementing features like "Remove all <script> tags"
- Translators
- Buttons to hide/unhide left and right columns (often used as site directory,
as seen on www.mozilla.org) of the "page table", which often cause annoying
horizontal scrollbars.

Implementation should be easy:
- Similar to the page's onload, allow the user to specify a script, which will
be loaded for each page, operating with the page's (or chrome?) capabilities.
- An extension would be to sequentially load *several* scripts, possibly for
some domains/protocols only. This extention could be implemented as such a
script itself, chainloading the other scripts.

Note: This is similar in goal to bug 13014, but uses a completely different
technical approach: Bug 13014 operates at the network level, on raw data
streams, with native filters, while the "filters" in this bug operate on the
already parsed HTML in the DOM, and they can only be scripts known to Gecko. So,
the applicability of this bug is theoretically more limited, but it is *much*
easier to implement, both the architecture and the concrete scripts.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->DOM

Comment 2

[Johnny Stenback (:jst)]

-> Future.

Comment 3

[djk]

I believe that the Context Menu Extentions
(http://white.sakura.ne.jp/~piro/xul/_extensions.en.html) has this feature
buried somewhere:
http://white.sakura.ne.jp/~piro/xul/doc/help-en.html#customscript

Comment 4

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 5

[Asa Dotzler [:asa]]

*** Bug 159017 has been marked as a duplicate of this bug. ***

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

*** Bug 241823 has been marked as a duplicate of this bug. ***

Comment 7

[Tim Powell]

For anybody who missed it, the Greasemonkey extension for Firefox basically
provides this. See http://greasemonkey.mozdev.org Another browser includes
support for user scripts as part of the product. Should we also have it as a
built-in tool like user stylesheets?

Comment 8

[lucianolll]

(In reply to comment #0)
> It would be cool for a user to have the option to modify each page that gets
> displayed in the browser. The user could write/specify a JavaScript that
> accesses and modifies the DOM to rewrite the page to the user's wishes.

> the applicability of this bug is theoretically more limited, but it is *much*
> easier to implement, both the architecture and the concrete scripts.

Reply
Partial Solution
With the introduction of this archive with the following codes; inside of the
folder of preferences of the navigator; Archive configured for the user; Here it
is a Bug that must be corrected;
<H3>
file:///C:/Program files/Mozilla Firefox/defaults/pref/macros.js
</H3>
<script>
// <![CDATA[
document.onload = function() {
var adibody = document.getElementsByTagName('body')[0];
if(document.bgColor.toLowerCase() == '#ffffff' ||
document.body.style.backgroundColor =='#ffffff' ||
window.getComputedStyle(document.body,null).getPropertyValue('background-color')
=='#ffffff') {
adibody.style.backgroundColor= '#f4fff1!important';
}

var adtab = document.getElementsByTagName('table');
for(var itab=0; itab<adtab.length; itab++) {
if(adtab[itab].getAttribute('bgColor').toLowerCase() == '#ffffff' ||
adtab[itab].style.backgroundColor == '#ffffff' ||
adtab[itab].bgColor.toLowerCase() == '#ffffff') {
adtab[itab].style.backgroundColor= '#f4fff1!important';
}
}

var adtd = document.getElementsByTagName('td');
for(var itd=0; itd<adtd.length; itd++) {
if(adtd[itd].getAttribute('bgColor').toLowerCase() == '#ffffff' ||
adtd[itd].style.backgroundColor == '#ffffff' || adtd[itd].bgColor.toLowerCase()
== '#ffffff') {
adtd[itd].style.backgroundColor= '#f4fff1!important';
}
}

}

self.moveTo(0,0);
self.resizeTo(770,600);

// ]]>
</script>

Comment 9

[Jesse Ruderman]

*** Bug 309112 has been marked as a duplicate of this bug. ***

Comment 10

[Jesse Ruderman]

*** Bug 309112 has been marked as a duplicate of this bug. ***

Comment 11

[Jan Moesen]

Can this be closed since Greasemonkey (first mentioned in comment 7) takes care of this?

Comment 12

[Ben Bucksch (:BenB)]

I guess so

Comment 13

[Ben Bucksch (:BenB)]

I'd really appreciate this to be built into Firefox, yes.

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

I had explored doing this back in 2009, as part of the first initial exploration in uplifting Jetpack to be in-product. I wish I had made more notes now:
https://wiki.mozilla.org/Firefox/Projects/Jetpack_Uplift_Exploration/Notes#Native_support_for_Content_Scripts
Sadly, I can't seem to find my old prototype code.

The rough outcome of that exploration was it works fine technically, but that Jetpack's Pagemods would fill that gap (see https://wiki.mozilla.org/Labs/Jetpack/JEP/17). However, existing scripts won't run as-is - they need to be converted over to be Jetpack extensions.

Jetpack has resulted in a large number of extensions that are essentially conversions of content scripts. However, that number is *tiny* compared to how many content scripts are available. So I do wonder if it's time to revisit this.

Also, I think Greasemonkey is a rather poor example of how this could be integrated. Scriptish is a much more modern implementation (https://addons.mozilla.org/en-US/firefox/addon/scriptish/).

Comment 16

[Erik Vold [:erikvold] (please needinfo? me)]

So I've got plans to port Scriptish to the SDK, so we could start there, then discuss pulling that work into FF after the SDK is in FF.

Comment 17

[Ben Bucksch (:BenB)]

Shouldn't we start with supporting Greasemonkey scripts? They had the idea, have the longest history, and have a big library of scripts.

Comment 18

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Ben Bucksch (:BenB) from comment #17)
> Shouldn't we start with supporting Greasemonkey scripts? They had the idea,
> have the longest history, and have a big library of scripts.

Scriptish runs the same scripts as Greasemonkey does. But it does a much better job of it, and adds some additional APIs for the scripts.

Comment 19

[Jorge Villalobos [:jorgev] (he/him)]

Supporting userscripts would be great for us AMO reviewers. We get way too many add-ons that are just userscript wrappers and are probably bulkier than should be. Basing it off Scriptish sounds like a good idea, as long as we support existing GM scripts.

Comment 20

[Kris Maglione [:kmag]]

There are some issues with supporting userscripts natively. The worst is that the scripts on userscripts.org are pretty universally horrific, so unless we add support to AMO and have proper code review, I don't much like the idea of exposing more of our users to that level of dross. The vast bulk of these converted userscripts that I've seen submitted to AMO, I've rejected wholesale, usually due to major security issues.

As for supporting exiting Greasemonkey scripts, there are some issues there too. Quite a lot of Greasemonkey scripts use 'return' at the top level. Greasemonkey handles that by wrapping the code in a closure and then evaling it, which is ugly, inefficient, and non-cacheable. If we were to do this, we should use the subscript loader to load scripts into a sandbox, and change the caching policy so that code loaded into content privileged sandboxes is cached, or at least can be cached.

Scriptish might be a good place to start. It already does decent add-on manager integration, and the codebase isn't too bad, but there would need to be some changes to bring it in line with the m-c codebase. The userscript metadata store should be converted to sqlite, scripts and their resources should probably be stored the same way as packed XPI add-ons, page load efficiency differences would need to be tested. Unless something's changed, there's also the issue of dozens of utility functions being separated into their own JavaScript modules, which doesn't make sense.

We'd also need a thorough security review of userscript sandboxing and the update mechanism.

Comment 21

[Alexandre Poirot [:ochameau]]

(In reply to Kris Maglione [:kmag] from comment #20)
> Scriptish might be a good place to start. It already does decent add-on
> manager integration, and the codebase isn't too bad, but there would need to
> be some changes to bring it in line with the m-c codebase. The userscript
> metadata store should be converted to sqlite, scripts and their resources
> should probably be stored the same way as packed XPI add-ons, page load
> efficiency differences would need to be tested. Unless something's changed,
> there's also the issue of dozens of utility functions being separated into
> their own JavaScript modules, which doesn't make sense.

Erik is aiming to port scriptish to the SDK, so that we can share our content scripts code which overuse sandboxes and subscript loader. It would so gain from all jetpack experience in term of sandboxing and avoid duplicate works! Some stuff may be tuned in jetpack for the sake of userscripts, and userscripts will gain from jetpack code (first for all the work on xraywrapper bugginess).

It doesn't mean that we shouldn't do any security review, I'm just try to vouch Erik in this quest, and will surely help him about all these sandboxing issues.

Comment 22

[Matthew N. [:MattN]]

Since web extensions are so easy to make, are cross-browser, and get reviewed on AMO, I think it's safe to say that they have significantly reduced the need for this bug.