Negated condition in rules does double htmlentities()?

Are you using Commerce or Ubercart? If so, you should report this to that module's issue queue, not Rules.

Confirmed that this still happens in the latest 7.x-2.x release, but it is absolutely NOT a problem with Ubercart - this is a problem with Rules (or, more specifically, the '#type' => 'link' render element) improperly double-encoding the condition name when the the negate text is added. The only reason it shows up with an Ubercart condition and not any of the built-in core Rules conditions is because the core Rules conditions don't use special characters like ' which can be HTML encoded.

To see that this really is a Rules problem, you can simply edit one of the core Rules conditions (such as 'Data comparison' in modules/data.rules.inc) and change the name to include an apostrophe. Then clear your caches and use that condition (negated) in a rule - you will see the exact same behavior as described in the original post.

The problem does not exist in Rules 8.x-3.x, just in 7.x-2.x.

Here's a patch that fixes this problem. I would appreciate it if someone would apply this patch and confirm that.

Patch looks like:

   public function label() {
     $label = parent::label();
-    return $this->negate ? t('NOT @condition', array('@condition' => $label)) : $label;
+    return $this->negate ? t('NOT !condition', array('!condition' => $label)) : $label;
   }
 }

The problem was that using @ here prematurely sanitizes $label when the NOT is prepended. Note that in the original code $label is not sanitized here except in the case where NOT is prepended. Thus, this is not introducing a security problem - the patch is just treating NOT $label the same as we were previously treating $label. The security problem would only be if $label wasn't sanitized before output, which occurs elsewhere in the code. Drupal policy is to sanitize before output, and Rules DOES do that. And we know Rules does that, because that's why we were getting a DOUBLE escape when we sanitized $label here.

Testbot does not like fuzz. Re-roll against current HEAD.

(EDIT: It seems I named the patch incorrectly. But the contents are as intended - it's just the name that's wrong)

Okay, here's a test-only patch that demonstrates and reproduces the error described by the original poster. This patch should FAIL because of the bug.

Also, here's a patch with the same test but also with the fix posted in #7. This patch should PASS because the fix solves the problem.

Tests results in #8 are as expected - the test-only patch adds tests to demonstrate the problem in the current -dev, and the other patch fixes the problem and proves the fix with the new tests.

Committed.