Click a link from some external application Actual result: nothnig happends Expected result: mozilla opens the URL It worked in 20030125xx, but does not in 1.3b and 2003021208.

Confirming (sort of). I use Pegasus as my email program. At the start of every session, clicking on a hyperlink in an email does nothing. I have to go into my settings and point it to the browser (even though it's already there with the correct path and everything) at which point it works once more. Next session (although the path to the browser has not changed) it does nothing again. I would normally say that this is a problem with Pegasus, not Mozilla, except for this bug and other people seeing the same thing. Also, at the same time that Mozilla stopped loading without my intervention as per the above, it started loading external links into the same browser/tab, overwriting all content. I know that there's a bug on this but up until the URLs stopped loading, it would always (for me) launch a separate browser window. So something happened to change both of these things at the same time.

Oh. I'm also using XP, and build 2003021208.

please read the component description to select a better component...

Yes, and doubleclicking URL shortcut icons does not bring up Mozilla, either.

As this is highly user-visible breakage, I nominate it for 1.3 final. Can anyone figure out when this stopped working? Was it working in 1.3 alpha?

From my commnet on mozillazine forum: Tried out builds from end of january and they did not even started for me... (I deleted the mozilla.org directory, but does not helped). After installed 2003020508 - All was OK. Went thrue all builds since then and the result is: now it works again for me in 2003021308... Dunno what it was. I remember I had a 2003012508 build, then I installed a 2003021008 (clean) and had the problem. Maybe there were some bad installation or some of the builds had caused this?

I can tell you that it was working in 2003020708, it was working in the 1.3b release, and it wasn't working in 2003021308. However, reverting to either of the previous two builds does *not* fix it. I have tried: Uninstall/reinstall Uninstall/delete GRE/reinstall Uninstall/delete GRE/run RegClean/reinstall Uninstall/delete GRE/run RegClean/delete old profile/reinstall/create new profile going back and forth between these various builds. I've also tried checking the file assosiation options. I will try 2002020508 to see if that helps. Attempting to open an HTML file from email fails. Attempting to open from a shortcut fails. Attempting to open from within a text editor fails. However, using the RUN command from the start menu will succeed. When Mozilla is removed, all tests work fine using IE6. Running Windows 2000/SP3.

FWIW, I believe it stopped working around the 2/8 builds.

I have the same problem with my Windows 2000 SP3. It's impossible to open a HTML file(and any other, XHTML, XML, ...) while double clicking. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030213

Additional info: 2002020508 does not solve the problem for me. I've gone back to 1.3a, which works.

I asked this in bug 192286 already, but anyone who sees the problem, please try: "does it make any difference if you turn on supportDDEExec, start and close Mozilla and turn it off again? If it doesn't work, could you export HKEY_CLASSES_ROOT\http key and its subkeys using regedit and attach the file to this bug?"

It is my HKEY_CLASSES_ROOT\http key It is in a state where launching URL from outside Mozilla does NOT work. After playing with supportDDEExec, I reached a state where launching URL works with supportDDEExec true, but files opened from explorer don't work. I will send the key for html a moment later.

Sébastien, I suppose you really have Mozilla installed under c:\program files\mozilla and not c:\program files\mozilla.org\mozilla, right?

Yes, it is installed in C:\program files\mozilla

Does it work if you run "mozilla.exe http://something" when Mozilla is already running?

Unfortunatly, I was testing at work, and it is now the week-end, so I can't answer your question before monday... However, I've tried to open files in a cmd with "mozilla.exe my_file.html" and it was working well (dbl click inside explorer did not work, of course). I think it was what puzzled me the most. I hope it can help you.

is bug 193287 a dupe of this? if so, it might be something of a clue - mozilla will only run when the current directory is the mozilla folder. I guess that prevents it being launched from other apps?

From bug 193287: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030213 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030213 Executing mozilla.exe from a location outside of installation directory causes Mozilla to abort execution without any error messages. This causes problems with the double-clicking of files associated with Mozilla -- the browser cannot be invoked to view the desired files. Reproducible: Always Steps to Reproduce: 1. Under DOS Prompt, change to the Mozilla installation directory ("C:\Program Files\Mozilla.org\Mozilla" by default) 2. Execute "mozilla.exe" 3. Notice that Mozilla is started as expected. 4. Exit Mozilla completely (including Quick Launch) 5. Under DOS Prompt, change to any other location other than the installation location (eg: C:\) 6. Execute "C:\Program Files\Mozilla.org\Mozilla\mozilla.exe" Actual Results: Mozilla is not started. Expected Results: Mozilla should be started, showing a new browser window. I believe the symptoms started appearing about a week ago, but I never tried to track down the specific cause until today. This bug severly affects the usability of Mozilla, because it nullifies the file association feature of Windows for Mozilla.

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

I can confirm comment 19. That's why every time I "reset" my mail program by pointing it to Mozilla as my hyperlink executable I would do so by browsing to the application directory and it would then work. Just having the full path wasn't enough - it needs to be called FROM the directory.

I can confirm comment 19. Launching (url or files) from command prompt works only if the current directory is the installation directory. It was what I've experimented in comment 17 but without understanding what happened.

I talked to ssu and he confirmed my suspiscion this had something to do with the recent GRE changes. In fact, he helped me find the problem: http://lxr.mozilla.org/seamonkey/source/xpcom/glue/standalone/nsGREDirServiceProvider.cpp#129 That "stat" checks for the XPCOM dll in the current working directory while it should look for it in the process' directory. -> dougt

dougt, had a chance to look? this is pain in the butt, and blocking 1.3.

I have a potential fix to the problem jag describes, but I can not reproduce this bug and therefore can not say that it will help out the situation. :-( A couple of notes. First the registry key for the GRE was changed to GRE_PRIVATE_Mozilla without the mozilla client code being updated. So, there is no way for the mozilla client to find the GRE. We should either change the key back to "GRE" or update the string value that ships with the mozilla client to use this GRE_PRIVATE_Mozilla key. Also, if you have installed older "nightly" build and haven't uninstalled it, and are now trying a "zip" install, you might run into problems. Is this the case with any the reports of this problem? reporters, please do this: open up regedit and recored the values for: HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Mozilla.exe Also, state how you installed mozilla (did you use the installer or did up just unzip a zip file?). Lastly state where you mozilla.exe exists on your system. Thank you.

I installed Mozilla via mozilla-win32-1.3b-installer.exe and mozilla-win32-installer-sea.exe (Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030217). My Mozilla.exe is placed at C:\Programme\Mozilla\mozilla.exe

untested patch.

Comment on attachment 114946 [details] [diff] [review] use Current Process Dir nope... try again.

FWIW: Double-clicking on the URL for this bug from my email client (it was a reflex) suddenly worked for me again as of 2003021908 / XP.

Comment on attachment 114951 [details] [diff] [review] attempt 2 this last patch works under windows and linux

Comment on attachment 114951 [details] [diff] [review] attempt 2 >> #ifdef XP_WIN >> char buf[MAX_PATH]; >> if ( ::GetModuleFileName(0, buf, sizeof(buf)) ) { >> // chop of the executable name by finding the rightmost backslash >> char* lastSlash = PL_strrchr(buf, '\\'); >> if (lastSlash) >> *(lastSlash + 1) = '\0'; the calling function already appends a XPCOM_FILE_PATH_SEPARATOR. You don't need to preserve the backslash here. Eventhough it works right now, you should take it out. >> #elif defined(XP_OS2) >> PPIB ppib; >> PTIB ptib; >> char buffer[CCHMAXPATH]; >> DosGetInfoBlocks( &ptib, &ppib); >> DosQueryModuleName( ppib->pib_hmte, CCHMAXPATH, buffer); >> *strrchr( buffer, '\\') = '\0'; // XXX DBCS misery you should check to make sure a '\\' was found before assigning '\0'. >> if (cpd) { >> char* xpcomLibPath= (char *)malloc(strlen(cpd) + sizeof(XPCOM_DLL) + sizeof(XPCOM_FILE_PATH_SEPARATOR)); You need a '+1' for the null byte. r=ssu once these things are fixed.

nevermind about the '+1' for the null byte. you're okay there. I'm just tired.

all fixed. thanks.

Comment on attachment 114965 [details] [diff] [review] same as above -u with ssu's comments. >+ char* xpcomLibPath= (char *)malloc(strlen(cpd) + sizeof(XPCOM_DLL) + sizeof(XPCOM_FILE_PATH_SEPARATOR)); >+ sprintf(xpcomLibPath, "%s" XPCOM_FILE_PATH_SEPARATOR XPCOM_DLL, cpd); This could be PR_smprintf() and hide the malloc and length calculation, a bit cleaner but this is OK too. >+ free (xpcomLibPath); This would have to be PR_smprintf_free() then sr=dveditz, adding approval request

Comment on attachment 114965 [details] [diff] [review] same as above -u with ssu's comments. a=dveditz, need this for 1.3

Checking in nsGREDirServiceProvider.cpp; /cvsroot/mozilla/xpcom/glue/standalone/nsGREDirServiceProvider.cpp,v <-- nsGREDirServiceProvider.cpp new revision: 1.12; previous revision: 1.11 done