Jetpack Tweaks: Decode child selectors > in Custom CSS

[ryelle]

Fixes #678 — The > in CSS is encoded as > when output on WordCamp sites, which is invalid CSS. This fix is very simple, just replace the > with > again on output. The sanitization already strips out any HTML-like tags, so this should not introduce any security issues.

Props @megmorsie, @CdrMarks.

How to test the changes in this Pull Request:

1. Open the Additional CSS panel in the Customizer
2. Add CSS with an angle bracket, like

   body > div {
   	background: lightcoral;
   }

3. It should apply correctly in the customizer, so any divs that are direct children of body should have a pink background now.
4. Save and exit the customizer, view the site
5. It should still have the background on the live site
6. Alternately, view https://yoursite.wordcamp.org/?custom-css and the CSS should be there, with the > not encoded.

I also added two simple tests, you can see it fail if you disable the filter, and pass again after the filter is enabled.

[coreymckrill]

👍 Works on the sandbox. Took a lot of effort to get the tests to run locally 😅 but that looks good too. One minor comment, but not a blocker.

[coreymckrill]

Are there any other characters this could happen to? Would it make sense to run something like html_entity_decode() here instead of a simple string replace?

[ryelle]

I was hesitant to do that at first because I'm not totally sure why it's encoded, if there would be a security implication to decoding everything. Looking at the different selectors available, no others are encoded, but it would be possible to add anything to an attribute selector, which could get encoded (like a[href*='a=1&b=2], would become a[href*='a=1&b=2]). I'm not sure if supporting that edge case is worth any security issue (but… maybe there is no issue here?)

I updated the test to check against almost all the selectors available.

[ryelle]

I'm going to merge this as-is, if other selectors become a problem we can make the switch then.