Closed
Bug 285741
Opened 19 years ago
Closed 19 years ago
Scripts and plugins function in composer documents
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
People
(Reporter: neil, Assigned: jst)
References
Details
(Keywords: dataloss)
Attachments
(1 file)
2.40 KB,
patch
|
Brade
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
Presumably as a result of bug 209020 and friends scripts and plugins are now active in Composer documents. When the editor element is created the docShell's allowJavascript is set to false. However when the document (event about:blank) loads the allowJavascript value is set to true and is never reset to false. Some Insert/HTML examples: <applet> (without Java) will trigger the null plugin. <script>alert('Boo!')</script> of course... <script>document.write('Boo!')</script> might even crash. This also applies to script in the source of the page.
Comment 1•19 years ago
|
||
Hmm... Odd. We do call SetAllowJavascript(PR_FALSE), right? I wonder why that doesn't work. Do we restore the old value (in editor) when the document is created?
Reporter | ||
Comment 2•19 years ago
|
||
Bug 209020 made TearDownEditor reset allowJavascript.
Comment 3•19 years ago
|
||
Sure, but if editing is torn down, why are we still able to edit the document?
Comment 4•19 years ago
|
||
Hmmm.... I see the value being reset to false in onload, but we're setting it on the wrong docshell (the docshell we tore down on is a kid of the docshell we catch onload for, looks like). And in any case, during document load javascript is active. This is something we really need to fix for 1.8/1.1/whatever...
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
OS: Windows 2000 → All
Hardware: PC → All
Reporter | ||
Comment 5•19 years ago
|
||
I don't know, I only had set a breakpoint at nsDocShell::SetAllowJavascript Note that there are three docShells; the chrome docshell, the HTML view and the source text view; the latter does have its javascript/plugins disabled.
Assignee | ||
Comment 6•19 years ago
|
||
Attachment #177872 -
Flags: superreview?(bzbarsky)
Attachment #177872 -
Flags: review?(bzbarsky)
Comment 7•19 years ago
|
||
Comment on attachment 177872 [details] [diff] [review] Only ever restore js/plugin etc state for midas. moa/r=brade (assuming you've tested Composer, Mail Compose and Midas) bonus points if you tested my sidebar ;-)
Attachment #177872 -
Flags: review?(bzbarsky) → review+
Comment 8•19 years ago
|
||
Comment on attachment 177872 [details] [diff] [review] Only ever restore js/plugin etc state for midas. sr=bzbarsky.
Attachment #177872 -
Flags: superreview?(bzbarsky) → superreview+
Comment 9•19 years ago
|
||
If someone could check this in before the next nightly, I could test it over the weekend for Mail/News HTML compose, and a possible fix for bug #285343 as well
Assignee | ||
Comment 10•19 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 11•19 years ago
|
||
This seemed to fix problems with HTML replies to messages with JS or plugins. Thanks jst Bug #285343 fixed for WinXP not yet tested for Mac
Reporter | ||
Comment 12•19 years ago
|
||
*** Bug 285343 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
You need to log in
before you can comment on or make changes to this bug.
Description
•