In Firefox 3 and later (and probably older versions), selecting content within an iframe always seems to use the grey selection background colour used for a document that doesn't currently have focus, even if the iframe does have focus. The only exception I have been able to find is when the content within the iframe is editable. This is not the case in other browsers. Here's an example illustrating this:
http://jsfiddle.net/97Vjz/
This unfortunately prevents styling the selection within an iframe using the ::-moz-selection CSS pseudo-element because it only applies to non-grey selections:
http://jsfiddle.net/YYXSY/1/
My question is: is it possible to prevent an iframe's selection being grey in Firefox without using contenteditable / designMode?
UPDATE
This only seems to happen on dynamically written iframes: using a separate file and the src attribute solves the problem. However, I do need it to work with dynamically written iframes.
I just tried to reproduce the problem with a "real" page as iframe content and then it works like you want: blue colored selection! (FF 5.0)
see: http://jsfiddle.net/97Vjz/8/
It seems only generated content has this problem, so you could make a page (php/asp(x)) that generates the content for you to circumvent the problem.
Another solution to use javascript generated content is to load it with src="javascript:'<html />'" (actually this is Tim's own solution from the comments below.)
A simple example script: http://jsfiddle.net/97Vjz/9/
iframe.src='javascript:\'<html><body>' + content + '</body></html>\'';
There is a property of the iframe exposed in Firebug's DOM inspector contentDocument->designMode which is set to false for you iFrames. Forcing it to true through the DOM inspector enables the blue highlight you're after.
Hypothesis: It seems that for dynamically written iFrames, either a XUL Iframe is rendered or the Gecko engine doesn't honor the styles.
Short of submitting a bug, the only workaround I can see is to wrap our contents in a textarea and style it to make it 'invisible': http://jsfiddle.net/mrchief/YYXSY/19/
Related
This question has me completely stumped. Since it's in a browser extension, I can't post my code.
The issue is apparently that mouse events inside the iframe (hovering over a link, over text, selecting...) are off by about 200px, this includes right clicks as shown in this screenshot:
The red dot is the actual mouseclick location. Again, since this is an extension (I'm actually doing the JS part in Tampermonkey, it's easier) I can't try it out in other browsers so it might just be chrome.
The iframe is to contain third-party dynamically loaded content so I can't use a div or other element. It's also reused and is dynamically inserted on load.
This also doesn't happen the first time content is inserted instead it takes a few "cycles" to appear.
Any ideas?
This was apparently a Chrome bug, albeit a strange one. I started having other issues so I reinstalled Chrome and upgraded to Windows 8 (I was planning to anyway), the bug seems to have gone away.
EDIT: It just came back, it turns out that the issue was that I was using -webkit-transform: scale() to show and hide the frame with a transition, removing this fixes the issue.
So, to all those with iframe mouse event issues in Chrome/WebKit: check all of your transforms and any CSS3 effects, try removing them one at a time.
I am currently working on a contenteditable iframe, which so far works perfectly under all browsers except for mobile Safari. I am using iOS 5.1.1. The issue is reproducible in any version of iOS that supports contentEditable up to the latest.
The issue is the following:
The content gets focused correctly when you tap on it, you can move the cursor and everything, however once you apply an action to it the following happens:
The focus is still in the iframe and you can see the cursor, however it does not respond to keydown as it previously did. Nothing happens, even if I move the cursor and still try to type anything inside.
Here is an example of what happens:
http://www.quirksmode.org/dom/execCommand/
If you focus the iframe anywhere inside the content and say you apply text-align right. The content is correctly aligned to the right, but if you try typing any additional characters, you can see that the ui locks, but no new characters appear inside where the cursor is. If you try to apply a different command it would still work though.
Does anyone have an idea of how I can workaround this?
you can simply use Iframes design mode instead of contenteditable attribute to make any HTML elements editable .
the javascript code to make elements in iframe editable is :
var iframe = document.getElementById ('the iframe Id ') ;
var doc = iframe.contentDocument || iframe.contentWindow.document;
doc.designMode = "on";
As I read no cross browser problems found in this method
for complete reference see here
Is upgrading your version of iOS an option? I just tested all the conditions you described using iOS 6.1 without a problem.
Since iOS5 was the first version of iOS Safari to support content editable, it's likely that the implementation contained bugs. It appears to have matured.
iOS 5.1.1 supports very minimal features of HTML5. It will work perfectly fine after you've updated it to iOS 7.
I'm using jquery in a page on domain "abc.com", and this page opens an iframe on domain "def.com", which also uses jquery (same version, and I tried different ones from 1.5.2 to 1.6.4). The frame is opened using the jquery library thickbox (not maintained anymore...).
My problem occurs in Firefox (any version from 3.X to 8.0), where I get the javascript error "c.defaultView.getComputedStyle(a, null) is null" the first time I load the iframe, and thus can't access any jquery initialization method:
$(function() {
/* Does not pass here in firefox */
});
On any other browser (chrome, ie, opera...) the code works, but in firefox I have to reload manually the iframe (right click -> this frame -> reload)... I have read some posts here on SO about similar issues, and each time the problem is a conflict between the two jquery libraries. In my case I can't remove one of the JS because the two pages are on different domains.
Thanks for your help.
This is related to the following Firefox bug:
Bug 548397 - window.getComputedStyle() returns null inside an iframe with display: none
Possible solutions include setting the iframe's width and height to 0 or visibility to hidden, rather than using display: none.
I'm currently trying to put together a rich text editor that includes widgets from a different location then the site the rich text editor is on. I'm doing this by providing an Iframe in the content area that is placed at the cursor.
Now the idea behind this instead of providing some kind of placeholder until they finish editing is so they can see what they are talking about while they type.
Now the iframe works perfectly fine in Chrome loads the content as expected, but in Firefox it seems to have disabled javascript in this case (notice none of the script files being downloaded), which is an issue as the widgets are extremely javascript heavy and don't function without it.
I have provided below a JSFiddle showcasing this issue, the site im loading in the iframe is just a javascript game but you will see it doesn't work in firefox but its okay in chrome!
http://jsfiddle.net/reefbarman/2uYja/2/
Any help is appreciated
Scripts won't be executed when designMode is activated (source). Internet explorer was the first browser to add this feature, and Mozilla implemented a similar function, heavily inspired by Microsoft.
Your code functions in Chrome, because Chrome has implemented designMode in a different way.
Well after some research and experimentation I was dealing with two different issues that looked like one.
Firstly I made a change to the rich text editor I was using to use contentEditable only as this seems to be the standard going forward and its a heavily html5 app im working on. So with designMode = 'Off'; the iframe would load in normal situations. But I had a strange issue where adding the iframe to soon after adding another element to the editable area caused the iframe not to load, so just delaying the add of the iframe by some time allowed that dynamically added iframe to load!
Problem solved!
I have a some trouble with iFrame.
Basically, I have drop down basic CSS menu and right underneath it I have iFrame with flash from external website.
Unfortunately whenever the menu drops down it goes underneath the iFrame.
Is there a way using jQuery , JavaScript or CSS to prevent the menu from disparaging behind the iframe?
Many Thank
Dom
You can try putting your Flash object into opaque window mode (wmode = 'opaque'), but because of the Iframe, I still expect some inconsistency.
http://www.communitymx.com/content/article.cfm?cid=e5141
You could also try coupling this with what's known as an "Iframe shim". It's definitely a hackish work-around, but one that Google themselves have used, sooo... take that as you will.
http://www.oratransplant.nl/2007/10/26/using-iframe-shim-to-partly-cover-a-java-applet/
iframe shimming or ie6 (and below) select z-index bug
http://www.google.com/search?q=iframe+shim
Good luck :) #Vili might still have the right idea with just hiding the Iframe when your menu opens. This is certainly the lowest level, and should probably happen for any browsers that don't support these other "fixes" (hacks).
(BTW, you can forget Z-Index helping on any platform or browser. Iframes and Flash both exist on macro-layers above the normal document flow. A DIV will never show in front of either without some finagling).
AFAICT it will always be broken on linux, since Flash doesn't play nicely with the z-index directive.
On other platforms you should be able to tweak z-index to your needs.
Maybe visibility: hidden; on the iframe, when the menu is opened?