great work,
but I will be honest: this is the overload, just for fix the email issue, from my point of view

Hi, Thank you for your Comment. Look, the problems that can occure aren't only with input, select or textarea fields. The mainproblem is, that where ever your use a string, that look like an emailadress it can distroy the html or javascript structure.
For example:

cat@table.gif is a valid filename. But for the emailcloaker it look like a emailadress. For this reason, i think, that we fix the obvious bugs at first, as input fields, select boxes, textareas, pictures, script tags etc. In addition, a user should be given the opportunity to define content sections on his own, as we are not aware of all pontential errors yet. For this purpose, the tag {noemailcloak}...{/noemailcloak} is defined. Within this tag, the cloaking functionality will be turned off.

I have tried to get the code lightweight so that the code hasn't a impact on the performance. I work with regex only for extracting the riski parts. The replace is always with str_replace.

Kind regards

sorry I tried to write an img-tag, but the System has rendert it. here is the example again [without <>]:

img src='cat@table.gif'

I thought we already had the ability to turn cloaking off

Yes, you can turn off the emailcloak functionality for the hole content, but not for only a section.

@xsability I understand your arguments, but I would stay with simple solution that we already have,
mean the ability to turn off the cloaking for whole content

For the emailcloaker community member has opend 2 Issues:
#5080 http://issues.joomla.org/tracker/joomla-cms/5080
#4995 http://issues.joomla.org/tracker/joomla-cms/4995

We have now a working solution, that solves booth issues at once and
prevents other possible issues in that context. Why we shouldn't use it?
Even it hasn't a impact on the performance...

I have tested this item successfully on 4deec3a

@designbengel Thank you for testing.

I have tested this item unsuccessfully on 4deec3a

@test unsuccessful here when mail on image:
for
<p> <a href="mailto:myname@gmail.com"><img src="images/sampledata/fruitshop/bananas_2.jpg" alt="" /></a></p>
I get on frontend:

I have tested this item successfully on 4deec3a

@test on 3.5.0 beta. ii applied the patch, the result was exact the same as described the issue.

I have tested this item successfully on 4deec3a

I edited an article as described in the test method.
Results before and after implementing the patch gave the expected results.

I have tested this item successfully on 4deec3a

Test was successfully

@LourensH , @w13ear , @FeikeMulder, @infograf768, thank you for testing.

@infograf768 this error ouccurs, because the e-mail-address String is within the a-tag. I don't classify a-tags as risky, because i think the email-cloaker allready is checking for this. If the string, that look like an emailadress is placing within the img-tag, then this hopefully doesn't occurs. This is the issue that I solved.

@xsability
The issue is that adding a mail link to an image using TinyMce Link icon adds the mail in an <a tag as I posted above.

I share @Fedik option, that this may be too much.
What I suggest is checking in last pattern check if email address is wrapped in value="email@address.com"

So I've tried with regex lookarounds and changed

// Search for plain text email@example.org
$pattern = '~' . $searchEmail . '([^a-z0-9]|$)~i';

into

// Search for plain text email@example.org
$pattern = '~(?<!value=")' . $searchEmail . '(?!")([^a-z0-9]|$)~i';

But that didn't work properly.

Then I had an idea to check preceding and forthcoming strings inside the while loop but everytime i used continue, next preg_match call found same matches so I just created an infinitive loop.

Quick workaround is to add <!--{emailcloak=off}--> code to the output, but this disables email cloak plugin for whole content.

I think we need a regex ninja here.

I have tested this item unsuccessfully on 4deec3a

issue raised by @infograf768 still present.

@Wolf-Rost Can you please check the issue raised by @infograf768 ?

Hey guys I have two questions concerning this PR since I was trying to fix the occuring error for this PR:
1. Doesnt PR #11353 fix the orignal issue anyway?
2. The error that is described by @infograf768 appears on my staging version anyway and I wanted to ask if its the same for anyone else? If so this seems like another issue entirely and not caused by this fix specifically.
Also what is the point of converting the "mailtext" to the htmlentities (as seen in in the JHtmlEmail class L63)?

I think #11353 fixes the issue so I'm closing this PR