Closed Bug 396001 Opened 17 years ago Closed 7 years ago

On text/plain page, document.body.innerHTML='' acts strange.

Categories

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

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: BijuMailList, Unassigned)

Details

Attachments

(1 file)

So like this
1.29 KB, patch
bzbarsky
: review-
Details | Diff | Splinter Review 
javascript:document.body.innerHTML='';void(0);

Above bookmarklet can be used to clear content of the page.
It works fine on an HTML page.

But on a page with mime-type:text/plain
It leaves "<HTML><BODY>"


Steps:
1. copy bookmarklet 
javascript:document.body.innerHTML='';void(0);

2. goto 
http://en.wikipedia.org/robots.txt

3. paste bookmarklet on location bar

4. press enter key, you see "<HTML><BODY>"

5. go to an html page

6. paste bookmarklet on location bar

7. press enter key, you see blank page
Summary: on text page document.body.innerHTML='' acts strange. → On text/plain page, document.body.innerHTML='' acts strange.
createContextualFragment assumes it's actually going to be parsed as markup.  We should probably make innerHTML throw in documents that are nsHTMLDocument but not text/html.
Component: DOM → DOM: Mozilla Extensions
Perhaps we should just blacklist text/plain instead of whitelisting both text/html and */*xml* (or however you describe the millions of XHTML content types).
Attached patch So like this — — Splinter Review 
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED

        Attachment #281031 -
        Flags: review?(bzbarsky)

    
    

    
  
> Perhaps we should just blacklist text/plain

And also all types handled like text/plain:

 91   "text/plain",
 92   "text/css",
 93   "text/javascript",
 94   "text/ecmascript",
 95   "application/javascript",
 96   "application/ecmascript",
 97   "application/x-javascript",

And also all image types and all plug-in types and anything else that creates a synthetic HTML document.

I really do think what I suggested in comment 1 is the way to go.

    
    

    
  
Note that if the blacklisting were in CreateContextualFragment it would be trivial to limit to non-HTML HTMLDocuments.

    
    

    
  
Comment on attachment 281031 [details] [diff] [review]
So like this

See comment 4

        Attachment #281031 -
        Flags: review?(bzbarsky) → review-
Assignee: mrbkap → nobody

    
    

    
  
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Component: DOM: Mozilla Extensions → DOM

    
    

    
  
This seems to work fine these days. And I don't think we need to change how the API works based on the document content type.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: