Closed Bug 73409 Opened 23 years ago Closed 20 years ago

document.open("text/plain") creates an html document instead of plain text.

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: kjrogers, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

An HTML file that attempts to open a plain text document in another window.
1.37 KB, text/html
Details
Patch updated to that comment
10.14 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109
BuildID:    2001010901

Using javascript I opened a new window and used document.open to create a plain
text document. The resultant document was html. This was verified by using view
source.

Reproducible: Always
Steps to Reproduce:
1. Open the attachment "open.html"
2. Select Open Window (This opens an empty window)
3. Select Display Doc Properties
4. Select "View/Source" in the operned window


Actual Results:  The lines of text displayed in the new window do not start on
new lines.
This is because the text is being interpreted as HTML rather than plain text.

When the source is viewed, it contains <html><body></body></html>, ie an empty
html document.

Expected Results:  If the same test is performed with IE, each line of text is
displayed on a separated line.

When view source is selected, the lines of text are displayed.
-> DOM 0
Assignee: anthonyd → jst
Component: DOM to Text Conversion → DOM Level 0
QA Contact: sujay → desale
What exactly does this break?
Target Milestone: --- → Future
Confirming, since this works in NS 4.7 and IE 5.5 but not in Mozilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
jst: You asked what this bug breaks.

It breaks compatibility with Netscape 3 and 4 and with IE 4, 5, 5.5, and 6 beta.  

I don't know if this counts, but...
It also breaks an example in my book JavaScript: The Definitive Guide, in which
I output debugging messages to "console" window that is created to display a
text document.  There are hundreds of thousands of programmers out there who
might try to run that code in Mozilla.  

In some situations, it is nice to be able to use newlines and tab characters for
formatting.  It was a cool feature when Netscape 3 introduced it.  I think it
would be cool to support in Mozilla.

Note, however, that the DOM standard does not require it.
I correct the summary to 
  document.open("text/plain")
instead of the wrong
  document.open("plain/text")
The test case has it right.
Here is the NN4 doc about document.open
  http://developer.netscape.com/docs/manuals/js/client/jsref/document.htm#1196317
It would be nice and logical if Mozilla also allowed
  document.open('text/xml')
Summary: document.open("plain/text") creates an html document instead of plain text. → document.open("text/plain") creates an html document instead of plain text.
Martin, I wouldn't excpect document.open('text/xml') ever being supported in
mozilla, supporting that would require "morphing" |document| from being a
HTMLDocument object (or whatever document type) into a XMLDocument object. Doing
that is non-trivial and far from worth it IMO.
Doesn't document.open always create a completely new document, even if you give 
the mimetype as text/html?
No, document.open() never returns a new document in mozilla, not sure what 4x/IE
does tho. I know 4x didn't use to do it either, but that might have changed at
some point in 4x.
Severity = MEDIUM [(1)No Crash, (2)Severe functional failure, (3)No Cosmetic 
failure]
Visibility = HIGH [(1)Reporter is author of book "JavaScript: The Definitive 
Guide" & claims that example in his book do not work because of this bug which 
gives this bug highest visibility because hundreds of people will try those 
examples on our browser. (2)Gets one point of compatibility with other browsers 
since it works on all other browsers. (3)Gets one more point on compliance with 
adopted techonology, that is JS] 

Priority = Visibility * Severity

Priority = p2

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.
Keywords: qawanted
Priority: -- → P2
Confirmed for build 2002100208 / Linux - in fact I wanted to file a new bug, but
stumbled across this bug instead.


Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Ran into this one myself independently; was going to file a new bug.
Linux, 2002100315.

Doesn't just happen with text/plain; seems to ignore ANY content type
completely, and produce an html document.

Wanted to create a text/plain document containing applet output (via
liveconnect) that the user can then print or save using standard browser
features. This is attractive because it works without needing a signed applet
and special privs, just mayscript, and I don't need to invent a file dialog that
duplicates the one in the browser.  Works nicely in NS4.

Would also very much like to use document.open("","application/postscript") and
have the applet produce a postscript diagram, letting the browser do all the
work of finding and launching the postscript viewer.  This *almost* works in NS4
(starts doing the right thing but hangs).  Moz just thinks I meant HTML. :(
Please ignore the extra "", in my last example. brain/fingers impedance mismatch...
Chapman: Have you tried using a data:application/postscript URL?  document.open
is usually used for HTML and sometimes text, both of which browsers can render
incrementally, so I'm not surprised that Netscape 4 has trouble with
document.open("application/postscript").  (Does that work in any browsers?)
No, hadn't tried; in fact hadn't heard of rfc2397 until just now. It doesn't
look like a very general solution, considering the inherent length limits, and
the quoting requirements would be sort of ugly.

I don't think it would be a bad thing if document.open() actually supported
whatever content types the browser can be configured to handle--since the
documentation doesn't indicate any intention to restrict the set.

But at the *very* least, if document.open is used usually for html and text, it
would be good if text worked. :)
Keywords: qawanted → testcase
Attached patch Fix (obsolete) — — Splinter Review 

    
    

    
  
Comment on attachment 148032 [details] [diff] [review]
Fix

jst, what do you think?

If we don't like the idea of write/writeln throwing on unknown types, we could
just assume text/html unless told text/plain (though there are some other types
this could support -- text/css, application/javascript, etc).

The expat driver change is to fix a crash on window close when opening a
document as text/xml.

        Attachment #148032 -
        Flags: superreview?(jst)

        Attachment #148032 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 148032 [details] [diff] [review]
Fix

Very nice!

I'd say we'd probably be better off special casing text/plain here and treating
everything else as text/html (like we now do).

r+sr=jst with that change.

        Attachment #148032 -
        Flags: superreview?(jst)

        Attachment #148032 -
        Flags: superreview+

        Attachment #148032 -
        Flags: review?(jst)

        Attachment #148032 -
        Flags: review+

    
    

    
  


  

        Attachment #148032 -
        Attachment is obsolete: true

    
    

    
  
Special case text/plain and treat everything else as text/html no matter how
carefully it says it isn't??  Why, that's fixing one special case of the problem
while enshrining the problem itself in policy!  I'd suggest at the very least
treating text/plain as text/plain, text/html as text/html, and providing some
frobbable preference for how some unknown type ought to be rendered.  text/plain
is a good default for that preference, because the user can at least see what is
being presented without alteration.  Treating non-html as html introduces line
wrapping and information loss surrounding sgml special characters.

Even the default with some obscure preference would just be a way of limping
along until it's possible to do the right thing with an unrecognized type, as in
#11521 / #57342 .

    
    

    
  
Chapman Flack, we have the following situation:

1)  In Mozilla different types of documents have different document objects
    (this was not the case in Netscape 4).  See comment 7.
2)  In Mozilla document.write works on the parser level, not on the byte stream
    level (this was not the case in netscape 4, where document.write actually
    changed the code stored in the cache entry).  This means bug 11521 and bug
    57342 are not relevant here -- the data being written never makes it to the
    content dispatch level.
3)  People expect to use document.open() followed by document.write() on the
    same exact object on which they called open().

Therefore, given constraint #3 and item #2, the only types we could possibly
support for document.open/document.write without completely rearchiteching Gecko
around this misfeature are the following:

  text/plain
  text/css
  text/html
  application/x-javascript
  text/javascript

Now you argue that data being written with an unsupported type should be treated
as text/plain.  That's doable, and maybe worth doing _if_ this ever happens. 
Does it?  I have to admit to never having seen an actual page that uses this stuff.

    
    

    
  
I should add application/xhtml+xml to that list, possibly, though I fully expect
the XML parser to throw validity errors if little bits of XML are fed to it via
the apis document.write uses.

    
    

    
  
Well, ok, I understand if bug 11521 / bug 57342 are not easily applicable at
present because of architectural limitations.  So one does something simpler as
a limp-along for the time being.  And maybe the architecture never gets fixed
and they never become applicable, but at least the point's made that in an ideal
world they would be applicable.

So in the limp-along world, is the question whether to treat things that are
neither text/plain nor text/html as text/plain or as text/html?  Out of those
two choices, I think text/plain is best.  I think if a document claims not to be
html, treating it as html is less safe than treating it as plain.  The effects
of trying to render it as html will just disguise the document and make it
harder for the user to see what it might really be.

    
    

    
  
s/architectural limitations/tradeoffs to make XML work better at the expense of
legacy cruft/ and sure.  ;)

I buy the rest of it; made that change.
Assignee: general → bzbarsky

    
    

    
  
Fixed for 1.8a2.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
The other day, I just tried to display HTML source via open new window with
text/plain.
I was astonished Firebird rendering HTML, but not displaying source. IE has no
problem.
This is very simple JS feature. I wish the fix applied to 1.7.

    
    

    
  
I'm pretty opposed to landing this on the 1.7 branch without a lot of
preliminary testing (which I doubt it'll get, myself).

And I hope the "I wish" part is "I wish that the fix had been applied" not an
order to apply the fix.

    
    

    
  
(In reply to comment #5)
> jst: You asked what this bug breaks.
> 
> It breaks compatibility with Netscape 3 and 4 and with IE 4, 5, 5.5, and 6 beta.  
> 
> I don't know if this counts, but...
> It also breaks an example in my book JavaScript: The Definitive Guide, in which
> I output debugging messages to "console" window that is created to display a
> text document.  There are hundreds of thousands of programmers out there who
> might try to run that code in Mozilla. [...]

I recently have found out that the W3C DOM Level 2 HTML's HTMLDocument interface
does have an open() method and that this method does not take any arguments:

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-72161170>

If the Gecko DOM should at least partly implement the HTMLDocument interface
with the `document' property (and I think that this is the case, take
document.getElementById() for example), allowing an argument for document.open()
that changes the behavior of that method will break this (quasi-)standard.  If
adhering to the (quasi-)standard breaks compatibility with proprietary code, so
be it.  It would help to focus the authors of such code on the fact that
something has changed in browser scripting in the meanwhile, to update
"Netscape" substring and document.layers checking, for example.

As for you book, David, I have never read it, it is recommended in the
comp.lang.javascript FAQ (<http://jibbering.com/faq/>, yet some serious errors
in it have been uncovered during discussions in this group and IIRC those
examples always used proprietary scripting methods (and some invalid HTML).


PointedEars
Depends on: 313217

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: