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:

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 22 (20 by maintainers)

Commits related to this issue

fix(frame): Fix fcc-test-frame on firefox I used an alternative to display: none; to allow Firefox to properly run challenge tests Closes #10749 — committed to dhcodes/FreeCodeCamp by dhcodes 7 years ago
fix(frame): Fix fcc-test-frame on firefox I used an alternative to display: none; to allow Firefox to properly run challenge tests Closes #10749 — committed to mhatout/freeCodeCamp by dhcodes 7 years ago

Most upvoted comments

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 Mar 17, 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 Mar 5, 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 Mar 28, 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 Mar 3, 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 Feb 25, 2017