Closed Bug 287990 Opened 20 years ago Closed 20 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: 20 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: 301375
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: