A page with this body content

<script type="text/javascript">
<!--
javascript:window.open('http://www.example.no/kart/kart.php','test','width=680,height=610,menubar=no,status=no,location=no,toolbar=no,scrollbars=yes,resizable=yes,directories=no')
//-->
</script>

gets transformed into this

<script type="text/javascript">
&lt;!--
javascript:window.open('http://www.example.no/kart/kart.php','test','width=680,height=610,menubar=no,status=no,location=no,toolbar=no,scrollbars=yes,resizable=yes,directories=no')
//-->
</script>

when loaded in a browser. In other words, < is replaced with &lt; which makes the JavaScript code non-functional.

Comments

jpoesen’s picture

jpoesen commented

Just to clarify:

* this does not happen in D5

* the page body format is set to FULL HTML

* only the html comment tag within a set of javascript script tags get escaped

rbns’s picture

rbns commented

Just giving one deeper example:

Probably the major drawback of this behavior will occur whit Google AdSense publicity and with Flickr Flash badges. The automatic replacement of <!-- for &lt;!-- inside JavaScript tags will prevent them from work inside Drupal blocks. (Flickr HTML badges works just fine, you have to use the Flash badge to reproduce the error).

But it is not enough to be on Full HTML mode to reproduce this bug, you will need to enter the options of Full HTML in http://www.example.com.br/admin/settings/filters/3 and then activate the option HTML Filter, only this way the replacement will take place.

Operating just in Full HTML mode, without activating the HTML Filter will keep things working just fine, even inside blocks (something that took me a considerable amount of time to figure out and seems worth to share).

dman’s picture

dman commented

So, um, why did you have the Full HTML format with the HTML Filter turned on ? :)
That sorta ruins the effect, doesn't it :-)

rbns’s picture

rbns commented

Yeah. That is a funny observation :-)

But the fact is that the option is available in user interface and if it got enabled it will brake the JavaScript inside a block. And the average user will not have a clue of the reason Google Ads suddenly disappear or even never got to work. Not a user friendly approach, I think.

It is one erratic behavior. It does not correct or replace the code, it just brakes the code replacing one single center character. :-(

I'm just beginning to understand Drupal's structure and architecture, so I do not want to go beyond my league making premature suggestions, but probably a path to correction would be to disable this option if it does not make any sense like dman suggests above (and I'm not sure it does not make sense), or to prevent Drupal from messing with this specific character ">" what seems to me to be the origin of the problem.

Well... anyway further investigation appears to show that the error will take place with the "HTML corrector" and/or "HTML filter" options enabled.

dman’s picture

dman commented

Well, escaping unknown HTML characters is HTML Filters job. So this will happen with any input format it's applied to.
"Full HTML" just happens to be an available preset. Default to use when you DON'T want this behaviour.

Using the HTML filter at all shows that you don't trust the input - user-supplied stuff - and don't want it doing bad things.
Allowing user-supplied javascript to run is what it's protecting you from!
So I'd call it expected behaviour.

However...
if it let the SCRIPT tag through (I assume you actually chose that!) and then broke the code inside it, I guess that's an issue that could be fixed up.
But the point remains - you should not be using html filter and scripting on the same input. If you want power to do script, there's not much left for the filter to protect you from. Turn it off, how can it be helping?

rbns’s picture

rbns commented

Hummm... I see, but again, in my opinion, it does not seems to be the user friendly approach.

As I mentioned above it will probably be better if this "HTML Filter" function could be "factory disabled" at the "Full HTML" preset. Just to avoid confusion amongst the users, since it is the "Default to use when you DON'T want this behavior". Other way it is just not clear and leads to erratic usage.

And the same logic will not apply to this issue when the user happens to set up the "Full HTML" preset + "HTML corrector" option.

Do we have a bug in this combination?

dman’s picture

dman commented

You are right, it shouldn't.
But out-of-the-box, it isn't.
On a clean install, "Full HTML input format" does not have HTML filter applied.

Probably just changes made at your end AFAIK.

If you can replicate on a clean install, then yes, we have an issue.

craigmoliver’s picture

craigmoliver commented

I'm having the exact same issue with my drupal install. I'm trying to put javascript in a block. Any one workout a fix yet?

dman’s picture

dman commented

- You should enter your code NOT using a WYSIWYG
- Input format for your block should be 'FULL HTML'
- The Full HTML input format should NOT have 'HTML Filter' in the list.

(-) .. Rendering of the block should be done either using the normal default block templates and theming functions, or be passed through the filter callbacks appropriately if you are trying to custom-code it. If that doesn't make sense to you, you can probably ignore it.

gpk’s picture

gpk commented

The culprit is probably the HTML corrector which has a known bug and does not handle HTML comments correctly. See http://drupal.org/node/222926.

Since the other problem described in this issue was to do with applying the HTML filter to content which needed it disabled, this issue can probably be marked as a duplicate.

liquidcable’s picture

liquidcable commented

I can confirm gpk, that the culprit is the HTML corrector. I had the same problem, and I disable HTML corrector and it is working fine now.

gpk’s picture

gpk commented
Status: Active » Closed (duplicate)

OK, marking as duplicate per #10. Must get round to testing the patch over there .. ;)

gpk’s picture

gpk commented
Component: base system » filter.module