Using a content script, I plan to insert a UI into the page in an <iframe>, but I have a few concerns.
Do people commonly use settings/extensions to block iframes on the page?
If my extension's iframe is blocked, is there a way for me to detect this?
Any other reasons to avoid the use of iframes in this scenario?
There are similar questions on the site, but they don't specifically ask what I want to know.
[The reason I want to use an iframe is this: My extension has to run independently of the website loaded (i.e. on any webpage). Its content script needs to show a UI for settings/help etc. Currently it does so by inserting a div into the page's DOM. However CSS from the webpage gets applied to the extension's UI, something which is harder to fix than one would think. Using an <iframe> seems to a way to avoid this issue.]
As you've discovered, trying to sandbox your CSS from interference, when injecting into the DOM is very difficult without declaratively setting every known style attribute. It's a well documented problem and some solutions can be found in the following posts:
How do I prevent CSS interference in an injected piece of HTML?
Is there a way to "sandbox" an HTML block away from its page's CSS without using iframes?
There's nothing fundamentally wrong with dropping your UI it into an <iframe>. I'm not aware of any settings or extension that would block this behaviour.
If your framed UI needs to interact with the DOM on the parent page or a content script you can do so with the use of Window.Parent. Also you may need to consider Same-Origin Policy if your pulling in the UI from another domain.
Answers in order:
People do not commonly use settings/extensions to block iFrames. Rather the opposite; the biggest complaint is how to get content out of iframes placed by ISP's and leach/wrapper sites, etc.
Yes, you can detect if your iFrame is blocked by having your iFrame's JS send an "I've started" message. If the message is not detected, assume the worst. :)
No reasons to avoid iFrames, other than they are a bit of a PITA to work with. If you just need to "show a UI for settings/help etc.", then it might be better to have your extension just open one of the popup window types available to extensions. You control the HTML/CSS/JS of those completely without worry of interference by the page.
Related
I am developing a chrome extension that is meant to work on all web pages. As part of its functionality, it needs to show a UI on any given page.
Currently, to do this, I append a div (containing the UI HTML) to the page from the content script. The issue with this is that the styles of the containing page get applied to the extension's UI, causing it to look different on different webpages.
Two approaches to fixing this issue:
Apply specific styles (marked as !important) for the extension's UI elements. This is really hard because depending on the page, any attribute of any element can have a different value.
Add this UI to an iframe, and insert that to the page. This of course, fixes the CSS issues with approach 1. But I haven't worked much with iframes in the context of extensions before and I'm wondering if there are any concerns that I should be aware of.
Some of the potential issues that come to mind:
1. There can be complexities in the content script interacting with the iframe js.
2. Some users might have iframes disabled at the browser level for specific or all sites?
Generally, the use of iframes is frowned upon, for reasons of security and performance (among others). I am wondering if in this scenario, using an iframe is the most sensible option?
Also, I intend to port the extension to Firefox later. This is probably not relevant, but just putting it out there in case it helps tilt the decision.
I have one solution with web forms approach (soln1) and the other one in MVC 2.0 (soln2). On a page page1.aspx in soln1, I want to render soln2. I used iFrame and in src atribute, I provided starting URL of soln2. Is there any other approach to this? Basically I dont want to use iFrame because of some styling issues.
Thanks
There are three ways (that I can think of) to load one webpage inside another:
IFrame
jquery.load
Frames
Unfortunately all of these options have their problems.
IFrame's can have styling issues as you know.
JQuery's load has compatibility problems with some browsers and an issue with event bubbling.
Frames demands a static layout to your site and probably has the same styling issue for you.
Considering those problems, an IFrame is probably the best choice, it's also specifically intended for the kind of behaviour you're trying to achieve.
Why don't you post about your styling problems, as that might be the easier thing to solve.
Update:
To fix the scroll bars, you can add this attribute to your iframe
scrolling="no"
For an example see here:
http://jsfiddle.net/FZ4eZ/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For me iframes are pure evil (well, maybe not so pure). They seems to make a lot of troubles. Yes, your whole site will load once and then you can just load single pages. But people invented AJAX for this purpose.
One of the biggest issues I found with iframe was that I couldn't paste a link to one of the subpages, because the URL never changed (yes, I know there is a workaround for this). Second thing, web search engines may have problems indexing such pages.
Sometimes the accessibility of this sites are worse and some browser can even display them improperly.
There are better ways to design layouts without iframes. Everyday I can see some one asking at SO questions, like "How to access iframe with jQuery?".
So what are the benefits of iframes? What reason can it be to still use them? I just would like to know why.
I can think of 2 reasons (at the moment) why people would still use iframes instead of AJAX:
1) Iframes circumvent the cross domain origin policy (images, scripts, and styles do not). This can be useful for pulling in sites / content from other domain names relatively safely. Basically, this allows the advantage of being able to visually show data from other domains without letting them stomp all over your page with unlimited access (like something like JSONP would be able to do).
2) You can load multiple types of resources from within an iframe, not just certain mime-types (you're relatively limited to application/javascript, application/x-javascript, text/css, text/xml, image/png, image/jpeg, image/gif with scripts, XHR, images, and sources). For instance, if I want to show you a PDF, I can open an iframe and let the Adobe Reader plugin show you that file. Additionally, in the same domain, if I want to pipeline a script, style, and image all together (inline on the page, image would have to be data URI), I can accomplish this with an iframe (and if it's in the same domain, port, and protocol I can access it with JavaScript as well).
Did you know that Gmail is a set of iframes? The visible part is just clever positioning. Additionally, many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in).
IFRAMEs are used to embed and isolate third-party content into a website.
Most of web advertising solutions are based on iframes - because they give security (cross-domain policy) and isolated rectangle on screen which can be fully managed by third party content and scripting (a common use case is advertisments).
Another modern use of IFRAMES is a management of history (common back button workaround) of AJAX applications.
FRAMEs are poor version of IFRAMES. Their use is declining.
If a user has javascript disabled, iframes will work when ajax doesn't. This is not out of the question, considering that people use things like NoScript.
I use them on ajax websites, when I need to upload files without reloading the page.
I still see iframes being used in large corporations where they provide a single sign on which injects header information about the authenticated user which is then passed, via an iframe, towards the actual application(s). Since the "portal" surrounding the iframe handles all the specific authentication details those applications behind it don't need to have each an implementation for it, making things easier to make for the development team and having a single place to monitor and adjust authentication details of users.
There are plenty of technical reasons to use them (especially the security issue mentioned by Dan Beam).
What you shouldn't do is use iframes “like frames”, doing navigation to new pages by updating the iframe only. As you say, this prevents the navigation from being bookmarkable/linkable, responding to the normal navigation buttons, and providing useful link affordances like open-in-new-tab.
But that's not peculiar to iframes. You can see more and more pages where the navigation is done by fetching new content with XMLHttpRequest and writing it to the main content div's innerHTML. Often this is done with jQuery load() and clever-clever slidey animations. This breaks navigation just as badly as iframe-used-as-frame, or indeed old-school framesets. It's a shame so many web authors are using this tactic believing it to be a super-modern web design methodology, when really it's just a new skin on yesterday's despised framesets.
You can work around it in both cases, but it means you have to store a viewstate in the # fragment identifier part and support proper hash-navigation, which isn't trivial. Even then you've still got problems with non-JS agents like search engines; you end up having to have a parallel ?-based and #-based navigation to support both. It's a pain and most don't bother.
Framesets are outdated as of HTML 5, and sometimes you need to have a frame with another site within a site.
Also AJAX can only do so much. Try uploading a file to a site on another domain through https without an iframe. AJAX won't help you there.
In addition to others reasons, I have one specific usage of iframe in my application. Unfortunately, the target browser in my case is Internet Explorer 6. I need to have a footer and a header that are fixed in my web pages. The main part of this page is scrollable.
However, there is a bug in IE6 where I cannot display a div element on top of select elements using the z-index CSS property. Thus, I need to create an iframe that will be used as a hack to avoid this problem.
Of course, this is a really specific usage of iframe and only concern IE6...
Javascript WYSIWYG Editors use iframes, because that is easiest and best way to make it. For example TinyMCE uses it:
http://tinymce.moxiecode.com/
I was building a social network and i see iframes being useful for widgets to put on other peoples website to show like a mini profile or integrate with the content on a remote server. Seems like the most simple way to build this. I know some widgets use JavaScript. Also with the iframe method the session is the same as visiting the site like normal, so great for like buttons.
Many Formatted Text Editors (e.g. TinyMCE, HTMLArea) are implemented as iframe.
iFrames are okay for some cases, as X-domain-requests, or posting data to a source via parameters. But when I want to access data across domains, I prefer using CSS-files - they can accept params, set cookies, add content to the page (:before & :after) and give a visual feedback.
Is there any problem with using jquery layout plugin (there are several) to layout a page as opposed to using CSS and fixing browser compatibility issues myself?
Another problem is that the page has to fully load and download the javascript, then get rendered. This will slow down the page significantly.
The most obvious problem is that any visitor to the page using a browser with JavaScript turned off will not get the layout. If you're willing to turn away from those people, that may not be a blocking factor for you.
There can also be performance issues, delays on resizing the browser window, that sort of thing.
I'm not saying don't do it; if it's appropriate for your target audience. But look to see if you can avoid it or at least gracefully degrade if JavaScript isn't enabled. (Turn off JavaScript and come here to SO, for instance; still very usable in a read-only way.)
If doing this, continue to be sure to mark up your content in the main page (rather than only adding it dynamically) and use the most semantic markup you can, to improve your search-ability.
When your layout doesn't behave for whatever reason (and that will happen), will you be able to understand the code behind the JQuery plugin to fix it?
Invest in yourself and learn CSS properly, it's not hard, it doesn't take long and it will equip you for the future, don't just rely on plugins. Now I'm not saying never use a plug-in, but this to me seems inappropriate use
are there any reasons not to use iframes at all? I currently use it to load a page from a different server (a sign up page - part of a distributed application) to provide a seamless experience. Is using iframes considered bad practice or is its use OK?
The iframe is a great tool. It enjoys near-universal browser support, it's easy to implement and has a number of useful functions. As with any other HTML element, it can be abused, but wielded intelligently it can play a part in a solid UI.
Some developers might argue to use AJAX instead, and in some situations that may be the more appropriate approach, but AJAX is not a panacea and iframes can be a far simpler implementation which has the same end-result for your users. Do whatever is simplest first, and only change that when you can verify how and why that is not working.
Keep using iframes. Here's an example of why:
The whole Verified By Visa thing really annoys me. I'm happily shopping at some site that I trust, when I'm redirected to some site I've never heard of (not visa.com) and I have to fill in some other form and hope that I get redirected correctly back to the shopping site.
Then recently I was shopping at the John Lewis website, and they brought up the Verified By Visa page in an iframe - wonderful! I'm still looking at the John Lewis site, and all that's happening is I'm being asked for my Verified By Visa password - no problem.
Although as a web developer I know that there's no technical difference between that and a plain old redirect-there-redirect-back, the user experience is so much better!
Pros:
Helps with slow third-party content like badges and ads
Security sandbox
Download scripts in parallel
Cons:
Costly even if blank
Blocks page onload
Non-semantic
Source: Best Practices for Speeding Up Your Web Site
iframes have access to certain properties of the parent document, e.g. redirect the parent frame to a new location using parent.location.href or parent.window.location (IE allows to restrict that).
This is great for phishing attacks when embedding content from other servers (even if you trust that server it might be compromised).
iframes can also be used for a variety of other attacks: IFrames security summary.
With HTML 5 you'll be able to use the cross document messaging API to send messages from window to window, but for now the iFrame is the most viable alternative to any sort of AJAX that requires styling and scripting to load with the data.
If you're looking to just use text data in the iFrame, use AJAX instead. If you want external CSS or JavaScript to work in a protected environment, want styling to start from scratch, or need to access cross domain documents, use the iFrame.
Cons are that the accessibility of iFrames generally sucks, although you can prevent this by making sure that you proceed the iFrame with a notice of external content for screenreaders. Also check the HTML specifications for other ways to make the iFrame more accessible. Other than that and the obvious limitations scripting wise, the iFrame is a great tool is used responsibly and sparsely.
One last note, piling a page full of iFrames is definitely not a good idea, as remember that for each loaded iFrame, a DOM is created, HTML requests are made and document wrappers are instantiated, eating memory and bandwidth in the process. Keep iFrame's to a minimum on the page, and you'll avoid misuing a powerful tool in the HTML aresenal.
IFrames are a great way to "include" external content in a web page. However, there are a couple of (small) drawbacks:
Security sandboxing will cause problems with JavaScript if the IFrame does not originate from the same domain.
You cannot get CSS to co-operate between the IFrame and the parent page, unless you control the stylesheets themselves.
From an indexing point of view, the IFrame's content doesn't exist.
Screen readers might not like the IFrame, for the same reason. Or they won't be able to properly indicate the relative meaning of an IFrame's contents.
Apart from that, they're great! The points I mentioned might even be considered advantages, if you think about it (except the screen reader one): in principle, an IFrame can't influence its parent page's layout, and it isn't influenced itself by its parent either.
As a general rule, iframes are a bad experience for SEO reasons. So, you ask is there any reason not to use iframes? Yes, if you use iframes you are losing some organic placement in the search engines.
Of course, there are usability concerns which can (and should) trump SEO value of pages.