Freecodecamp: changes in editor do not change real-time - must click run tests

[RandellDawson]

Challenge use-html5-to-require-a-field has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.

The issue I am reporting is not unique to this problem, but is definitely more evident in this problem. The original FCC allowed you "see" the changes browser screen (fake phone on the right) as you edited them. Now you have to click "Run tests" to see any change.

The problem with this in this particular exercise is that once you type the "required" statement into the text box and click "Run tests", you automatically pass the challenge without being able do as it says in the instructions (see below).

Then try to submit the form without inputing any text. See how your HTML5 form notifies you that the field is required?

If you come into the challenge and type "required" correctly and click the submit button shown in the fake phone, does not prompt you with "Please fill out this field", because you must first run the tests for the fake phone to get the new code.

Why did they make such a change? The original FCC allowed you to "play" with the code before running tests. All good editors (not notepad) give you a real-time view of changes you make in the editor.

Just curious why the change?

Randell

```html

CatPhotoApp

Click here for cat photos.

Things cats love:

• cat nip
• laser pointers
• lasagna

Top 3 things cats hate:

1. flea treatment
2. thunder
3. other cats

Submit

```

[raisedadead]

@rmdawson71 Hi, and thanks for the feedback, we deliberately disabled the "run on the fly" because, in some of the jQuery challenges we used to get weird errors.
There used to be exceptions thrown and that was more bad UX than now.

Also there was one particular challenge which had more DOM elements inserted than the code written in the editor.

This confused a lot of campers.

Sure, I agree that this more of an inconvenience, and we should be looking at this, sometime in future. But I don't believe that it a a work stopper for the moment.

We are open to feedback though.

Thanks again and happy coding!

[QuincyLarson]

Thinking about this and reading @raisedadead's response, I think we just need to change the "run tests" button's copy to be "run tests and update preview" - that way people realize we're no longer immediately updating the preview.

What do you think about doing this, @rmdawson71?

[RandellDawson]

I suppose that would work. Is there a way to load the page the first time where it updates the preview but does not run the tests? That would be the best solution, then you would not have to change the button text and people could see the challenge “as-is” before making modifications to the code.

I know it was stated there are some JQuery issues when auto-running , but I have to be honest and say the beauty of the real-time preview updates were a big selling point in learning new challenges.

Maybe there can be some verbiage add to the first 1-10 challenges with text at the top stating something like “Please run your tests first to see what the current code produces before changing any code.” And then, on challenges that did not build on the previous challenges content, put the same text at the top of the challenge again. I find it quite startling when I first hit the Run Tests button and see that the content is completely different than the last challenge. I always do a double-take and it makes me think there is a bug, because I was expecting the preview to look different. For a beginner, they would not know if they messed up their code or they really should be seeing content that is completely different from the last challenge.

If there are only a handful of JQuery challenges where "run on the fly" is a problem, why not disable "run on the fly" just for those particular problems and then add in the text I mentioned above for those. That way, the majority of the challenges work as was originally intended with no surprises to the camper.

These are just my opinions having worked in both versions. I really do like the new content and challenges of the Beta and continue to work through them all to fill content not covered in the original FCC.

Randell

[QuincyLarson]

@randell I agree that it would be best if the code ran immediately when the challenge loaded up so that campers didn't have to run it the first time.

@raisedadead is this something we can do? Would there be any detriments to it, other than the potential for infinite loops?

Perhaps we could only run the code when it's the unchanged challenge seed?

[raisedadead]

@QuincyLarson well in a perfect world, we should be able to execute the code only on the jQuery challenges.

I am not 100% percent sure, but yup I'll give it a try and update.

[QuincyLarson]

@raisedadead OK - thank you for looking into this. We need to figure out a way to do this that's reasonably safe, as campers have already come to expect this behavior from our editor and if we change it, hundreds of thousands of people will be scratching their heads :)

[QuincyLarson]

@BerkeleyTrue what's the best way to safely run the seed code when a user arrives at a challenge, so that the preview is populated?

[BerkeleyTrue]

@QuincyLarson The issue does not lie with just the jQuery challenges. It existed with all challenges. Users where constantly locking up their code because the preview attempt to display incomplete code. Waiting for the user to submit code to run in the preview drastically reduced this issue.

[raisedadead]

I prefer closing this as a wontfix in that case, which is we do not render the preview before user submits.

Also, I am not sure, but could we just add a message stating this?

[nicklambourne]

I know this is a relatively old issue, but would a potential fix be run the preview once, without tests, only for those challenges that won't involve lockups. Even if it was only for the earlier HTML/CSS sections, the ability to see what you're changing is particularly important when designing visual elements.

In the very worst case scenario, the content of the preview from the last challenge should be cleared (it is definitely noticeable and somewhat confusing in the Flexbox section, when the challenges jump backwards and forwards between examples - from plain coloured boxes to tweets etc.). In my opinion it would be better to present a blank preview, with a warning that the code needs to be run to initiate the preview, but I'm interested to hear whether other people feel the same.

[QuincyLarson]

In response to @nickl93's suggestion, there a way we could at least render the HTML and not run the JavaScript?

If not, then we should show a message in the preview like "Press Control+Enter to run your code" that always shows up.

@raisedadead @BerkeleyTrue it would be a much, much better user experience if we could figure out a way to prevent infinite loops so that the preview would always render upon arriving at a challenge.

[raisedadead]

@QuincyLarson

Ideally that is the characteristic dependent of the solution. We have mechanisms like loopProtect for instance already, but nothing is full proof and its tied to the code and the browser's behaviour.

What I can see that an alternative would be to:
Step 1: Show at least the seed code rendered (not user's solution), which we know is good.
Step 2: Prompt a message as discussed above.
Step 3: Execute all of the code when user interacts via the Run Test.

[QuincyLarson]

@raisedadead I like your proposed solution.

[BerkeleyTrue]

I'm also in favor of @raisedadead's solution.

To document some of the reasons this was disabled in the first place:

• Helps reduce the amount of "Help my browsers freeze when the page loads"
• Reduces the risk of xss attacks by preventing malicious code from running in the browser. (less so in the case where a user is actively writing code or seed code)

Maybe we can indicate to the user when code is stale. Something along the lines of graying out the iframe (opacity .5).

[QuincyLarson]

@BerkeleyTrue Yes - or when the toast that pops up that says "We found your old code" perhaps that toast could have a button to trigger the running of their code.

[yoizfefisch]

If the issue is with on-the-fly updating, is it at least possible to update the preview when a new challenge arrives so that it reflects the new challenge? For each new challenge I begin, I first run the test to see how it looks before I follow the challenge instructions.

Also, I think this wasn't suggested yet, maybe the solution would be to add a button to preview changes? Although that's not very different from running a test and getting the "keep trying" toast.

[QuincyLarson]

@yoizfefisch I think @BerkeleyTrue is working on a way to load the HTML and CSS without running the JavaScript when the page loads. This should make it clear that the new challenge has loaded without running the risk of an infinite loop or malicious code.

[rockwellmoon]

For what it's worth, I just spent 20 to 30 minutes troubleshooting why I wasn't seeing the "Please fill out this field" pop-up until I finally found this github issue. It's definitely not intuitive to me (a newbie) that the user has to click "Run tests", especially when the Preview pane showcases live changes for things like adjusting the text in a p element.

[QuincyLarson]

I'm closing this issue as stale since it hasn't been active lately. If you think this is still relevant to the newly updated platform, please explain why, then reopen it.