From f8d7c8b06db18158cccbff0bf99472d9360daabb Mon Sep 17 00:00:00 2001 From: "kaie%netscape.com" Date: Sat, 19 Apr 2003 14:04:59 +0000 Subject: [PATCH] b=155760 Changing content by JavaScript document.write => open insecure lock icon r=javi sr=peterv --- .../manager/boot/src/nsSecureBrowserUIImpl.cpp | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/security/manager/boot/src/nsSecureBrowserUIImpl.cpp b/security/manager/boot/src/nsSecureBrowserUIImpl.cpp index 2af46bd677a8..731fe346782b 100644 --- a/security/manager/boot/src/nsSecureBrowserUIImpl.cpp +++ b/security/manager/boot/src/nsSecureBrowserUIImpl.cpp @@ -539,6 +539,22 @@ nsSecureBrowserUIImpl::OnStateChange(nsIWebProgress* aWebProgress, // If a document loading gets triggered, we will see more events. return NS_OK; } + + if (NS_SUCCEEDED(uri->SchemeIs("wyciwyg", &vs)) && vs) + { + // We ignore everything caused by wycywig == document.write/writeln + // and assume the same security status + // Unfortunately, this results in different lock icon states + // when using "back". + // 1) goto secure page => secure lock icon + // 2) trigger document.writeln() => still secure lock icon + // (because we not change lock icon) + // 3) go to a different insecure page => insecure lock icon + // 4) press "back" button => still insecure lock icon + // To fix this, we could try to remember the security state in the + // wyciwyg channel object. + return NS_OK; + } } }