I am getting crazy with this problem, and hope there is a solution or workaround.
I have a canvas inside an iframe, in a different domain (for security reasons). This canvas shows a Processing.js animation/drawing. I need to allow the canvas to load image files that are located on the same domain.
index.html with the iframe is in domain.com
index.html with the canvas is in sub.domain.com
Now I know for sure that:
The canvas can load/visualize a remote image but cannot access a remote image data (pixels).
The canvas can fully access an image file on the same domain, unless it is played in an iframe (!?).
Setting Access-Control-Allow-Origin header simply allows to access files on other domains.
The canvas does not support/consider Access-Control-Allow-Origin headers at all.
Is there a way to bypass all these security limits and simply get a canvas played in an iframe to load an image file?
I found the solution to my problem (and saw that nobody answered). Actually I forgot something... I was using the sandbox attribute in the iframe tag and that was the problem. Once removed, images started to be accessible within the canvas, in Firefox and Chrome at least (did not test IE yet). Anyway, the sandbox attribute still has a very bad support and is probably totally useless in a cross-domain scenario.
So. I can confirm that with a normal iframe (without any sandbox parameter) there are no problems when loading images into a canvas, within an iframe, if and only if the image is in the same domain of the canvas page.
Related
I am working on an e-commerce site and the product images are NOT visible on the live site but they are visible on my local development version even though I am using an exact copy of the code and database. What is even weirder is that when I open the developer console and look at
- the source code for the images is there and also the preview of the image is correct which tells me that the image is loaded correctly it must be something else.
Also, the only difference between the development site and the live site is that the live site runs on SSL, so I guess the problem could be related to that but I have no idea what it could be - the image urls start with https.
Here is an example page where the images are not visible.
Also, to mention the website is build with WordPress and WooComerce, custom theme.
EDIT: For some reason the images are no longer visible on the local version as well.
One of the parent elements / ancestors of the image (in single product view) is a DIV which has the class attribute woocommerce-product-gallery woocommerce-product-gallery--with-images woocommerce-product-gallery--columns-4 images and a style attribute which contains opacity: 0, i.e. completely transparent, therefore it remains invisible
So you have to find where that opacity setting is added and deactivate it. (Or if it's static, simply remove it from the HTML tag)
I have a div tag on my site that uses a background image. When we make a tiny text change in that image and ftp it back to the server, it continues to serve it as 304 not modified and uses the cached version. Only until we force a browser refresh does it fetch the new image.
I've read where you can set Cache-Control to no-cache in the HTTP Response Headers (I'm using IIS 7.5), but that still does nothing, still uses the cached image and sends back a 304. My workaround was to rename the image and also change the div's css and that does work, but I'm looking for a better way. Ideally, we want this single image to be dynamic so we can change it often, but we don't want our customers to have to know to refresh their browsers.
Is there a solution?
Changing url is most common workaround.
In my case, when I've experienced such issue, I've moved image in separate controller(or it may be page, or even hadler), and was adding little url param, which was generated by datetime class, e.g.:
http:\\mysite.com\myimage\dynamic.jpg?bla=20121119184001
I want to place a div above an iframe with flash content (for example like a youtube video).
I do not have access to the content in the iframe, so I can't modify something in there.
I've tried a lot of things (z-index... everything).
But nothing works. I am only asking because I really can't find a solution :(
The problem is that the iframe contains the flash content.
I can't really help with a tested solution I'm afraid, as I don't have any flash files to test creating an answer with, but I can tell you why this is happening.
Flash is a browser plugin, which means flash movies are never really part of the HTML document. Instead what happens is the area of the page is reserved for the plugin to run in, which is then invoked and runs 'on top' of the page. Therefore setting z-index on other elements will never actually solve the problem, no matter what combination you try.
However, there is a 'magic' parameter / attribute you can set on the elements themselves that the plugin recognises, called "wmode". If you set this parameter / attribute to 'transparent', the Flash plugin allows some HTML elements to show through, giving the illusion that they are on top of the Flash movie.
If you're able to contact the owner of the iframe to set the wmode parameter to transparent, I'd suggest doing that. If this is a youtube or vimeo embed, see if there's any documentation or options on adding the parameter yourself.
Failing that there's not a lot you can do, as even JavaScript won't be your friend here (you can't modify the contents of a frame with JS for security reasons)
EDIT:
Just remembered, if there's a way of you using HTML5 video instead of Flash, that would help. HTML5 videos are rendered as part of the Document Object Model, and therefore are controllable through the z-index property.
Neal
Is there a way to "cache" background image.
For example..
Background image is 3x3px and it's set like this:
body {
background: #000 url(bg.png);
}
When refresh happens, background image "flickers" for second.
Is there a cross-browser solution? (for Apache/PHP server if that is relevant)
If you go to seo.hr and browse navigation,... you can see what I'm trying to do.
http://www.seo.hr/
http://www.seo.hr/usluge/izrada-stranica
http://www.seo.hr/usluge/optimizacija-za-trazilice
I think you need to determine first if the issue actually is a caching issue or if it's caused by the size of your image. You could use a program like Wireshark or Fiddler to do this, but to be honest it's overkill for your need and you probably already have a browser with developer tools.
Here's how you determine where an image is coming from in Chrome (the other browsers are similar).
Open your developer tools and go to the "Network" tab.
Find "bg.png" in the list of network requests and click on it's name. Below is an example of having selected a stack overflow image from this page.
Notice that it says status 200 (from cache). The browser didn't need to go out to the server and rerequire that resource. It used the cache. If that "from cache" text wasn't there it wasn't reusing cached resources.
There is also the potential that you'll get a status code of 304. That means that the server said the image wasn't modified since the last request that you made. You do make the server trip in that case.
Ok, so my image wasn't in cache... now what?
There are a few reasons that this could occur.
You're request headers aren't set to tell the browser to cache the image (also found in that same "Headers" tab that you would have seen that Status Code if the browser actually went to the server for the image). You'll want to set cache-control and expires to something that makes sense for you. Cache headers can get a bit complicated you may want to browse through this caching tutorial document.
Is it SSL? If so not all browsers cache this but most modern browsers do. Set cache-control: public on these images (and also expires).
The real question here is how do you fix this? Unfortunately, that's entirely dependent on the server and/or the framework that you are using. As the OP is using Apache, they can find great documentation on the Apache module mod_expires to figure out how to tweak caching for their site.
Yes!
You should decide whats more suitable for you, but at this time we have some methods, like:
Pure HTML/CSS
Javascript Only
Mixed HTML/CSS/Javascript
Using base64 to encode the image somewhere on the source code
At this point I recommend a mixed solution, using javascript. This will make it work on many browsers as possible.
There is a good tutorial at:
http://perishablepress.com/press/2009/12/28/3-ways-preload-images-css-javascript-ajax/
Having several images in one can take you a step beyond that, so check this sprites article:
http://www.alistapart.com/articles/sprites/
You can try to encode your image in base64 and put it directly into CSS source code. I found a question about pros and cons over here.
Make your tiled image much much larger, when the browser engine renders the page it has to multiply each tile to cover the entire width and length of your object, which results in bad performance with small tiles on large objects.
Small tiles -> more repetitions -> slower performance
I installed a template on blogger, but it's not showing the background image.
in the main blog here you can see that there is no background image (the orange one)
now visiting this one which is the blog I do test the template on first, shows normally the background.
the weird result is that if you go back to the first website now and refresh it, the background will be shown??
how can that happen between 2 different domains? they both reference the same image but why it loads on website1 only after loading website2?
this is the CSS associated
#body_top {
background:transparent url(http://4.bp.blogspot.com/_66wIGDjagHk/Sh1HpWevpII/AAAAAAAAAeo/L2BR0NJ6kB4/s1600/bgr_body_top.png) no-repeat scroll 0 0;
width:100%;
}
Maybe some resource takes extremely long to load? Then visiting the second site causes it to be loaded to a cache - which acts as a reordering.
I'd suggest inspecting this behaviour with firebug - Network tab.
EDIT: weird, the firebug shows that server responds with 404
Appears like HTTP and not CSS bug. The server responds with 404 when connection is already open (keep-alive issue?) and returns the image otherwise.
OK, it's the referer. It should be blogspot.com subdomain.
Maybe blogspot has some sort of file size limit which disallows hot-linking of large files from other sites. The background_top seems somewhat larger than other files.
Here, look at blogspot.com referrer restrictions: http://www.google.com/support/blogger/bin/answer.py?answer=57527