205236 - No compose mail window, no prefs window, dom inspector if browser.cache.check_doc_frequency set to 1

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Tom]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4b) Gecko/20030511
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4b) Gecko/20030511

In 2003051005 and 2003051105 actions which should invoke the mail composer
window do not create a mail composer window. However, in the javascript debugger
open windows box a new instance of messengercompose.xul does appear each time
the compose button is clicked (but the window doesn't actually get created). WFM
in builds up to and including 2003050905. I tried creating a new profile but
this did not make any difference.

Reproducible: Always

Steps to Reproduce:
1. Open messenger window
2. Click on Compose (or File > New > Message, Ctrl-M, open message and click
Reply, etc.)

Actual Results:  
Aside from a brief burst of CPU activity nothing happens.

Expected Results:  
The mail composer window should open.

I'm using the classic theme. I did not try the modern theme.

Comment 1

[Gilles Durys]

WFM 200305105 trunk (self-made build)
Both modern and classic work.

Comment 2

[Andrew Schultz]

WFM with linux trunk 20030510
do you get any messages in the javascript console?

Comment 3

[Tom]

I get only the following in 20030509 (WFM) and 20030510 (doesn't WFM) when
clicking on the compose button:

Error: redeclaration of const MOZ_HELP_URI
Source File: chrome://help/content/contextHelp.js
Line: 1

Comment 4

[Tom]

FWIW if I copy components/libimglib2.so from my 2003050905 nightly over to my
2003051005 nightly the problem goes away.

Comment 5

[Daniel Kies]

I noticed the same behavior with the 2003051008 win32 build.  On my system, I
have isolated the problem to a single line in my prefs.js file: 

user_pref("browser.cache.check_doc_frequency", 1);

With that line in prefs.js, the 20030510 win32 build (on win98se) would not
launch a message composer window. (However, see the 'Further bit of weirdness'
note below.)

That line gave no problem with the 20030509 win32 build.

The 20030510 build instead seems to ignore the command to launch a Message
Composer window, but it really doesn't: after closing Mozilla, one can see that
there is a Mozilla process running in the Task Manager that must be killed manually.

*A further bit of weirdness: the 20030510 win32 build will fire the message
composer window using the Modern theme, but not with the Classic theme (or any
third party theme I tested).

Comment 6

[(not reading, please use [e-mail] instead)]

accepting.  I see this too.

Comment 7

[(not reading, please use [e-mail] instead)]

a blocker

Comment 8

[(not reading, please use [e-mail] instead)]

going to trying backing this out:

nsHTMLDocument.cpp 	+3/-1 	Bug 204682 - do not allow document.domain to be set
to the empty string. r=heikki, sr=darin, a=blizzard

Comment 9

[(not reading, please use [e-mail] instead)]

ok, it wasn't that checkin.  still looking...

Comment 10

[(not reading, please use [e-mail] instead)]

note, on win2k, after I do ctrl m, I don't see the window, but there is a
"blank" entry in the "Window" menu.

it's like the window is there, but not showing yet.

Comment 11

[(not reading, please use [e-mail] instead)]

bienvenu was right, it was caused by this checkin:

brendan%mozilla.org 	mozilla/caps/src/nsScriptSecurityManager.cpp 	1.199 	2/2  
Fix overbroad getter/setter access check to apply only to scripted
getters/setters; fix wrong object class name in error messages (198660,
r=mstoltz, sr=jst, a=asa

Comment 12

[(not reading, please use [e-mail] instead)]

oops, false alarm?

I was able to do ctrl-m from about:blank, but just once, if I do mozilla
about:blank.

other instances, no luck.

still investigating.

Comment 13

[Tracy Walker [:tracy]]

I did some testing with this as I wasn't seeing it with daily smoketests on the
commercial builds. I installed todays (2003-05-12-04) mozilla build, ran with a
new profile and had no problem with Mail compose windows.  Using a new profile
is a valid workaround for testing.  But, per Seth, leaving this a blocker as
users will want to be able to use their existing profiles.

Comment 14

[(not reading, please use [e-mail] instead)]

I also see this problem only with my existing profile.

Comment 15

[(not reading, please use [e-mail] instead)]

as dan pointed out in comment #5, this fixes it for me:

user_pref("browser.cache.check_doc_frequency", 1);

to

user_pref("browser.cache.check_doc_frequency", 3);  *this is the default*

Comment 16

[(not reading, please use [e-mail] instead)]

in DoChannelLoad() [where we check this cache pref]
we don't seem to have a case for LOAD_FLAGS_NONE.

from OpenWindowJS()

    newDocShell->LoadURI(uriToLoad, loadInfo,
                         nsIWebNavigation::LOAD_FLAGS_NONE, PR_TRUE);

a stack:

nsDocShell::DoChannelLoad(nsIChannel * 0x04d72860, nsIURILoader * 0x00f614e8)
line 5636
nsDocShell::DoURILoad(nsIURI * 0x016b1078, nsIURI * 0x00faff28, nsISupports *
0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 1,
nsIDocShell * * 0x00000000, nsIRequest * * 0x00000000) line 5430 + 38 bytes
nsDocShell::InternalLoad(nsDocShell * const 0x03cb8b68, nsIURI * 0x016b1078,
nsIURI * 0x00faff28, nsISupports * 0x00000000, int 1, const unsigned short *
0x04b282b0, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned
int 1, nsISHEntry * 0x00000000, int 1, nsIDocShell * * 0x00000000, nsIRequest *
* 0x00000000) line 5222 + 51 bytes
nsDocShell::LoadURI(nsDocShell * const 0x03cb8b68, nsIURI * 0x016b1078,
nsIDocShellLoadInfo * 0x04b47fa8, unsigned int 0, int 1) line 734 + 80 bytes
nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x01571e54, nsIDOMWindow *
0x00000000, const char * 0x04159308, const char * 0x04159300, const char *
0x041592dc, int 1, unsigned int 1, long * 0x04d11c58, nsIDOMWindow * *
0x0012b74c) line 785
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x01571e50, nsIDOMWindow *
0x00000000, const char * 0x04159308, const char * 0x04159300, const char *
0x041592dc, nsISupports * 0x03f20170, nsIDOMWindow * * 0x0012b74c) line 457 + 48
bytes
nsMsgComposeService::OpenWindow(const char * 0x00000000, nsIMsgComposeParams *
0x04aaf720) line 303 + 103 bytes
nsMsgComposeService::OpenComposeWindow(nsMsgComposeService * const 0x03c90d40,
const char * 0x00000000, const char * 0x00000000, int 0, int 0, nsIMsgIdentity *
0x03c290d0, nsIMsgWindow * 0x03cb9718) line 495 + 21 bytes
XPTC_InvokeByIndex(nsISupports * 0x03c90d40, unsigned int 3, unsigned int 6,
nsXPTCVariant * 0x0012bc04) line 102
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2023 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x01561020, JSObject * 0x03c59220, unsigned int 6,
long * 0x04cd63ac, long * 0x0012bee4) line 1284 + 14 bytes
js_Invoke(JSContext * 0x01561020, unsigned int 6, unsigned int 0) line 843 + 23
bytes
js_Interpret(JSContext * 0x01561020, long * 0x0012cda4) line 2851 + 15 bytes
js_Invoke(JSContext * 0x01561020, unsigned int 1, unsigned int 2) line 860 + 13
bytes
js_InternalInvoke(JSContext * 0x01561020, JSObject * 0x03a8f8b0, long 61405376,
unsigned int 0, unsigned int 1, long * 0x0012d000, long * 0x0012ced0) line 935 +
20 bytes
JS_CallFunctionValue(JSContext * 0x01561020, JSObject * 0x03a8f8b0, long
61405376, unsigned int 1, long * 0x0012d000, long * 0x0012ced0) line 3527 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x015740e8, void * 0x03a8f8b0,
void * 0x03a8f8c0, unsigned int 1, void * 0x0012d000, int * 0x0012d004, int 0)
line 1079 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x04abd338, nsIDOMEvent
* 0x03ee3388) line 181 + 77 bytes
nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver * 0x04c87598,
nsIDOMEvent * 0x03ee3388) line 449
nsXBLWindowHandler::WalkHandlersInternal(nsIDOMEvent * 0x03ee3388, nsIAtom *
0x00ee4db0, nsXBLPrototypeHandler * 0x0382e430) line 313 + 24 bytes
nsXBLWindowKeyHandler::WalkHandlers(nsXBLWindowKeyHandler * const 0x03406938,
nsIDOMEvent * 0x03ee3388, nsIAtom * 0x00ee4db0) line 164
nsXBLWindowKeyHandler::KeyPress(nsXBLWindowKeyHandler * const 0x03406938,
nsIDOMEvent * 0x03ee3388) line 180
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x0162c6d0,
nsIPresContext * 0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0,
nsIDOMEventTarget * 0x0169cc14, unsigned int 514, nsEventStatus * 0x0012f5ac)
line 1631 + 41 bytes
nsXULDocument::HandleDOMEvent(nsXULDocument * const 0x0169cbe0, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 514,
nsEventStatus * 0x0012f5ac) line 1280
nsXULElement::HandleDOMEvent(nsXULElement * const 0x016ff928, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 514,
nsEventStatus * 0x0012f5ac) line 3325 + 46 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0344fa78, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 514,
nsEventStatus * 0x0012f5ac) line 3319 + 60 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0344af58, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 514,
nsEventStatus * 0x0012f5ac) line 3319 + 60 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0344b3e0, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 514,
nsEventStatus * 0x0012f5ac) line 3319 + 60 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0344b5a8, nsIPresContext *
0x016b7af0, nsEvent * 0x0012f780, nsIDOMEvent * * 0x0012f3b0, unsigned int 519,
nsEventStatus * 0x0012f5ac) line 3319 + 60 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f780, nsIView * 0x016e3938,
unsigned int 1, nsEventStatus * 0x0012f5ac) line 6417 + 55 bytes
PresShell::HandleEvent(PresShell * const 0x016e3e2c, nsIView * 0x016e3938,
nsGUIEvent * 0x0012f780, nsEventStatus * 0x0012f5ac, int 1, int & 1) line 6291 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x016e3938, nsGUIEvent * 0x0012f780, int 0)
line 2246
nsView::HandleEvent(nsViewManager * 0x016b4678, nsGUIEvent * 0x0012f780, int 0)
line 308
nsViewManager::DispatchEvent(nsViewManager * const 0x016b4678, nsGUIEvent *
0x0012f780, nsEventStatus * 0x0012f6f0) line 2022 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f780) line 82
nsWindow::DispatchEvent(nsWindow * const 0x016e39d4, nsGUIEvent * 0x0012f780,
nsEventStatus & nsEventStatus_eIgnore) line 1054 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f780) line 1075
nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 109, unsigned int 0,
long 0) line 2931 + 15 bytes
nsWindow::OnChar(unsigned int 13, unsigned int 0, unsigned char 0) line 3118
nsWindow::ProcessMessage(unsigned int 258, unsigned int 13, long 3276801, long *
0x0012fc34) line 3827 + 41 bytes
nsWindow::WindowProc(HWND__ * 0x0025016a, unsigned int 258, unsigned int 13,
long 3276801) line 1348 + 27 bytes
USER32! 77e3a244()
USER32! 77e145e5()
USER32! 77e1a792()
nsAppShellService::Run(nsAppShellService * const 0x015702c8) line 479
main1(int 2, char * * 0x00270070, nsISupports * 0x00f9be18) line 1268 + 32 bytes
main(int 2, char * * 0x00270070) line 1647 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77ea847c()

Comment 17

[(not reading, please use [e-mail] instead)]

am I missing something?

the default is 3, but the code, no case for 3 (or default)

                GetIntPref("browser.cache.check_doc_frequency",
                            &prefSetting))) {
                switch (prefSetting) {
                case 0:
                    loadFlags |= nsIRequest::VALIDATE_ONCE_PER_SESSION;
                    break;
                case 1:
                    loadFlags |= nsIRequest::VALIDATE_ALWAYS;
                    break;
                case 2:
                    loadFlags |= nsIRequest::VALIDATE_NEVER;
                    break;

Comment 18

[(not reading, please use [e-mail] instead)]

it seems odd to me that for LOAD_NONE (assuming this is only for chrome)
we heed that cache pref.

a fix:

Index: base/nsDocShell.cpp
===================================================================
RCS file: /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v
retrieving revision 1.544
diff -u -w -r1.544 nsDocShell.cpp
--- base/nsDocShell.cpp 9 May 2003 18:27:47 -0000       1.544
+++ base/nsDocShell.cpp 12 May 2003 16:27:20 -0000
@@ -5608,6 +5608,7 @@
     // Load attributes depend on load type...
     switch (mLoadType) {
     case LOAD_HISTORY:
+    case LOAD_FLAGS_NONE:
         loadFlags |= nsIRequest::VALIDATE_NEVER;
         break;

Comment 19

[(not reading, please use [e-mail] instead)]

oops, that's no fix, we come in with LOAD_NORMAL

fyi, the channel is nsCachedChromeChannel, so this looks like the xul cache, so
maybe this isn't the problem.

bienvenu says he's going to try to back out jst.

Comment 20

[Tom]

If I have set:

user_pref("browser.cache.check_doc_frequency", 1);

then not only does the compose window not appear but the prefs window (bug
205124) and the DOM inspector window (bug 205223) also don't appear. Setting:

user_pref("browser.cache.check_doc_frequency", 3);

fixes all three problems.

Comment 21

[David :Bienvenu]

backing out these jst checkins:

cvs update -j3.626 -j3.625 mozilla/layout/html/base/src/nsPresShell.cpp
cvs update -j1.11 -j1.10 mozilla/content/base/src/nsImageLoadingContent.cpp
cvs update -j1.56 -j1.55 mozilla/content/base/src/Makefile.in
cvs update -j1.44 -j1.43 mozilla/modules/libpr0n/src/imgRequestProxy.cpp

seems to fix it for me. I'll investigate a little more since is surprising to me.

Comment 22

[(not reading, please use [e-mail] instead)]

so we have a workaround (change the pref) and david said backing out jst's fix
for bug #93015 fixed it.

setting as blocking 1.4 final.  downgrading from smoketest blocker.

Comment 23

[(not reading, please use [e-mail] instead)]

*** Bug 205124 has been marked as a duplicate of this bug. ***

Comment 24

[Johnny Stenback (:jst)]

This is really weird... I wonder if the imgRequestProxy change along caused
these problems, could someone verify that? If so, I think there's currently code
elsewere that relies on the imgRequestProxy code being broken, or at least
that's what it seems like. I'll be investigating this closer a bit later today...

Comment 25

[David :Bienvenu]

yes, backing out just the imgRequestProxy change fixes this problem.

Comment 26

[james davis]

*** Bug 205272 has been marked as a duplicate of this bug. ***

Comment 27

[Johnny Stenback (:jst)]

Attachment: No good...

Comment 28

[Johnny Stenback (:jst)]

Comment on attachment 123065 [details] [diff] [review]
No good...

Never mind, better patch coming up.

Comment 29

[Johnny Stenback (:jst)]

Attachment: Make sure the imgCacheValidator notifies it's proxies once the data is loaded.

This should be better, I think.

Comment 30

[Johnny Stenback (:jst)]

Comment on attachment 123067 [details] [diff] [review]
Make sure the imgCacheValidator notifies it's proxies once the data is loaded.

Not yet... Pavlov and I will see tomorrow if we can figure out a better way to
fix this.

Comment 31

[Johnny Stenback (:jst)]

Marking FIXED.

Comment 32

[Patrick]

*** Bug 205496 has been marked as a duplicate of this bug. ***

Comment 33

[james davis]

*** Bug 205788 has been marked as a duplicate of this bug. ***

Comment 34

[Tom]

Builds Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4b) Gecko/2003051305,
2003051405 and 2003051505 wfm with browser.cache.check_doc_frequency set to 1.

Comment 35

[esther]

Using trunk build 20030521 on winxp, macosx and linux and changing my prefs.js
file to set browser.cache.check_doc_frequency   to 1 this is fixed. Verified.