Freecodecamp: [beta] Decrease the Opacity of An Element - browser specific test failure

Created on 31 Jan 2017  路  12Comments  路  Source: freeCodeCamp/freeCodeCamp

Challenge decrease-the-opacity-of-an-element has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8.
Please describe how to reproduce this issue, and include links to screenshots if possible.



<style>
  h4 {
    text-align: center;
    background-color: rgba(45, 45, 45, 0.1);
    padding: 10px;
    font-size: 27px;
  }
  p {
    text-align: justify;
  }
  .links {
    text-align: left;
    color: black;
    opacity: 0.7;

  }
  #thumbnail:hover {
    box-shadow: 0 10px 20px rgba(0,0,0,0.19), 0 6px 6px rgba(0,0,0,0.23);
  }
  .fullCard {
    width: 245px;
    border: 1px solid #ccc;
    border-radius: 5px;
    margin: 10px 5px;
    padding: 4px;
  }
  .cardContent {
    padding: 10px;
  }
  .cardText {
    margin-bottom: 30px;
  }

</style>
<div class="fullCard" id="thumbnail">
  <div class="cardContent">
    <div class="cardText">
      <strong><h4>Alphabet</h4></strong>
      <hr>
      <em><p>Google was founded by Larry Page and Sergey Brin while they were Ph.D. students at Stanford University.</p></em>
    </div>
    <div class="cardLinks">
      <u>
        <a href="https://en.wikipedia.org/wiki/Larry_Page" class="links">Larry Page</a><br><br>
        <a href="https://en.wikipedia.org/wiki/Sergey_Brin" class="links">Sergey Brin</a>
      </u>
    </div>
  </div>
</div>

first timers only help wanted device specific

Most helpful comment

@Marvive Thanks for reporting this! I am able to confirm this on Safari, however the solution works correctly in Chrome.

/ cc @freeCodeCamp/moderators - it looks like this is because Safari returns a finer precision number than Chrome does when $('.links').css('opacity') is called. Even though the user sets an opacity of 0.7 Safari ridiculously returns "0.699999988079071". So to fix this, we could use Chai's approximately assert:

assert.approximately(parseFloat($('.links').css('opacity')), 0.7, 0.1, 'message: ....');

where 0.7 is the expected value, and 0.1 is the +/- delta.

This seems easy enough - should we open it up to Help Wanted / First Timers Only?

All 12 comments

@Marvive Thanks for reporting this! I am able to confirm this on Safari, however the solution works correctly in Chrome.

/ cc @freeCodeCamp/moderators - it looks like this is because Safari returns a finer precision number than Chrome does when $('.links').css('opacity') is called. Even though the user sets an opacity of 0.7 Safari ridiculously returns "0.699999988079071". So to fix this, we could use Chai's approximately assert:

assert.approximately(parseFloat($('.links').css('opacity')), 0.7, 0.1, 'message: ....');

where 0.7 is the expected value, and 0.1 is the +/- delta.

This seems easy enough - should we open it up to Help Wanted / First Timers Only?

Does this same thing happen in Firefox? Would the new test fix it?

@dhcodes _If_ the same thing happens in FF, and I'm not sure that it does, the new test should fix it, as long as it's not off by more than a full tenth, and I can't see a browser registering 0.7 as 0.6 or less. Returning "0.699999988079071" is one thing, it's practically the same as 0.7, but it would be way off at more than a tenth discrepancy.

@no-stack-dub-sack I went ahead and tested it and it would not fix it in Firefox because the .css tests are not working there. Still investigating that one. It should fix it in Safari.

@dhcodes Ahh, so it's not fixing in FF, but for a different reason altogether right? Related to #12644 & #13005? Assuming that issue was resolved though, and that it is unrelated to this, I think this solution would do the trick.

Knowing it at least fixes in Safari, what do you think the best way to proceed is? Should we fix this and just make sure to circle back and test it in FF once the other issue is resolved?

@no-stack-dub-sack I'd say fix this for Safari now and deal with Firefox if it occurs in the future :blush:

I think .css() or possibly CSP-issues with iframes are to blame for Firefox issues lately. This seems to affect Safari.

@Greenheart Should I just go ahead an do it? Or do you think we should open this one up? It's a pretty simple fix. On the other hand, I already know this issue and don't mind at all

@no-stack-dub-sack I don't know actually, we don't have many "first-timers-only" open at the moment, so I think we should spare whatever we can for new contributors.

Fun fact: I just did the exact opposite without realizing a few hours back! I was in patch-mode... :neutral_face:

@Greenheart haha, ok let's do it then. Opening this up to first timers only, the task being to change the code on this line from

"assert($('.links').css('opacity') == '0.7', 'message: Your code should set the <code>opacity</code> property to 0.7 on the anchor tags by selecting the class of <code>links</code>.');"

to

"assert.approximately(parseFloat($('.links').css('opacity')), 0.7, 0.1, 'message: Your code should set the <code>opacity</code> property to 0.7 on the anchor tags by selecting the class of <code>links</code>.');"

Contributors: please leave a comment and let us know you are working on this! See an explanation in the above comments for why this change is being made. And see this guide for help with getting an environment set up and for PR guidelines. Feel free to ping us with any questions in the contributors chatroom!

@Marvive perhaps you'd like to take a stab since you pointed out the problem?

I can take this.

Sorry for being so late to the party! Could the rounding problem in https://github.com/freeCodeCamp/freeCodeCamp/issues/12687 be related?

@systimotic It could be, but it seems more like Safari has some funky math for getting/setting some css values.

Was this page helpful?
0 / 5 - 0 ratings