bugGNUstep Application Project - Bugs: bug #61920, [Grr.app] parsing of <PRE>...

 
 

bug #61920: [Grr.app] parsing of <PRE> is too crude

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Tue 25 Jan 2022 10:08:34 PM UTC
   
 
Category:  Application Severity:  3 - Normal
Item Group:  Bug Status:  Ready For Test
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 Feb 2022 12:46:15 PM UTC, comment #10: 

Updated the patch to avoid special treatment of comments and xml.

Added another HTML-entity 'ohm'

(file #52826)

Sergei Golovin <svg>
Mon 07 Feb 2022 08:47:08 PM UTC, comment #9: 

Yes, I like that more. Essentially we parse those tags, be it in PRE or non-PRE, but don't do anything with them, which makes sense, especially for <!-- -->.
Neither of them should have formatting effect, in theory the xml tag could drive the parser, but for our crude parser it makes currently no sense anyway.

Riccardo Mottola <rmottola>
Group administrator
Sun 06 Feb 2022 05:22:14 AM UTC, comment #8: 

OK. If you don't like 'special treatment' I can add recognising the pseudo-tags <!-- --> and <?xml ?> by adding something like

-[openComment:]
-[openXml:]

and context flags

BOOL comment;
BOOL xml;

to recognise the closing parts --> and ?> instead of /> .
What do you think?

Sergei Golovin <svg>
Sun 06 Feb 2022 04:44:29 AM UTC, comment #7: 


> According to the specs only these tags are excluded in PRE:
> <!ENTITY % pre.exclusion "IMG|OBJECT|BIG|SMALL|SUB|SUP">


My understanding it is for content creators that is for a rss writer. Grr is a rss reader.

I attached examples with special treatment:



and without



The <pre> is precisely to show the content without a modification by the parser.

The xml-configuration snippets can be copy-pasted by the user to check them.

Sergei Golovin <svg>
Sun 06 Feb 2022 04:41:56 AM UTC, comment #6: 

a better example of without special treatment


Sergei Golovin <svg>
Sun 06 Feb 2022 04:31:19 AM UTC, comment #5: 

Added an example of special treatment inside <pre>


Sergei Golovin <svg>
Sun 06 Feb 2022 03:56:15 AM UTC, comment #4: 

added an example of <?xml ?> inside <pre> without special treatment





Sergei Golovin <svg>
Sat 05 Feb 2022 11:55:39 PM UTC, comment #3: 

Looks to work fine at a first test, nice examples.

I wonder why you make a special treatment for comments inside PRE. Now I wonder if they should be displayed or not. Tags are treated.

According to the specs only these tags are excluded in PRE:
<!ENTITY % pre.exclusion "IMG|OBJECT|BIG|SMALL|SUB|SUP">

I am also unsure if
// <?xml.....?>

should have special treatments for PRE, I think not, but I couldn't certify the opposite.

I excluded special treatment for now until we understand it better or have a proof.

Riccardo Mottola <rmottola>
Group administrator
Fri 04 Feb 2022 08:44:19 AM UTC, comment #2: 

Improved the patch by disabling tag attributes handling when inside <pre>...</pre>.

(file #52800)

Sergei Golovin <svg>
Fri 04 Feb 2022 05:32:50 AM UTC, comment #1: 

Please review the attached patch.

A brief description:
- removed extra -[retain] (memory leak);
- changed return values of -[foundOpeningTagName:attributes] and -[foundClosingTagName:attributes] to BOOL because otherwise any unknown tag is eaten by the -[parseHTML]... RedHat' feed has those xml-configuration snippets inside the <pre></pre>... see one of attached screenshots;
- added straightforward handling of <?..?> and <!-- --> because there is no reason to sieve them throw the code chunk seeking attribute name/value pairs;
- I didn't get the comment "// TODO: People use <br/> inside <pre>, parse that!" so left it intact;
- added the missed HTML entity 'apos'

Take a look at the nice ASCII now is visible.


(file #52797,

Sergei Golovin <svg>
Tue 25 Jan 2022 10:08:34 PM UTC, original submission:  

Current implementation ignores any tag inside PRE.
However specification still mandates that entities should be escaped inside PRE.

A, hr, br, tt, code etc are permitted inside.
Yet newline and spaces and formatting are preserved. A little bit more complicated. Perhaps a "pre" status should be inside the parser, recurse but do not chew newlines/spaces when inside PRE..

Riccardo Mottola <rmottola>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #52812:  xml_comments_eaten.png added by svg (104KiB - image/png)
file #52811:  xml_comments_not_eaten.png added by svg (167KiB - image/png)
file #52810:  xml_snippet_without_xml.png added by svg (122KiB - image/png)
file #52798:  Grr_pre_handled.png added by svg (62KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by svg (Updated the item)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-09 svg Attached File- Added pre_handled_without_spec_treatment_Grr_bug_61920.patch, #52826
    2022-02-06 svg Attached File- Added xml_comments_eaten.png, #52812
    2022-02-06 svg Attached File- Added xml_comments_not_eaten.png, #52811
    2022-02-06 svg Attached File- Added xml_snippet_without_xml.png, #52810
    2022-02-06 rmottola StatusNone Ready For Test
    2022-02-04 svg Attached File- Added pre_handled_graciously_Grr_bug_61920.patch, #52800
    2022-02-04 svg Attached File- Added pre_handled_graciously_Grr_bug_61920.patch, #52797
        Attached File- Added Grr_pre_handled.png, #52798
        Attached File- Added Grr_pre_xml_configuration.png, #52799

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code