So I am calling the wistia script with a script tag in my head like this:
<script charSet='ISO-8859-1' src='//fast.wistia.com/assets/external/E-v1.js' async defer data-script='wistia' />
However, when I check out the network tab on Chrome, I notice that the E-v1.js script from Wistia is being loaded twice, which is rather significant as it is a 273kb script.
The first load of the script is from https://fast.wistia.com/assets/external/E-v1.js, the location to which I have called it.
However, the second load of the script comes from an iframe, despite me not having put any iframes on the page. This iframe calls the script even on webpages which do not contain any wistia videos. The referrer is: https://fast.wistia.com/embed/iframe_shim?domain=com.
What's going on here? I assume this is some trying-to-be-helpful behaviour from wistia to lazy load their script via an iframe, but it's already loaded...
So I contacted Wistia and got an answer. Their development practices are not exactly intuitive.
Here's what the guy said:
The iframe_shim is a way of tracking the visitor_key for stats tracking, and storing that information on the fast.wistia domain rather than your domain. For a more lightweight method of doing that, you can set window.wistiaIframeShim = false in script tags on your page, and that will stop E-v1.js from loading again. Visitors will then be tracked via a cookie and localstorage directly on your domain instead of the fast.wistia.com domain. As far as I know this shouldn't be problematic, and we'll eventually be changing how that works to make it more efficient, it just hasn't been prioritized yet.
So they seem to load it twice from two different origins just to store a tiny amount of information on their own domain rather than on the client. Seems ridicuous to me, but I can confirm as of right now that all you have to do is change that window variable.
THE FIX: window.wistiaIframeShim = false
Related
I need to display several exactly identical iframes. This iframes have javascript that reads from the # of the URI and then perform different request but the source code of the iframe and the fetched ressources are exactly identical.
1 iframes, including javascript, stylesheets and image is approximately 10 mb. Now imagine that I need to display up to 10 iframes on the same page. That's a page of up to 100 mb !
The problem is that neither the iframes themselves or the content they are loading are being directly cached. (not on Google Chrome at least, which is my principal target).
Here is an example of what my code looks like :
<iframe src="myiframe#1">
<iframe src="myiframe#2">
<iframe src="myiframe#3">
...
Each iframe is loading the same huge javascript file and the same request is being fired for as many iframe as I have :
We can clearly see that when the first js file finished to download, the other one (even the connections that weren't initiated yet!) are not using the cache but rather downloading it all over again. And it goes the same with every file.
What have I tried ?
Sending caching headers. Currently replying with cache-control: public, max-age=31536000 but I've even tried the more restrictive such as Cache-Control: immutable
First loading only one iframe and then, onload, loading all the other iframes. It still doesn't use the cache even though the first iframe has fully loaded and should have saved the ressources in the cache !
Cloning iframes but, and as described by the RFC, it fully reloads the iframe hence firing the requests again.
On the second load of my page however, the browser does fetch the ressources in the cache but that's not enough for me.
The desperate (and only ?) solution I can think of :
Load all the ressources and the iframe source code, then dynamically create an iframe element and inject everything in it. It would be possible but very hard. Also, probably not very performance friendly.
Note : The iframe are not on my domain but I'm doing some reverse proxy thing so I have controls over the iframes. It means I can possibly modify the source code of the iframe but since everything is minified and all it's not an easy thing to do.
Could you try to load the iframes without the # ? If the cache problem relies on the anchor, you could set it after the iframe is loaded:
<iframe src="myiframe" onload="this.src+='#1'"></iframe>
<iframe src="myiframe" onload="this.src+='#2'"></iframe>
<iframe src="myiframe" onload="this.src+='#3'"></iframe>
This question already has answers here:
Fire Greasemonkey script on AJAX request
(2 answers)
Closed 7 years ago.
I have the following situation:
A website gets data from another html-file("news.html") which gets called every 10s or so
I want to manipulate the data from the news.html
I thought I could set up a greasemonkey script which manipulates the news.html and thus also the main website.
However this assumption was wrong: When I open the news.html in my browser, the news are manipulated (in terms of data - just to clarify this), but when I visit the main website the news don't get manipulated.
I think that greasemonkey does not work when the website is not opened "directly" in the browser, but with ajax/jQuery/....
Is there any known workaround for this?
Thanks in advance!
You can't change files that are on a server with greasemonkey unless the API for some reason leaves that exposed. Whatever you are changing is just local to you.
For simple pages, it's safest to wrap your greasemonkey scripts in at least an unload handler: According to the "Authoring" page at http://greasemonkey.mozdev.org/authoring.html,
User scripts are executed after the DOM is fully loaded, but before
onload occurs. This means that your scripts can begin immediately and
don't need to wait for onload. However, replacing large parts of the
DOM (e.g. using innerHTML or outerHTML) at this early stage of
rendering is known to cause Firefox some trouble. In this case, you'll
have more success if you call your code in response to the load event
instead:
window.addEventListener("load", function(e) {
document.innerHTML = "Hello, world!";
}, false);
However, if the "main site" is constructing itself via a secondary ajax call to news.html, that won't be enough, because the data you want to manipulate won't be in the DOM yet when your script runs on the main site. You'll need to delay your script's execution until after the main site has finished doing its thing, so that when you try to do your thing there'll be the thing there for you to do your thing to. So to speak.
Have your script observe the DOM and wait to run until after news.html has been injected into the main site, or be lazy and start it after a sufficiently-long setTimeout.
(A clarification based on discussion in comments: Greasemonkey will only act on the site that was actually loaded in the browser; it will not act directly on every XHR request that site makes, even if that url was #included in the script. So if site "foo.com" ajax-injects content from "bar.com/news.html", and the browser loaded "foo.com", greasemonkey will not directly modify the "bar.com/news.html" request foo.com made; it can only work with the DOM that foo.com constructs based on what it got from news.html.)
I am working on a Greasemonkey script to turn some text into links on a a Rally page. The script works fine only when I reload the page. If I navigate to the page in any manner (links, browser forward/back) the script does not run, despite the fact that the Greasemonkey menu shows my script at the bottom, with a checkmark.
Here is an example URL:
https://rally1.rallydev.com/#/4745909548/detail/userstory/6138899084/changesets
My matching rule:
/^https://.*\.rallydev\.com/.*/changesets$/
I don't know if the hash is causing a problem, but everything is fine when I reload.
Not sure where to go from here. Any help is appreciated.
It's impossible to be sure what's going on, because the target page(s) are behind a pay-wall and their alleged "Free Trial" mechanism blows chunks.
Here are some possible causes of the current behavior:
The initial request is insecure (http) but redirects to a secure page (https).
The first page load does a some other kind of redirect to the actual page.
The target content is in an <iframe> that does not load right away.
The target content is AJAXed-in.
Something exotic that we would need to see the actual page to figure out.
The initial URL does not really end in changesets.
Also, get into the habit of escaping the /s in the middle of regular expressions. It's not always needed, but it will eventually bite you in the [censored] if you don't.
So the script should use:
// #include /^https:\/\/.*\.rallydev\.com\/.*\/changesets$/
to start, but see below.
Steps to a solution:
Change your #include to account for http and the Possibility of trailing space or trailing slash in the URL. Use:
// #include /^https?:\/\/.*\.rallydev\.com\/.*\/changesets(?:\s|\/)*$/
Examine the page with Firebug. Is the content AJAXed-in? Is it in an <iframe>? If so, what is the iframe URL, if any?
To also detect AJAX and/or redirects, use Firebug's Net panel and/or Wireshark.
If possible, provide us with login credentials so that we may see a problematic page.
Snapshot a problematic page (Save it via Firefox) and link to that HTML and JS in Pastebin.com.
Consider using code like:
if (window.top != window.self) {
//--- Don't run on/in frames or iframes.
return;
}
To have the script run only in (or not in) iframes, as applicable.
If the problem is caused by AJAX delays (or loading of new content), get around that by using the waitForKeyElements() utility as shown in "Fire Greasemonkey script on AJAX request".
I have iframes with OpenX ads I server from another server/domain.
When something happens to this ad server the main server doesn't load whole contents because the domain that openx loads in iframe is not responding. I always thought that iframe works independently from the main site but it doesn't if the domain doesn't answer at all...
Anyway can main site detect somehow that a url in iframe is not responding and skips loading iframe and show the rest of the site?
How about loading the iFrame once the website is loaded? It's pretty easy to do this using jQuery (or even plain javascript using the window.load event).
So rather than wanting to 'detect' whether the iFrame has loaded, you can load it AFTER the rest of the website has completed loading. (sorry for excessive use of word 'load')
In jQuery, you can simply attach the url to the iFrame on the document.ready event.
A blank iFrame
<iframe id="iframe-ad" width="200"></iframe>
Simple jQuery to load the URL on document.ready
<script type="text/javascript">
$(document).ready(function() {
$("#iframe-ad").attr("src", "http://www.google.com");
});
</script>
Unfortunately there is no easy way to do this unless they are served from the same domain. I know there is a way to get let the javascript inside the iframe perform some actions on the parent document it is contained in, but I am not really sure how...
It is not possible, because of Same origin policy, there are some "gaps" in some browsers. But this is not going to recommend!
Might not make for the best experience, but you can make a local redirect file. something like:
<iframe src="http://www.mydomain.com/redir?url=http://www.theirdomain.com/ads"/>
then the redir page just returns
<script>
location.href = "${url}";
</script>
That way as long as your server is responding, everything else will continue as normal while the iframe redirects?
How about if I don't have iframe just javascript originating from different domain? If the domain is not responding javascript holds the page back not to load. Is there a way to prevent that?
I have a 'toolbar' that displays some code on the top of the window, and then I load an iframe with an external site. I realize that I can't get the active link the user is on because it would be a violation of same origin policy.
Is there any way (using greasemonkey maybe?) that I could get the active url of the external iframe?
I need to do this for demo purposes, not for anything practical. (I realize the real solution would be to process the entire page through my own server)
Thanks!
I'll post a workaround that I wrote:
If you install greasemonkey, write a script does (roughly) something like this:
current_link = document.location.href;
if(current_link !== 'http://my_local_site')
{
GM_setVal("link", current_link); }
Have greasemonkey run this script on your iframe's URL and on your local site and on your iframe's site.
GM will save to its internal memory the link. If you don't trigger the IF statement, you're probably reading the script from your local site, ergo you need to:
unsafeWindow.urlVal = GM_getVal("link");
All you need to do now is to get both the local frame and the iframe to run the script every time a page is navigated on the iframe.
You can get this done on your local frame by a) timing it b) using some type of event trigger.
Best of luck!