Params tag removed in IE
| Project: | Wysiwyg |
| Version: | 7.x-3.x-dev |
| Component: | Plugins |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
If the Teaser Break plug-in is enabled, when you add a YouTube video via the Media plugin in IE7, the generated HTML does not include (or has removed) the <Param> tag which is inside from the <OBJECT> tag. This causes HTML that doesn't work with IE. Strangely, if you use FF (3.0), the <Param> tag does not get removed. If you disable the Teaser Break plug-in, it works in both browsers.
Specifically:
Bad IE7 Generated HTML
<object width="425" height="350" data="http://www.youtube.com/v/ZaxymPkC6SA" type="application/x-shockwave-flash"></object>Valid FF Generated HTML
<object width="425" height="350" data="http://www.youtube.com/v/ZaxymPkC6SA" type="application/x-shockwave-flash"><param name="src" value="http://www.youtube.com/v/ZaxymPkC6SA" /></object>Note a quick way to see this is to have the "source(html)" button enabled. Clicking the HTML button after inserting a video will show if the tag is missing or not.
I only tested YouTube flash videos but it might have the same problem with other media types. It was first found on a fairly complex site, but the root cause was determined on a new test site with only the Admin Menu and Wysiwyg modules enabled. (and the temporary fix of removing the Teaser Break plug-in validated against the full site).
Version Details: Drupal 6.14, Wysiwyg 6.x-2.0, TinyMCE 3.2.7, IE 7/XP Pro (latest patches).
#1
This problem is not specific to Teaser Break. Tested this with almost all supported editors and plugins in IE8. It happens in any editor which does not explicitly hide the params tag from IE. What Internet Explorer does not understand, it removes. The tag is removed whenever the source string is parsed into a DOM tree and/or serialized back to a string, just like we do in Teaser Break (and Image Assist, Column Break and other Drupal plugins).
TinyMCE, FCKeditor, CKEditor and some other editors know about this so they internally escape certain tags and use placeholders when not working with pure strings. The rest don't do this so IE finds the tags and removes them.
To work around this, we probably need a way to escape these 'bad' tags before sending the source to the plugins. CKEditor adds a 'namespace' to the tags like
<params ...>becomes<cke:params ...>, that might work. But this also means Drupal plugins need to be aware of how this is done, reversed and re-done if they operate on these tags. It must still be possible for them to create a DOM tree if they need it. If editors mess this up internally, we can't do much about it other than file a bug on their trackers.This is related to issues like:
#617944: HTML tags are automatically capitalized and not validating,
#495828: In TinyMCE in IE7 Relative Links Become Absolute Links if Teaser Break is Enabled,
#510552: Teaser Break and Image Assist plugins dropping trailing slashes (XHTML vs HTML).
They all deal with content which needs escaping in some way.
#2
Thanks for the clairification. I splunked around in the code and see what you mean about this. As pointed out in:
#510552: Teaser Break and Image Assist plugins dropping trailing slashes (XHTML vs HTML)
It all seems to happen in the detach(content, settings, instanceId) function in the break.js code. Specifically, when jQuery is called to convert the HTML to a DOM structure (and create the $content var). Since the results of this are returned everytime the visual display is converted to raw HTML, it effect "unparseable" tags all the time, not just when a teaser break has been inserted.
It seems to me, that changing this function to use a Regex replace on the content string to change "img.wysiwyg-break" tags to the "break" comment tag would fix this. Not as sexy as jQuery, but since the input is coming from an "unreliable" source (e.g. users and various 3rd party editors with different opinions on what good HTML is...), I'm not sure you can rely on jQuery to alway parse this input into html correctly.
Using a Regex function on the raw string would seem to be a more reliable method and much less likely to have bad side effects.