Closed Bug 1107113 Opened 9 years ago Closed 5 years ago

WYCIWYG is caching scripts, breaking pages

Categories

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

31 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: JasonETupper, Unassigned)

References

Details

User-agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0

My site is running some out of band scripts that use document.write, which modify the style of the page. Firefox's WYCIWYG is caching and running these and creating a bad UX experience. We would like to have a way of telling firefox to not cache these document.writes

Repro steps:

1) Create a .html file with the following:

<!DOCTYPE html>
<!-- Command to be run in the console -->
<!-- document.getElementById("frame").contentDocument.write('<body><script>top.document.body.style.backgroundColor = "#AAAAAA";</script></body>');
document.getElementById("frame").contentDocument.close(); -->
<html>
<head>
</head>
<body>
                <div id="top">
                                <iframe
                                width="300"
                                height="300"
                                name="frame"
                                id="frame"
                                />
                </div>
</body>
</html>

2) Open the .html file in firefox
3) Open firebug (The default firefox console cannot follow these repro steps)
4) In the console, run "document.getElementById("frame").contentDocument.write('<body><script>top.document.body.style.backgroundColor = "#AAAAAA";</script></body>');
document.getElementById("frame").contentDocument.close();"
5) Refresh the page
6) The background is still #AAAAAA
7) Go to about:cache
8) Check the disk cache for a "wyciwyg://" cache item
9) Note the script that was document.written to the page is now cached
Component: Bookmarks & History → Networking: Cache
Product: Firefox → Core
This belongs to DOM.
Component: Networking: Cache → DOM: Core & HTML
Priority: -- → P3

WYCIWYG is being removed.

Depends on: 1489308

Yes, at this point the reload will do something completely nuts, probably (reload the parent page in the subframe), but that's what the spec kinda says...

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.