Closed
Bug 396001
Opened 18 years ago
Closed 8 years ago
On text/plain page, document.body.innerHTML='' acts strange.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: BijuMailList, Unassigned)
Details
Attachments
(1 file)
|
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
|
||
Updated•18 years ago
|
Summary: on text page document.body.innerHTML='' acts strange. → On text/plain page, document.body.innerHTML='' acts strange.
|
||
Comment 1•18 years ago
|
||
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
|
||
Comment 2•18 years ago
|
||
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).
|
|
||
Comment 3•18 years ago
|
||
|
|
||
Comment 4•18 years ago
|
||
> 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.
|
|
||
Comment 5•18 years ago
|
||
Note that if the blacklisting were in CreateContextualFragment it would be trivial to limit to non-HTML HTMLDocuments.
|
|
||
Comment 6•18 years ago
|
||
Attachment #281031 -
Flags: review?(bzbarsky) → review-
|
|
||
Updated•16 years ago
|
Assignee: mrbkap → nobody
|
||
Comment 7•15 years ago
|
||
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
|
Assignee | |
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
|
||
Comment 8•8 years ago
|
||
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: 8 years ago
Resolution: --- → WORKSFORME
|
|
Assignee | |
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•