Closed Bug 287990 Opened 19 years ago Closed 19 years ago

<plaintext></plaintext>doesn't works well in Mozilla 1.8b1 as before

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: njnu1115, Assigned: mrbkap)

References

Details

Attachments

(3 files)

reporter´s testcase
322 bytes, text/html
Details
screenshot of testcase in DOM Inspector
8.08 KB, image/png
Details
brings back plaintext
18.52 KB, patch
jst
: review+
dbaron
: superreview+
shaver
: approval1.8b3+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217

<plaintext></plaintext>doesn't works well in Mozilla 1.8b1 as before
e.g:I write a html:

<html><head><title></title></head>		
		<body bgcolor="#eeeeee">	
<plaintext>
aaaaaaaaaaa
aaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaa
</plaintext></body></html>

then, in Mozilla 1.8b1, the text displayed on brower is continuous, without wrap.
but on the previous edition of Mozilla and FireFox, it's displayed with wrap.


Reproducible: Always

Steps to Reproduce:
1.Write a html 
===============================
<plaintext></plaintext>doesn't works well in Mozilla 1.8b1 as before
e.g:I write a html:

<html><head><title></title></head>		
		<body bgcolor="#eeeeee">	
<plaintext>
aaaaaaaaaaa
aaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaa
</plaintext></body></html>
===============================
2.use Mozilla 1.8 to open it
3.use FireFox 1.0 to open it

Actual Results:  
in Mozilla 1.8b:
it shows :
"aaaaaaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa"

in FireFox
it shows:
"aaaaaaaaaaa 
aaaaaaaaaaaaa 
aaaaaaaaaaaaaaaaaa"

Expected Results:  
Both show 
"aaaaaaaaaaa 
aaaaaaaaaaaaa 
aaaaaaaaaaaaaaaaaa"

I know that <plaintext> is not a w3c standerd, but I hope that it could be remained.
<plaintext> has been obsolete since HTML 1.0 and is not supported by Mozilla.
Why not to use <pre> instead?

See more on this issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=38176
Attached file reporter´s testcase — 

    
    

    
  


  
browser view replaces newlines with spaces, the Object-Dom Node view respects
the newlines.

    
    

    
  
Bugzilla Bug 88987 should not support PLAINTEXT

was fixed 2004-10-18 12:57 PST

Also see discussion in 
Bug 269116 There shouldn't be </plaintext> tag, <plaintext> should be effective
up to EOF
Assignee: composer → parser
URL: http://it's a internal website, so I ...
Component: Composer → HTML: Parser
Depends on: 88987
Product: Mozilla Application Suite → Core
QA Contact: mrbkap
Version: unspecified → Trunk

    
    

    
  
See also bug 269116. I'm going to reimplement <plaintext> (with no end tag this
time!) and hopefully we'll come to a consensus about whether or not to check in
such a patch.
Assignee: parser → mrbkap

    
    

    
  
IMHO we shouldn't support <plaintext>. At the very least, to support this
obsolete (and dubious) tag, we would need evidence that it is used on important
pages. A few URIs demonstrating big sites that use this would help.

The only pages I could find that used <plaintext> were pages on Geocities trying
to disable the server-attached scripts that pop up adverts. A valiant goal, I'm
sure, but there are better ways to do this than supporting <plaintext>...
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  


  
This patch brings back <plaintext>. It's handled specially in a couple of
places, and I needed to bring back nsITokenizer::CopyState() to handle
document.write("<plaintext>") correctly. It's slightly evil to play with the
HTML tokenizer's mFlags like this, but it's the easiest (and probably the
cleanest way to implement it).

I used parts of the patches in bug 88987 (especially the content/ and layout/
stuff).

In my opinion, we should support <plaintext> until the PERL library is updated
to not support <plaintext> (see bug 269116 comment 0). Other opinions (on the
patch and otherwise are welcome).

        Attachment #179355 -
        Flags: superreview?(bzbarsky)

        Attachment #179355 -
        Flags: review?(jst)

    
  
Status: NEW → ASSIGNED

    
    

    
  
I'm not likely to be able to get to this in time for the freeze on Tuesday... :(

    
  

        Attachment #179355 -
        Flags: superreview?(bzbarsky) → superreview?(dbaron)

    
    

    
  
Comment on attachment 179355 [details] [diff] [review]
brings back plaintext

r=jst

        Attachment #179355 -
        Flags: review?(jst) → review+

    
    

    
  
jst: I still maintain we should not implement this. What is the use case for
supporting this?

    
    

    
  
Comment on attachment 179355 [details] [diff] [review]
brings back plaintext

>-// Currently there are 107 HTML tags. eHTMLTag_text = 109.
>+// Currently there are 108 HTML tags. eHTMLTag_text = 110.

Either drop this comment or reword it so that it doesn't have a number in it. 
That's what the constant is for.

> #define NS_HTML_TAG_MAX PRInt32(eHTMLTag_text - 1)

sr=dbaron, although it seems like we ought to be able to use something more
like the CDATA-ish parsing that we use for style and script to do this actually
right, and with less code.

        Attachment #179355 -
        Flags: superreview?(dbaron) → superreview+

    
    

    
  
This shouldn't go in without a clear reason.

Opera did some deep analysis of tag use on the Web and <plaintext> was one of
the least used tags found, with zero real use cases, and the remaining cases
being attempts to violate Geocities' terms of service.

What is the use case for checking this in? There is a cost, what's the benefit?

    
  

        Attachment #179355 -
        Flags: approval1.8b3?

    
    

    
  
Comment on attachment 179355 [details] [diff] [review]
brings back plaintext

a=shaver

        Attachment #179355 -
        Flags: approval1.8b3? → approval1.8b3+

    
    

    
  
Fix checked in. When the HTML::Parser folks remove <plaintext> support, we
should too.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
(In reply to comment #12)
> Opera did some deep analysis of tag use on the Web and <plaintext> was one of
> the least used tags found, with zero real use cases, and the remaining cases
> being attempts to violate Geocities' terms of service.
> 
> What is the use case for checking this in? There is a cost, what's the benefit?

Simple explanation. It can be exploited. Not the text wrapping (un)feature of
course, is vulnerable, but support for the end tag '</plaintext>'. Blake
reimplemented <plaintext> to mimic historical behaviour which is to ignore
'</plaintext>' and span up to the end of document. That's nice and compatible
with other browsers (and standalone html parsers).

    
    

    
  
But why support it _at all_?

This is ridiculous. We're adding obsolete features that aren't used and are
merely complicated and bloating the code.

    
    

    
  
See(In reply to comment #16)
> But why support it _at all_?

See bug 269116 comment 0.

    
  
Blocks: 269116

    
  
Blocks: xss

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: