Open Bug 1018251 Opened 11 years ago Updated 3 years ago

CSS on parent window html element overrides CSS on iframe html element.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
29 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: eurythrace, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.29.13 (KHTML, like Gecko) Version/6.0.4 Safari/536.29.13 Build ID: 20140419190604 Steps to reproduce: I am using the browser (Firefox and Chromium) as a basic EPUB Reader using some custom Javascript. All documents are XHTML5. The issue: Previous branches of Firefox worked fine, but after the upgrade to the current branch, a problem appeared in Firefox, but NOT Chromium. The specific problem is that suddenly in Firefox, the CSS styling on the parent window <html> element is overriding the CSS styling on the iframe <html> element. Example here: http://cdn.e-nexions.com/Weber-15GS2DVCFT/Changer_Of_Worlds-10H3CQH1R4/Reader.xhtml Actual results: Found this issue when doing a window.getComputedStyle( iframe.contentWindow.document.documentElement ) after the iframe loads. The styling I get in Firefox on the iframe <html> element is not what is declared in the iframe stylesheet, but rather what is declared in the parent window stylesheet; specifically for the font-family and font-size properties. This happens whether I load from local files or from online. Expected results: Chromium reports what I expect: the styling from the iframe stylesheet on the iframe <html> element; NOT the parent window <html> styling on the iframe <html> element.
OS: Mac OS X → Windows 7
Hardware: x86 → x86_64
Quick clarification: I don't know specifically which branch I upgraded from that had no problems, but it was around branch 24.
http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle says: Let doc be the Document associated with the Window object on which the method was invoked. and then: declarations All longhand properties that are supported CSS properties, in lexicographical order, with the value being the resolved value computed for obj using the style rules associated with doc. So if you do window.getComputedStyle you get the style using the stylesheets of "window", not of whatever document the node is in. If you want the latter, you should b edoing iframe.contentWindow.getComputedStyle. Previous versions of Firefox had the same exact behavior, as far as I can tell, so I'm not sure why you think the behavior changed.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Actually, hold on. I can't reproduce comment 0. This testcase: <!DOCTYPE html> <style> body { color: green; } </style> <iframe src="data:text/html,<style>body { color: red; }</style>"></iframe> <script> onload = function() { alert(getComputedStyle(document.querySelector("iframe").contentDocument.body).color); } </script> shows rgb(255,0,0) for me both in Fx24 and in Fx29 and in current nightly. That's not what the spec says to do (and if no one does what the spec says, then the spec might need to change), but certainly the behavior doesn't seem to have changed... Can you attach a testcase that does show a behavior change for you?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Ah, so I can get the color to be green in that testcase if I style the iframe with display:none. But that's also the case in Firefox 24 and much older versions... In general, if you want sane consistent behavior, you should be using the window the element is actually in to get the computed style.
@Boris, You nailed the problem with the CSS { display: none; } property. THANKS!!!!!!!!!!!!!!!!!!!!!!!! The containing <div> element wrapping the iframe had been set to { display: none; }, which the iframe inherited. I guess this occurred at about the same time I had upgraded Firefox. And apparently Firefox and Chromium have different philosophies about how to handle an element that has { display: none; }. So since the iframe had { display: none; } by inheritance, using either window.getComputedStyle( iframe.contentWindow.document.documentElement ) or iframe.contentWindow.getComputedStyle( iframe.contentWindow.document.documentElement ) was apparently causing Firefox to grab the PARENT window documentElement, i.e., window.getComputedStyle( document.documentElement ) instead. THIS is weird behaviour to me. The { display: none; } property should not "block" getting the computed style, just prevent it from displaying. And apparently this is the philosophy that Chromium chose, since I was able to get correct CSS property values of the iframe even with { display: none; } set on the iframe in Chromium - but obviously not in Firefox. The fact that window.getComputedStyle( iframe.contentWindow.document.documentElement ) AND iframe.contentWindow.getComputedStyle( iframe.contentWindow.document.documentElement ) produce the same results seems perfectly reasonable. Which COPY of the getComputedStyle function is invoked should be (and apparently IS) irrelevant - the key factor is the ELEMENT parameter that is passed into the function. THAT parameter alone should and apparently does determine what element is used inside the function; not where the function "resides". Anyway, thanks again! You saved me hours of hair pulling.
> was apparently causing Firefox to grab the PARENT window documentElement, i.e., No, it wasn't. What it was doing was causing Firefox to use the CSS rules of the window you called getComputedStyle on. Which is what the spec currently says should be done in _all_ cases, actually. > Which COPY of the getComputedStyle function is invoked should be (and apparently IS) > irrelevant Not according to the W3C spec.
@Boris, I went to the spec using the link you provided above and you are absolutely correct: “This means that even if obj IS IN A DIFFERENT DOCUMENT (e.g. one fetched via XMLHttpRequest) it will still use the style rules associated with the document that is associated with the global object on which getComputedStyle() was invoked to compute the CSS declaration block.” However, apparently this is NOT how the getComputedStyle() function is implemented in current browsers; and as I stated previously, the current implementations are the way it SHOULD be done. So as you suggested, this is a case where the SPEC needs to be revised to reflect how things have been/are done. Regardless, though, the behaviour of Firefox when an element has { display: none; } IS peculiar in that it does NOT actually compute the element’s style; unlike Chromium which does. This is one of the very few times I prefer a Chromium implementation over a Firefox one. Thanks again.
Yeah, none of the machinery for computing styles in Gecko exists at all in a display:none iframe. So the only options there right now are to throw or to compute using the styles of the window getComputedStyle was called on...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.