Freecodecamp: firefox: style tags in hidden iframes do not apply css
Issue Description
This is for the feature/curriculum-expansion branch only when run locally, and NOT the staging branch.
For several challenges (challengeType: 0, using the code editor with the mobile-phone output layout), the jQuery method .css() doesn't seem to be accessing the styles applied in a style tag in the given code. This is affecting any assert tests that use a pattern of assert($('selector').css('propertyToCheck') == 'valueToCompare', 'message: ...');.Here's an example:
<style>
h2 {
position: relative;
top: 15px;
}
</style>
<body>
<h1>On Being Well-Positioned</h1>
<h2 class="testCode">Move me!</h2>
<p>I still think the h2 is where it normally sits.</p>
</body>
<script>
console.log($('h2').attr('class')); // Works great, returns testCode
console.log($('h2').css('position')); // returns undefined
console.log($('h2').css('top')); // returns undefined
</script>
Related assert tests that aren't passing:
assert($('h2').css('position') == 'relative', 'message: Add a CSS rule to specify that the <code>h2</code> has a <code>position</code> set to <code>relative</code>.');
assert($('h2').css('top') == '15px', 'message: Use a CSS offset to relatively position the <code>h2</code> 15px away from the <code>top</code> of where it normally sits.');
Browser Information
- Browser Name, Version: Firefox 48.0.1
- Operating System: Mac OS X, El Capitan v10.11.3
- Mobile, Desktop, or Tablet:
HKuz
All 21 comments
@QuincyLarson the .css() method issue as discussed. And copying in @BerkeleyTrue as requested.
HKuz
on 15 Sep 2016
@HKuz I believe this issue may be the cause of the bugs in #10595, especially since you are on Firefox. Can you test if they are returning undefined in Chrome?
So far, I've tried rewriting a test or two in JS instead of jQuery, but it seems that assert is not working properly with document.getElement (either in Chrome or Firefox). I've yet to write a successful test that works with assert in both Chrome and Firefox but maybe assert doesn't work with the DOM.
dhcodes
on 16 Sep 2016
Ah, brilliant detective work, @dhcodes - I checked in Chrome a challenge that has both .css() and regex versions in separate assert tests (where the .css() ones failed in FireFox) and they were all good. The console also logs the info correctly. Makes sense the browser would factor in here. If there's already an issue covering browser differences, should we close this one and maybe note (or brace ourselves) over there that potentially most of the new Applied Visual Design section tests are going to cause problems? I guess one plus here is that I have tests written using (less-ideal) regex for ~2/3 of this section that I can hold onto offline just in case.
HKuz
on 16 Sep 2016
@HKuz I'm not sure what the true solution is. We could rewrite all the asserts as code.match with Regex, but that sort of depends on if we can find a better fix universally before the React update rolls out again. I've done some limited searching and haven't determined the cause yet.
dhcodes
on 16 Sep 2016
@dhcodes I wish I could be more helpful on the big picture issues, but I don't know either. I guess a blind squirrel finds a nut on occasion, so if I stumble onto any leads, I'll keep you posted. Regardless, thanks for pointing me in the right direction re the browser. I noticed a slight UX difference between Chrome and Firefox, too, Chrome automatically loads the code editor and the mobile phone output when I submit/go to next challenge, whereas Firefox will continue to display the prior challenges output until I manually run tests/ hit ctrl-enter / reload page.
HKuz
on 16 Sep 2016
@HKuz @dhcodes Are the .css() tests not working on freecodecamp.com right now in firefox? If they are working on production, we should be able to find a way to get them working on our staging branch (which the curriculum expansion branch will eventually be merged into).
So if you can't get these working, I recommend moving on to QA'ing other challenges and writing other tests. But assume that it will indeed work.
We can see whether @BerkeleyTrue can fix this in the meantime.
QuincyLarson
on 17 Sep 2016
@QuincyLarson and @dhcodes I just ran a couple challenges through my FCC account using Firefox and they worked as expected (Change the Color of Text / Use CSS Selectors to Style Elements / Use Clockwise Notation to Specify the Padding of an Element). They use a .css() test or were in the issues list #10595. For the work I'm doing with QA'ing, I do need to use the code.match(regex) style tests in some places, but I'll move forward using the .css() ones as well. They are working in Chrome, so I'm able to test them locally in one environment, at least.
HKuz
on 17 Sep 2016
@HKuz OK - great! I'm glad these tests are still working in FireFox in production and that you're able to move forward using Chrome locally. Thanks for the update.
QuincyLarson
on 18 Sep 2016
@QuincyLarson This issue is coming up a bunch now that the beta is out (#12677 / #12668 / #12684 / #12679 / #12697 / #12644)
systimotic
on 21 Jan 2017
I've successfully used native alternatives such as document.querySelector('#someElement').style.insertPropertyHere instead of $('#someElement').css('insertPropertyHere'). It seems to be more reliable accross browsers, and seems to be more performant (~40 - 50 ms) on my computer.
As JS is getting more and more standardized, I feel like we should take advantage of what the environment gives us.
A simple solution could be to replace the problematic $().css() tests that we stumble upon with native alternatives. This way, we could leave tests that already work as they are and only update things as we go. If we make this decision though, we should probably add it as a requirement/best practice for PR-reviews - and to the Challenge Style Guide.
Greenheart
on 25 Feb 2017
@Greenheart this won't fix the underlying problem that the challenges aren't pulling in the libraries like they're supposed to, but if you want to refactor the challenges to use native JS instead of jQuery, you've got a green light from me :)
QuincyLarson
on 27 Feb 2017
@QuincyLarson Could you please clarify this?
the underlying problem that the challenges aren't pulling in the libraries like they're supposed to
I was a bit unclear with my original message - I only suggest that we rewrite the failing tests with native solutions.
Greenheart
on 27 Feb 2017
@Greenheart Yes - I agree that if rewriting these tests in native JavaScript will speed things up (and maybe make them easier for new contributors to understand) we should go forward with this.
My other comment was just regarding the fact that some tests may fail because we're not yet able to pull in all the right libraries - @BerkeleyTrue is still working on this.
QuincyLarson
on 3 Mar 2017
@QuincyLarson Can you elaborate on how not pulling in the libraries is the underlying issue here? Seeing as though it works fine in Chrome, and other jQuery tests (as long as they don't involve the .css() method).
I looked into the issue a bit, and here's what I found:
There's an open issue over at the jQuery repo: https://github.com/jquery/jquery/issues/3514
The underlying Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=548397
In summary, we can't get the styles in Firefox from display: none; iframe.
The reason why this isn't a problem on the live site is that on there, tests are being run in the visible iframe, rather than an iframe specifically for the tests.
@BerkeleyTrue Would running tests in the visible iframe be possible in the beta? Could that be a solution?
There's a caveat with @Greenheart's suggested solution. Though I'm a big fan of vanilla JavaScript, it won't save us here. Using the style property is not the proper way to get the style: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style#Getting_style_information
I put together a little demo to demonstrate the difference between the two: http://codepen.io/systimotic/pen/ryLJBy?editors=1011
getComputedStyle would also not help, as it has the same issue as the jQuery solution.
Interestingly, I couldn't get the .style tests to work in any browser. This may indicate that I did something wrong in my demo. @Greenheart any input?
I'd love to get this working quickly. The amount of issues we've had on this is insane.
systimotic
on 5 Mar 2017
@systimotic my understanding is the challenge framework doesn't currently have a graceful way to pull in libraries like D3 selectively. I believe @BerkeleyTrue is working on that.
Anyway, you have my go-ahead to convert these jQuery-based tests to vanilla JavaScript :)
QuincyLarson
on 6 Mar 2017
@systimotic Excellent work, thanks for telling us about the issue in more detail. It makes sense that Firefox doesn't execute code related to hidden/unused parts of webpages.
Using a visible iframe would be a workaround, as it clearly works on the main site - but we proably want a separate test environment to improve the test framework for the future.
The behavior of your example can be explained by the MDN link you shared:
The style property is not useful for learning about the element's style in general, since it represents only the CSS declarations set in the element's inline style attribute
Thus, <style> tags or external stylesheets can't be read.
Greenheart
on 17 Mar 2017
Would running tests in the visible iframe be possible in the beta? Could that be a solution?
We run tests in a separate hidden iframe is to get around a whole host of issues with running user code multiple times for tests.
In the future I would like to run each tests in it's own environment, so this would not be a solution.
Alternatively we could try hiding the iframe in another fashion, such as making it position: absolute; top: -9999999999999, left: -999999999; and putting it in zero width div with overflow hidden. Would this get around that issue?
BerkeleyTrue
on 17 Mar 2017
@BerkeleyTrue Nice haxz! Since it still is off-screen, I don't think it would work - but feel free to test it! :smile:
Greenheart
on 17 Mar 2017
we can't get the styles in Firefox from display: none;
Since it still is off-screen, I don't think it would work
@Greenheart What makes you say that? Seems like the issue is display: none not that it is off screen.
BerkeleyTrue
on 17 Mar 2017
@BerkeleyTrue I am only guessing here, but as display: none makes the browser ignore an element, I'm afraid moving an element off screen could have a similar effect.
But we should definitely test your idea!
Greenheart
on 18 Mar 2017
I recently had a similar problem in a project that I solved by adding a class hidden and removing it once I needed to display the iframe.
The class hidden:
.hidden {
visibility: hidden;
width: 0;
height: 0;
}
@BerkeleyTrue solution also works.
Tiagojdferreira
on 28 Mar 2017
Related issues
EthanDavis
路
3Comments
trashtalka3000
路
3Comments
ROWn1ne
路
3Comments
robwelan
路
3Comments
SaintPeter
路
3Comments
Most helpful comment
We run tests in a separate hidden iframe is to get around a whole host of issues with running user code multiple times for tests.
In the future I would like to run each tests in it's own environment, so this would not be a solution.
Alternatively we could try hiding the iframe in another fashion, such as making it
position: absolute; top: -9999999999999, left: -999999999;and putting it in zero width div with overflow hidden. Would this get around that issue?