Bug 3316 - standalone < tag in abstract field stops text from displaying
standalone < tag in abstract field stops text from displaying
Status: RESOLVED FIXED
Product: OJS
Classification: Unclassified
Component: Submissions and Publishing
2.x
PC Linux
: P1 normal
Assigned To: MJ Suhonos
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-23 14:56 PDT by James MacGregor
Modified: 2009-01-08 08:08 PST (History)
0 users

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2008-03-23 14:56:10 PDT
If a standalone < tag appears in an abstract, neither it nor any other text following it will display when the abstract is viewed. 

Example provided here: http://pkp.sfu.ca/support/forum/viewtopic.php?f=3&t=2945

I've managed to replicate the issue.
Comment 1 James MacGregor 2008-03-23 14:58:41 PDT
Note: I just realized that the forum poster was referring to OCS; however I replicated this in OJS. Probably safe to assume then that it's inherent in both systems. 
Comment 2 Alec Smecher 2008-03-29 18:20:59 PDT
This is because OJS and OCS allow limited HTML in abstract fields, so "<" is being treated as an invalid HTML tag. This should already be addressed in OJS > 2.1.1 using the TinyMCE plugin (and in CVS OCS) -- James, were you using TinyMCE when you duplicated this in OJS?
Comment 3 James MacGregor 2008-03-30 00:05:28 PDT
(In reply to comment #2)
> This is because OJS and OCS allow limited HTML in abstract fields, so "<" is
> being treated as an invalid HTML tag. This should already be addressed in OJS >
> 2.1.1 using the TinyMCE plugin (and in CVS OCS) -- James, were you using
> TinyMCE when you duplicated this in OJS?
> 

Yep -- OJS 2.2 stock install, using TinyMCE. I've tested a bit further, using both stock and CVS, and actually, this behaviour only happens when the tag is followed by a non-space character: "<word" and "<." trigger the display stoppage, but "< word" appears as "< word". 
Comment 4 MJ Suhonos 2008-04-29 16:07:41 PDT
This was an issue with Core::cleanVar() -- by default it would convert HTML entities to their respective characters.  Behaviour has been changed to skip this if TinyMCE is enabled (assuming HTML entities coming from TinyMCE are intentional).
Comment 5 Alec Smecher 2008-04-29 16:15:03 PDT
MJ, the core shouldn't mention any plugins by name -- the TinyMCE plugin should be in charge of this kind of behavior modification. If necessary, you can add a hook to Core::cleanVar. (Also, don't forget OCS and the Harvester!) -- Thanks.
Comment 6 MJ Suhonos 2008-06-09 15:17:04 PDT
Mea culpa; thanks for your comments Alec.  I actually reproduced this incorrectly -- the issue is that strings starting with '<' followed by alphanumerics are caught by the strip_tags call in String::stripUnsafeHtml().

This may be bad behaviour on PHP's part, but I'm not going to make any drastic changes to code that we rely on for preventing XSS attacks.  Data is stored correctly, this is a display (Smarty) issue.

Deferred as a known issue.
Comment 7 Alec Smecher 2008-06-09 16:44:16 PDT
MJ, do you know where these &#someNumberHere; entities are coming from? AFAIK, TinyMCE should use the expected &lt; and &gt; etc.

(FYI, you should defer issues by marking them against a subsequent or to-be-decided release, rather than resolving them as LATER.)
Comment 8 Alec Smecher 2008-06-11 10:31:51 PDT
Needs further testing -- but for the moment, either TinyMCE or a space between the < and the number (when TinyMCE is disabled) should be good work-arounds.
Comment 9 Alec Smecher 2008-12-08 08:51:14 PST
MJ, is this entry still relevant, or should we close it?
Comment 10 MJ Suhonos 2009-01-08 08:08:24 PST
Alec, this should be fixed as part of the new phputf8 code (#3807):

http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=3807

Marking as resolved.