HTML Filter does not strip text between 'style' and 'script' elements

Same issue. I would like to make sure these styles are stripped and not displayed.

I believe the people who are having issues with this are people who are using mailhandler, in which an entire HTML Email will get inputted into the body, which usually contains

I agree it doesn't make sense to strip script tags but leave their content; the only reason I can think of to show the script code is to allow an administrator user to notice there is content that must be removed (if showing the JavaScript code mixed with normal content would really allow to notice it).

I guess it is not considered a critical bug.

I believe it's considered a critical bug by everyone in this thread.

I personally can't see any reason to leave the stuff in between the tags in the output, but I can see many reasons why people would want it removed.

Issue is probably that with a filter that's so widely used, the maintainers are unwilling to change something that might effect many already existing installs. In which case this patch should at least be rolled into something less stable like DRUPAL-7 and for Drupal 6 we can use the extra module provided by Dane Powell.

I would still like to see the maintainers ring in on this, so us people who are effected by thing, can provide a proper solution for ourselves.

I meant that the issue seems to not be considered critical from the maintainers.
I am the first to think the content of the script tag should be removed together the script tag. To only remove the tag works for all the other tags, which have text content that can be shown; it is not the case for the script tag, which has content that is not text, but script code that should be executed by the browser.

If I would forget that the currently set input format does not allow me to use the script tags, I would like better if the script code would not be shown in the page.

Drupal's "input formats" are made up of an ordered list of "filters" which are applied (in order) to the text of a particular format. If you have a site-specific requirement to remove content from *inside* elements, you should use a module that provides a filter that does this - then add this filter to your input format.

Perhaps there's one already at http://drupal.org/taxonomy/term/63

For a good background on Filters and Formats see http://www.lullabot.com/articles/drupal_input_formats_and_filters

The problem here is not choosing an input filter to use, but a Drupal input filter that is not doing completely its task (or it is not doing what users expect from it).
If it makes sense to only strip the HTML tags when the tag is something like <h2>, <a> (compare "Test" with "Test"), it doesn't make sense to do the same with a tag like <script>, where the content of the tag is not text that should be shown.

To all people in that thread that consider this issue as "critical": nothing in Drupal happens unless *someone* actually do something for it. Reassigning to Drupal 7, where it should first be considered, before an (eventual) back-port to Drupal 6.

It seems like a feature request to me - the filter does what it says it does: remove *tags*. The fact that you want it to remove the *stuff between some of the tags*, is new/extra - the definition of a feature request. But, this distinction needn't effect whether it gets done.

Seriously, this would be pretty easy in a contrib module.

I think that normally by "HTML tag", one means "the tag, and its content"; the content of a tag is not seen as an entity separated from the tag that contains it.

#18: so are you saying that <em>something important</em> should be removed entirely? What about <b> or <span> or <div> etc? (the actual selection of tags is up to the site admin). So clearly you don't mean "remove all contents from all removed tags".

Hi Dane -- have you tried your regular expression with the Custom Filter module? -- I'm thinking about putting it in there -- it would be nice to have it as a separate filter, so it could be assigned to run before HTML Corrector, but HTML Corrector could run before HTML Filter...

http://drupal.org/project/customfilter

subscribing

Anyone up for implementing this? Shouldn't be too hard.

#25-2 These will not match all tags. Office filter now uses this

  $text = preg_replace('/<style.*?<\/style>/xmsi', '', $text);
  $text = preg_replace('/<xml.*?<\/xml>/xmsi', '', $text);
  $text = preg_replace('/<script.*?<\/script>/xmsi', '', $text);

Verified the behavior described in the issue is still present in 8.0-alpha4.

sun (#24) and kiamlaluno (#13) agree this should be considered a bug - the default expectation is that text inside a script or style tag would be removed along with the tag itself.

This would also need a test.

D7 d.o does funky things to HTML tags in issue titles so re-titling to fix.

Tagging for tests per the last comment.

#28: issue titles are not filtered by text formats, but by check_plain()?

@Wim Leers, no idea. All I know is that issue titles with HTML get messed up in certain issue views, can't remember exactly how atm but it might just strip out the tags.

#31 is inefficient because it is serializing the html an additional time. It would maybe be preferable to add some kind of option to XSS::filter() to strip the inner tag contents.

This probably needs a test, but otherwise the patch in #34 seems solid.

I am having the same issue in drupal 8.9.16. In one of the view we are loading the content which has script in it. And when we strip html it strips just the

I need to do more testing before publishing

This came up as a daily bugsmash target.

Testing with 10.1 I added

<script>alert('hello');</script>

and confirmed alert still appears.

This ticket will still need a test case (or expand existing ones).

Plus an issue summary update using the default template

thanks.

So brought this up in #bugsmash with @larowlan and @longwave and consensus seems to be this is a feature we may want to keep. Shows that a user has done something they shouldn't.

Also the code that would probably have to be edited is Xss.php which is a nightmare, and would impact other tags as well.