I've got a little problem with UserScripts in Google Chrome, to be precise with getting to the object window of an iframe. Very doable via the Google Chrome console, very impossible via the UserScript or so it seems so far. To be honest it seems as if it was on purpose, as if there was some reason why I'm not allowed to access other window objects.
document.body.innerHTML += "<iframe name='iframe'></iframe>";
console.log(top.frames.iframe);
console.log(window.frames.iframe);
console.log(unsafeWindow.frames.iframe);
console.log(document.getElementsByName('iframe')[0].contentWindow);
console.log(document.getElementsByName('iframe')[0].contentDocument.defaultView);
-->
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:14 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:15 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:16 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:17 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:18 undefined
Might I ask what Chrome's problem is? I don't really get why should a UserScript have lesser access to javascript than a normal script, what are the implications? By the way, yes, the iframe is on the same domain and protocol. :(
UnsafeWindow isn't support by Chrome, try TamperMonkey, pretty sure it provides read-only access to that variable.
contentWindow.document isn't available for Chrome. contentDocument should work.
Also, XMLHttpRequest for cross domains also aren't supported. Most of these are for security purposes. Userscripts in Chrome are content scripts, they cannot access the functions/variables defined by web pages or by other content scripts. It's mostly for security and isolation of scripts, to prevent scripts from conflicting with each other.
As for document.getElementsByName('iframe')[0].contentWindow, I think it's because the way you're trying to add in your iframe. For starters, don't name your iframe as 'iframe', always a very bad practice.
Instead to attempting to add it into the body's innerHTML, use appendChild(), and append a new iframe object into document.body. Also, instead of document.getElementsByName, try document.body.getElementsByName.
I write greasemonkey scripts for firefox, and Chrome seems too restrictive. And I hope you know about the location hack for userscripts. Check out http://wiki.greasespot.net/Location_hack . You can use Javascript in your userscripts ;) And just to let you know right now, I would VERY much warn against messing with iframes and userscripts. I've wrote a script for Greasemonkey, been trying for 6 months, but somehow, when I involve code inside the iframe, half of the time, that result is undefined, and I never get into that problem with javascript. Also, if you inject .js script objects into a document from a userscripts, the new code is still somehow affected, and so how, randomly, elements show up as undefined. After 6 months of trying, I gave up, and I just have a bookmarklet just injects a .js script into documents manually. Of course, you don't have to do that, you can just use a location hack to inject the code from a userscript. But as for writing entire scripts based on userscripts for iframes, I'm staying far far away...
Related
i use an external script from Air-bnb. The script causes an error in Internet Explorer. For Air bnb it is not possible to fix this script. Is there a possibility to fix it by my self?
This function is not supported by IE
if(c.includes(r))return t
On this site i load the script via iframe:
https://www.immvestwolf.de/rent-a-home-2
i look forward to find a solution...
Thanks
No. If they don't support IE, it's their decision and the iframe is a different context that won't affect the JavaScript running in the top/parent context (your page).
You can exclude the iframe from IE and have IE users go directly to Airbnb for the specific set of actions you want them to go through.
No, you cannot. If you use an iframe to load external content there is absolute no way to manipulate or react.
Yes, you can.
Issue is .includes is a part of ES6 features and belongs to String and Array. These features are not supported by IE. If you include the polyfills, it should work.
References:
Array.includes MDN
String.includes
Note: Polyfills should be added on the page that is having issues and not on parent/root page
Userscripts are used by add-ons like Greasemonkey. But how can I utilize these scripts in my site?
For example, I found a script could eliminate ads in videos, and I want to put this script in my site, so people in my site wont't see those ads
I've tried just to save and put it in <script> in the head, but something just went wrong.
(TypeError: document.body is null)
I also tried to put it just before </body>, no error reported this time, but something still doesn't work.
And I'm wondering how Greasemonkey works? Does it just insert scripts in the webpage? How does it load scripts into the pages?
Greasemonkey and Userscripts.org are meant to provide kind of lightweight extensions for the browser, not for the webpages. I.e. you install them as the user inside your browser.
Some of the trivial scripts might be incorporated into webpages, but in general, Greasemonkey has some "superpowers" to do things that ordinary JavaScript can't do due to security constraints. For instance, issuing (and reading response of) cross-domain XMLHttpRequest, interactions between frames from different origin etc.
Normally Greasemonkey scripts are executed when DOMContentLoaded is fired by the browser (this can be changed using #run-at directive to execute the script before anything is loaded).
If the script has #grant none in its GM meta section, then it could be perhaps incorporated into your site, but it depends on what it exactly does.
Bear in mind also that Greasemonkey is a Firefox extension (there's equivalent extension for Chrome and also some limited native support from Chrome and Opera). Many userscripts will likely fail in IE8.
I was facing an issue while developing this small userscript. When I wanted to block every XMLHttpRequest from the running website with my script, nothing was happening (at least with Chrome):
function main() {
// Override XHR.open with a custom function
window.XMLHttpRequest.prototype.open = function() {
// Nothing... so it's supposed to block every xhr.open() call
}
}
main();
Same thing when replacing window by unsafeWindow.
However, when I used this little trick, everything worked like a charm:
// No more call to main(), and:
var script = document.createElement("script");
script.textContent = "(" + main.toString() + ")();";
document.body.appendChild(script);
Every call to xhr.open is replaced by my custom function, no more AJAX.
So I guess the window element is not the same when main is called from inside the script than when it's called from a <script></script> container. Can someone explain me why ?
See "Are Chrome user-scripts separated from the global namespace like Greasemonkey scripts?". Both Chrome userscripts/content-scripts and Greasemonkey scripts are isolated from the page's javascript. This is done to help keep you from being hacked, but it also reduces conflicts and unexpected side-effects.
However, the methods are different for each browser...
Firefox:
Runs scripts in an XPCNativeWrapper sandbox, unless #grant none is in effect (as of GM 1.0).
Wraps the script in an anonymous function by default.
Provides unsafeWindow to access the target page's javascript. But beware that it is possible for hostile webmasters to follow unsafeWindow usage back to the script's context and thus gain elevated privileges to pwn you with.
Chrome:
Runs scripts in an "isolated world".
Wraps the script in an anonymous function.
Strictly blocks any access to the page's JS by the script and vice-versa.
Recent versions of Chrome now provide an object named unsafeWindow, for very-limited compatibility, but this object does not provide any access to the target page's JS. It is the same as window in the script scope (which is not window in the page scope).
That said, the version of your script that used unsafeWindow should work on/in Firefox if implemented correctly. It might work using the Tampermonkey extension on Chrome, but I'm not going to double-check that right now.
When you do that "trick" (var script = document.createElement("script"); ...), you are injecting code into the target page. This bypasses the sandbox and is the only way on a normal Chrome userscript for a script to interact with the page's JS.
Injection advantages:
The only way for non-Tampermonkey userscripts to access objects or functions provided by the target page.
Almost always fully compatible between Chrome, Firefox, Opera, etc. (IE is, as always, something else.)
Often easier to debug the whole script; developer tools work normally.
Injection drawbacks:
The script, at least the injected parts, cannot use the enhanced privileges (especially cross-domain) provided by the GM_ functions -- especially GM_xmlhttpRequest().
Note that currently Chrome only supports GM_addStyle, GM_xmlhttpRequest, GM_log and GM_openInTab, fully, natively.
Tampermonkey supports GM_ functions almost fully, however.
Can cause side effects or conflicts with the page's JS.
Using external libraries introduces even more conflicts and timing issues. It's nowhere near as easy as #require.
#require, also runs the external JS from a local copy -- speeding execution and all but eliminating reliance on an external server.
The page can see, use, change, or block the script.
Requires JS to be enabled. Firefox Greasemonkey, especially, can run on a page which has JS blocked. This can be godsend on bloated, crappy, and/or intrusive pages.
I have a custom piece of Javascript which I would like to run on every web page from specific domains, or perhaps simply on every web page.
(If you are wondering: it is not malicious. It allows to display formulas by using MathJax.)
Is that possible? I tried including it in userContent.css, that of course did not work.
A simple Greasemonkey script I tried did not insert it. Is it because of the security precautions? (Which would be very logical).
Still, there should be a way to do it on the machine I physically control, by changing something in Mozilla chrome directory, shouldn't it?
Anyway, how can I do this for myself?
Welcome to stackoverflow!
Greasemonkey should do what you want. If it's not working either it's not being applied to the correct domains, or the code contains some sort of bug! (I personally use grease monkey on stack overflow to make some changes to the answer area).
Try placing some alerts() within your code to ensure that your grease monkey script is executing as intended.
If this is your first GreaseMonkey script, I suggest running through the links "For Script Authors" on The GreaseMonkey Wiki.
Specifically, we've got some external JavaScript tracking code on our sites that throws itself into an infinite loop each time an anchor is clicked on.
We don't maintain the tracking code, so we don't know exactly how it works. Since the code causes the browser to lock up almost immediately, I was wondering if there's anyway to log the results of Firebug's 'profile' functionality to an external file for review?
You should be able to narrow it down by setting breakpoints in the offending JavaScript. It might be messy (especially if they "minify" their JavaScript), but I think it's your best bet.
Perhaps by modifying firebug itself, or creating a firebug plugin, you could log the data to a preferences or sqllite. But firefox doesn't grant write access to plain old javascript.