Discussie op greasemonkey-scripts-userscripts-cross-browser-compatible-maken

[Knabbelaar]

Vergeet niet, dat voor cross-browser compatibiliteit er goed gelet
moet worden op de specifieke verschillen in de verschillende
javascript engines, de DOM ondersteuning en de beveiligingsscope die
de browser oplegt. Zelfs binnen 1 browser, zijn ook per versie
verschillen in de featureset belangrijk.

Handige referenties hierbij zijn:
http://www.quirksmode.org/dom/w3c_html.html
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(ECMAScript)
http://www.robertnyman.com/javascript/index.html

Waar ook rekening mee gehouden dient te worden, is het veiligheids
aspect. Sommige beperkingen die voor userscripts gelden, zijn er voor
een reden: het voorkomen dat een kwaadwillend script er aan de haal
gaat met vertrouwelijke gegevens.
Door zomaar in de hoofdpagina je code te injecteren, verlies je
controle over de javascript functies die je vanaf dat moment gebruikt.
document.getElementsById kan best wel eens veranderd zijn door een
ander script...

Vandaar dat ik - als het niet nodig is - geen voorstander ben van het
standaard injecteren van je userscript.

[Lekensteyn]

Ik doe net alsof het een script is die op de servers staat van TW (of
waar dan ook). Enkele scripts hebben last van
compatibaliteitsproblemen omdat een browser een nieuwe functie (nog)
niet ondersteunt. Maar daar kan omheen gewerkt worden om volledige
cross-browser comptibaliteit te garanderen.
Zo kun je niet met addEventListener() beforeunload handlers aan window
toevoegen in WebKit browsers (Safari, Chrome). Daar kan dat alleen
door window.onbeforeunload in te stellen. Daar kan omheen gewerkt
worden, door eerst een oude listener ergens op te slaan, en nadat jouw
eigen functie is verwerkt, weer de opgeslagen functie aan te roepen.
Je mag er toch wel van uit gaan dat de gebruiker een beetje bij is met
zijn/haar browser. Het bijwerken van FF is zo gedaan.

Ik ben bekend met Quirksmode, die man doet geweldig werk.

Bij userscripts ga ik er van uit dat het een script is als
bijvoorbeeld 'script.js' van TW. De beperkingen voor userscripts zijn
aanwezig om te voorkomen dat een kwaadwillende site via een slecht
geschreven userscript de browser over te nemen, of gegevens te stelen
die normaliter niet bereikbaar zijn.
Door meteen alle JS te injecteren in de pagina hoef je je geen zorgen
te maken over extra functies (GM_xmlhttpRequest bijv) die mogelijk
gebruikt kunnen worden door een kwaadwillende site/script.
Ik denk niet dat TW het ooit toestaat om via Instellingen scripts aan
de pagina toe te voegen (zoals snellijsten links genereren, zo zou
deze niet-bestaande feature <script>-tags in de pagina stoppen).
Een userscript is hier dus een handige middel om het laatste te
behalen.

Als je al vreest dat document.getElementById wordt overschreven,
waarom gebruik je dan jQuery van TW? Dat kan ook worden overschreven.
Waarom denk je dat er 'unsafe' in 'unsafeWindow' zit? Omdat je daarmee
toch weer mogelijke lekken creërt.
Dan kun je beter meteen je code injecteren, ben je meteen van
ongebruikte functies (lees: GM_* in FF) en hacks af af. (bij hacks:
bijv. location.href = 'javascript:...')

Gewoon ervan uitgaan dat een script openbaar is. Anders zou je ook
vraagtekens kunnen zetten bij de API code van TW, die wordt gebruikt
voor externe mededelingen. Met een simpele snellijst script of
userscript kan die gemakkelijk worden overgenomen.