Closed Bug 53952 Opened 24 years ago Closed 24 years ago

Mozilla won't start if another Windows DDE app is frozen or blocking DDE requests

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: jruderman, Assigned: law)

References

Details

(Keywords: hang, Whiteboard: fix in hand)

Attachments

(3 files)

Cumulative fix; please test if you're doing builds and experiencing these symptoms
15.19 KB, patch
Details | Diff | Splinter Review
New patch, with DNS_UNREGISTER added
16.33 KB, patch
Details | Diff | Splinter Review
Updated patch for nsNativeAppSupportWin.cpp with Alec's suggestions
13.86 KB, patch
Details | Diff | Splinter Review
Steps to reproduce: 1. Open an IE window 2. Move IE window out of the way so you can click your desktop shortcut to Moz 3. Type ftp://ftp.mozilla.org:15311 in IE location bar 4. Quickly open Moz Result: Mozilla waits until IE thaws before displaying the splash screen. Expected result: Mozilla opens quickly so I can ditch IE and actually get to the ftp site. Additional notes: IE is not using 100% cpu while trying to connect to the ftp site. With the -console option, Mozilla freezes after the first two lines (stdout, stderr redirected to console). The console window itself also freezes -- I can't click the 'x' at the top to get the normal Windows warning that I'm about to kill a DOS app. Additional freezes that prevent Mozilla from loading: - ie: about:<script>while(1);</script> and answer "yes" to the 2-second dialog (you'll get another one in 10 seconds) - mirc 5.7 or 5.8: ;put this in "remotes" and then type /freezeme alias freezeme { while (1){ } } - telnet.exe or putty.exe connect to www.mozilla.org on some random 4-digit port
I have seen this happen, and initially I would say that it's a problem with Win9x's multitasking model. But the fact that it happens with Mozilla, but not with lots of other programs makes me wonder. . .
Bill, any idea what's going on here?
Assignee: don → law
I've seen this behavior and now I'm starting to think I know what's happening. If Mozilla is already running, launching another instance will attempt to locate the running instance by finding a DDE server (this done by doing a DDEConnect). What I've observed is what is described here: the win32 API request blocks in some cases (I've seen it block forever, for all intents and purposes). I never could explain this (and only saw it on certain machines). With the information provided here, it appears as if the Win32 DDE requests block until DDE-aware processes respond. I suspect we will have to find a way to detect an already-running instance of Mozilla that isn't subject to this problem. That shouldn't be too hard.
Status: NEW → ASSIGNED
*** Bug 56897 has been marked as a duplicate of this bug. ***
This might have been causing bug 42997 (mozilla wouldn't start with old/corrupted versions of outlook 2000 running).
also 100% repro on NT (Windows 2000): Mozilla won't start when you have hit a breakpoint in a Visual Studio debugging session when you hit F5 in VS to resume the program being debugged (just any program, not Mozilla of course) then Mozilla will start
I just saw this on Windows 2000 and looked around a little. I found this on Internet: "Does your program create windows or use a standard message loop? If so make sure that you're not doing a WaitForSingleObject or WaitForMultipleObjects call in those threads - use MsgWaitForMultipleObjects instead. The reason for this is that DDE calls SendMessage to send messages to all windows in the system (using something like a "while (gotNextWindow)" loop) and if a thread that owns a window is in a wait and takes no notice of the message, the DDE subsystem (or at least that application) can deadlock. Look at the notes at the end of the help topic for WaitForSingleObject if you need more info. Hope this helps. Regards, John Bates mailto:jlb@powerup.com.au Lead Developer JLB Productions http://www.devstuff.com" Also http://support.microsoft.com/support/kb/articles/Q136/2/18.asp describes a bug in Windows 95 that could cause this, but that is only in Windows 95. I also got an interesting search hit: http://www.angelfire.com/biz/rhaminisys/ddeinfo.html but it won't load right now for me.
nav triage team: Sounds like we should fix this one. Marking nsbeta1, mozilla0.9
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
Adding CC
looks like windows98 blocks on certain Win32 calls if other application is frozen.
Target Milestone: mozilla0.9 → Future
This isn't just Win98. It also happens on Win2000. Can someone change the summary to win32 instead of win98 and put other win32 OS's in the os list? I'm not sure I am allowed to change these feilds...
I saw this today with w2k. Mozilla doesn´t start and I deleted all (Mozilla, Profile, Mozregistry.dat) and reinstalled Mozilla :-( After that I saw, that I have a dead Acdsee process (taskmanager). After I killed this process, mozilla started again.
Changed summary (there doesn't seem to be a way to set the OS field to "all Win32 OSs"). The problem is described completely by the MS knowledge-base article (previously cited): http://support.microsoft.com/support/kb/articles/q136/2/18.asp. Previously, it was stated that this was a Win95-only problem but I don't think that's the case. NT 3.51 is mentioned explicitly and I suspect that subsequent MS OS versions (Win98, WinME, and Win2K) also suffer from the same problem. There is no ready fix, because the problem is with the other applications. The only thing we could do is find an alternative to use of DDEML (note that we don't do our own WaitFor...Object calls). I don't think we have resources to do an alternative DDE implementation using the lower-level DDE apis/msgs. We could do some other form of IPC but support for DDE to enable third-party app interaction was a goal. But since we don't really support that, maybe abandoning DDE entirely would be best for the short term? Anybody should feel free to contribute solutions.
Summary: Mozilla won't start if another win98 app is frozen → Mozilla won't start if another Windows app is frozen
could we ask the os if there are any known dead apps, and disable dde while we know they exist?
This bug might be related to bug 50424, "Run moz while moz is already running --> nothing happens".
*** Bug 66161 has been marked as a duplicate of this bug. ***
Mozilla as a DDE Server ? why not The problem is that DDE is used for by mozilla itself to communicate with other mozilla instances to ensure that there is always only one instance running. The command line (C string) is sent to the previous instance wich takes the focus. Maybe a simple solution would look like: 1) Create a hidden window with a known Window class (there is already a Phantom dialog created then destroyed) 2) When a new mozilla instance starts try to find a window of that class 3) If found send a WM_COPYDATA (see MSDN "Using WM_COPYDATA for IPC") to that window with the commandline then exit 4) If not found proceed normally Of course the WM_COPYDATA handler must be written but it should not be difficult a solution would be to use WM_COPYDATA message as IPC mechanism
We'd like to support DDE for the benefit of third-party apps, as I mentioned earlier. But using a hidden window is a good plan if we drop DDE support entirely.
*** Bug 67069 has been marked as a duplicate of this bug. ***
*** Bug 70973 has been marked as a duplicate of this bug. ***
Target Milestone: Future → ---
This bug sucks. I've come up with a plan, though (looking at bug 70973 prompted me to think about this). I think the trick is to make the support for DDE optional. Basically, we use messages via a hidden window as the standard mozilla<->mozilla ipc mechanism. We will also provide an optional DDE server for third party apps to use. The user will be able to turn off the DDE server (via some "-nodde" cmd line switch). That's for "power users." An alternative is to only start the DDE server if the user specifies some "-dde" flag (or by some registry key which would enable 3rd party applications that rely on DDE communication with Mozilla to turn it on). We will monitor our use of DDEConnect and if it fails (determined by storing info in the registry?) then we'll not try next time. The least risky strategy would be to abandon the DDE server support, switch to some alternative IPC, and then re-enable the DDE server as time/resources permit. Basically, that puts priority on making startup more reliable and lowers the priority of the DDE support. Another approach might be to run the DDE server on a separate thread. That way, if that thread blocks, life goes on. I'm resetting target milestone to renominate this. Note to triagers: This is important! The failure is fatal! If anybody can identify specific applications that block Mozilla from starting due to this problem, please post those here. That will help us prioritize things.
what is the cost of moving DDE to some other thread? unfortunately, it's really hard to tell if our DirectX/Sound bugs are really this. a search for windows* + keyword:hang should turn up the bugs ... I think we have some dde test apps somewhere, but currently, we have no real standard way of diagnosing the problem, if we could create such a diagnostic the problems would be much easier to identify.
Keywords: hang
Moving DDE server to another thread isn't too much trouble *if* we set up the alternate ipc mechanism (that thread would simply convert the incoming DDE request and use that alternate mechanism). As for diagnosing: A hang prior to splash screen is always this problem. If you dynamically attached the debugger and broke into the app, the call to DDEConnect would always be there.
I use the Microsoft Network, and I see this bug when the MSN dialer (MSN Explorer) is open and connected to the Internet.
adding to cc
Bill Law wrote on http://www.mozilla.org/status/2001-03-21.html : > I have a non-DDE ipc mechanism working. Maybe bug 68702 "[RFE] Implement inter-process communication (IPC) in Mozilla" (mozilla1.0, patch, review) is somehow related, maybe not. I'm not familiar with any of these issues, I just stumbled over the "IPC" acronym in both bugs.
That "IPC" isn't of use here. This stuff needs to happen before Mozilla loads and starts up all it's services. I think a mechanism built on top of Necko is too heavyweight.
This is a really bad bug because the only recourse for the user is to give up on Mozilla. Nominating as "cat food."
Keywords: nsCatFood
This also happens for me on Windows 2000 (and did NT 4.0). I happens 100% of the time when I run certain java apps (JServ/tomcat + some of my own servers). If I quit the java apps when mozilla is blocked it will start perfectly. It happens with some other apps too... This is a very annoying problem. (possibly related: bug 65197)
*** Bug 65941 has been marked as a duplicate of this bug. ***
How about this for a workaround: Start a thread whose job it is to call DdeConnect. Wait 15 seconds for the thread to terminate. If it doesn't, kill it. Of course, you could just use WM_DDE* messages :-)
nav triage team: Marking nsbeta1+, nsCatFood+, mozilla0.9.1
Keywords: nsbeta1, nsCatFood → nsbeta1+, nsCatFood+
Target Milestone: --- → mozilla0.9.1
I frequently hang on startup before the splash under Windows/ME. I can't find the app that is causing it to hang, but it always works as soon as I reboot, but no longer starts up after a while. The only workaround is to reboot - closing applications manually does not help. Do you think this problem is related? There are a few other "hang on startup before splash" on windows/98/ME under other specific conditions (after loading Windows Media Player, on low memory conditions, reports of Direct/X interactions, etc). Are you saying these are all related to DDE?
I think we're saying that most of them are dde related, but some are not. I suspect that some of the media ones could actually be related to locked devices, but I could be wrong and have not tried to test this theory. Law: why don't we use a Semaphore, if we successfully create one then we don't try to contact a mozilla session, if we fail, there's already one in existance. IIRC this was the standard way to handle the problem on win32 The CreateSemaphore function creates a named or unnamed semaphore object. #include <winbase.h> //requires win32, not supported by win32s HANDLE CreateSemaphore( NULL, /*LPSECURITY_ATTRIBUTES pointer to security attributes*/ LONG(0), /*initial count*/ LONG(1), /*maximum count*/ "mozillaGeckoV..." /*LPCTSTR pointer to semaphore-object name*/ ); /* Return Values If the function succeeds, the return value is a handle to the semaphore object. If the named semaphore object existed before the function call, the GetLastError function returns ERROR_ALREADY_EXISTS. Otherwise, GetLastError returns zero. */
Summary: Mozilla won't start if another Windows app is frozen → Mozilla won't start if another Windows DDE app is frozen
I presume they're all DDE problems. I have a patch that uses a non-DDE technique to communicate with the running Mozilla. I'll try to attach that shortly (it isn't done) and then people might be able to test whether this fixes their situation. timeless: The semaphore works to tell if Mozilla is running, but in order to talk DDE, you still have to do a DDEConnect. So we need to alternative IPC mechanism in place, as well.
true, but this bug is theoretically limited to the summary [frozen dde using win32 apps], so the semaphore should solve problems when mozilla isn't running, at least for the beginning, right?
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from mozilla0.9.1 to mozilla0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
law: To me the problem is that mozilla is at the same time a DDE client *and* a DDE Server. The DDE Client part needs DDEConnect() and I think that the DDE Server part doesn't need that (correct me If I'm wrong but I think that DdeNameService() is enough) The DDE Server part is used by the first Mozilla instance to register the DDE service. Mozilla is a DDE Client because it needs to talk to other Mozilla instances to transfer control to the first instance (the server) The DDE Client code in Mozilla needs to be removed and replaced by some private communication process but the DDE Server registration is still needed (and it must be done only once when the first instance is started) The result will be that mozilla will not block *itself* anymore but 3rd party applications that use some DDE client code (DDEConnect() call) will still block but it seems to be a well-kown DDE problem ...
Cool; this is a great tip. Coupling this with my already-coded patch to use WM_COPYDATA to a dummy ("message") window will solve the problem, then. I was thinking I was going to have to do the DDE server on another thread to avoid the DDEConnect hang. But you are right; if we can detect client vs. server mode (and communicate from client to server) via another means, then Mozilla does not need to ever do a DDEConnect. Problem solved. When I get back to this, it should be relatively easy to code this up and solve this problem once and for all. I'll try to remember to attach the patch that I've got so far as soon as I can track it down.
There are lots of different and very simplyeways to handle the first instance - later instance thing in a couple of code lines and without resorting to DDE, eg: 1) use a Property (parented to the desktop window) or Atom. On startup, the app just checks whether something of the appropriate name exists. If not, it registers it. 2) Use a named object, such as a mutex (same procedure as above) In either case a 'token' (eg. window handle) of the first instance can be found for the purpose of passing the invokation of a further instance to the original instance. Also WM_COPYDATA might be overkill for the latter (I have had all sorts of cross-Windows-platform issues arising in the past by using this), and its "1-way IPC" - it doesnt allow the receiver to return a result to the sender (eg. if new instance cant be done, for some reason). There are other messages which will automatically convert the LPARAM to have visibility to the receiving process, assuming it points to a string. Of course this just refers to start-up issues. For Mozilla to expose automation functionality for other apps/scripts to use, either object model exposure (nice for automation through scripting) or standard IPC are far better, being divorced from the windowing aspect of things (unlike DDE). DDE was a great way to do IPC back in the days when it was all that there was (Windows 2.0, if I remember correctly) but I personally avoid it like the plague these days :-) In the other hand I'm very much a Mozilla newbie, so I might be talking b*ll*cks :-) Cheers, Chris PS - Note that I assume that Mac/Linux have similar constructs to the above (which use Windows terminology).
Forgot to mention - I just finished by first Mozilla build (0.8.1) and it wont run - it just dissapears into the task list without doing anything visible. I'm using NT4/SP6. As far as I know I dont have any resource (memory/disk/CPU) problems and nothing is locked up on my system - task manager thinks everything is running OK, and the MS Spy++ utility (which tends to hang if you run it when something has a blocked message loop) runs OK. Cheers, Chris
*** Bug 69929 has been marked as a duplicate of this bug. ***
Blocks: 68680
No longer blocks: 68680
*** Bug 68680 has been marked as a duplicate of this bug. ***
From bug 68680: Ontrack's SystemSuite 3.0 Task Manager is another bad mozilla-blocking app.
*** Bug 65197 has been marked as a duplicate of this bug. ***
From bug 65197, this happens with Apache+PHP module as well.
This bug has now oficially 8 dups. If you add bug 73542, a dup of duplicate bug 66161, this makes 9. From the discussion, it seems there may be other dups still at large. Isn't it tme for marking it mostfreq?
Keywords: mostfreq
*** Bug 70799 has been marked as a duplicate of this bug. ***
> Ontrack's SystemSuite 3.0 Task Manager is another bad mozilla-blocking app. This seems to block Netscape 4.7 as well, but it doesn't block any other application software I've tried.
Whoops - forgot to add. If you start Moz/Netscape with the SystemSuite 3.0 "Task Manager" service running, it wont appear (except in the task list). However if you then use the control panel to stop this service, it will complete its initialisation and appear. Maybe thats a clue as to what is going on.
*** Bug 78347 has been marked as a duplicate of this bug. ***
*** Bug 76043 has been marked as a duplicate of this bug. ***
*** Bug 69220 has been marked as a duplicate of this bug. ***
*** Bug 74295 has been marked as a duplicate of this bug. ***
*** Bug 77836 has been marked as a duplicate of this bug. ***
I've applied the patch and it works for me, good job :-) I mean that I only have one mozilla.exe when I try to run it twice and that it doesn't block anymore (for me it was with Visual Studio see above) However I played around with mozilla and DDESpy and I can see that the server is never unregistered (ie run mozilla, close mozilla, run mozilla again, and you can see *2* DDE servers registered instead of *1*) I think that this is because a DDENameService(..., DNS_UNREGISTER) in nsNativeAppSupportWin::Quit() method call must match the DDENameService(..., DNS_REGISTER)
Blocks: 65305
nav triage team: Since we have a fix, moving up from mozilla0.9.2 to mozilla0.9.1
Target Milestone: mozilla0.9.2 → mozilla0.9.1
Blocks: MailNotification
Sorry to just rush into this with a potentially lame suggestion, but if I understand correctly, you are acting as a DDE client to detect if another instance of Mozilla is running. Why not just try to create a named mutex called "MozillaRunsMutex" or something similar, and if it succeeds but GetLastError returns ERROR_ALREADY_EXISTS, then you know that you already have another Mozilla running. Upon exit, you might want to close the handle returned by CreateMutex, but if you don't, Win32 will clean it up for you anyway. Marton Anka marton@03am.com
marton@03am.com: please read the patch. We will no longer act as a dde client.
Keywords: approval, review
*** Bug 79269 has been marked as a duplicate of this bug. ***
Thank you Marton. We welcome all suggestions, lame or not :-). Your suggestion was made previously. I noted then that a semaphore isn't sufficient, because in addition to detecting whether Mozilla is running, we also need to be able to communicate with that running instance. A semaphore alone isn't capable of that. The current scheme (in the patch) satisfies both requirements, hopefully in a way that doesn't hang.
How does the patch work if you were to run both Mozilla and a NS 6.x commercial build at the same time? Do they have different DDE application names?
*** Bug 65305 has been marked as a duplicate of this bug. ***
Making this P1 since bug 65305 (which was P1) was closed as a dup.
Priority: P3 → P1
Whiteboard: fix in hand
I added the call to DdeNameService(...DNS_UNREGISTER), as suggested. I also had to add code to nsAppShellService so that it would make the right call at Quit() time to cause this code to be executed. Looking for review and super-review.
re: Mozilla vs. NS 6.x Mozilla and Netscape do have distinct DDE appliation names. The patch preserves that distinction by varying the "message window" class name accordingly.
Blocks: 75599
Bill, the code itself looks fine, but your deep-nested if statements are very hard to follow. Can we just do some early-returns when errors are encountered? Also, you're making extensive use of printf() when we have stuff like NS_WARNING() available to you (i.e. for debug-only stuff) for example, in MessageWindow::Create(), you have: + if ( winClass ) { + // Create the window. + mHandle = ::CreateWindow( className(), + 0, // title + WS_CAPTION, // style + 0,0,0,0, // x, y, cx, cy + 0, // parent + 0, // menu + 0, // instance + 0 ); // create struct + if ( mHandle ) { + #ifdef MOZ_DEBUG_DDE + printf( "Message window = 0x%08X\n", (int)mHandle ); + #endif + } else { + printf( "CreateWindow failed, reason=0x%08X\n", (int)::GetLastError() ); + rv = NS_ERROR_FAILURE; + } + } else { + printf( "RegisterClass failed, reason=0x%08X\n", (int)::GetLastError() ); + rv = NS_ERROR_FAILURE; + } + return rv; + } This could be shortened to: if (!winClass) { NS_WARNING("Registerclass failed"); return NS_ERROR_FAILURE; } mHandle = ::CreateWindow( className(), 0, // title WS_CAPTION, // style 0,0,0,0, // x, y, cx, cy 0, // parent 0, // menu 0, // instance 0 ); // create struct if (!mHandle) { NS_WARNING("CreateWindow failed"); return NS_ERROR_FAILURE; } #ifdef MOZ_DEBUG_DDE printf("Message window = 0x%08X\n", (int)mHandle ); #endif return NS_OK; --- The flow of control is much more obvious, and error checking doesn't change the indentation of code. You might also like NS_ENSURE_TRUE, which will throw an assertion (so you can debug it), and return automatically: mHandle = ::CreateWindow( className(), 0, // title WS_CAPTION, // style 0,0,0,0, // x, y, cx, cy 0, // parent 0, // menu 0, // instance 0 ); // create struct NS_ENSURE_TRUE(mHandle, NS_ERROR_FAILURE); // mHandle garanteed to be non-null after this..
Thanks, Alec. In this updated patch, I've now adopted liberal use of NS_ENSURE_TRUE, which best matches the intent and semantics of the previous printfs. The only thing missing is the ::GetLastError calls. But I'll just add those back in if I ever have to debug this code again. Maybe we need a vararg version of NS_WARNING... I'm still trying to forget everything I learned while growing up about structured programming and C++; please bear with me :-). The updated version is more succinct, tho'.
great, looks generally good, though I still don't understand why you use this pattern: NS_ENSURE_TRUE(val = SomeCallWithLotsOfParams(a, b, c, d, e), NS_ERROR_FAILURE); instead of val = SomeCallWithLotsOfParams(a, b, c, d, e); NS_ENSURE_TRUE(val, NS_ERROR_FAILURE); from my perspective the 2nd one is much easier to read, and any decent compiler will generate the same compiled code for both versions... a varargs NS_WARNING sure would be nice..hard to do with macros though. By the way, this isn't non-structured programming, this is simply a matter of seperating out error handling from the logic of the code. I won't let that style nit block this sr=, but I would prefer the latter form. sr=alecf
I don't think a compiler will generate exactly the same code (unless it's a *really* smart compiler). I was wanting to put the "SomeCallWithLotsOfParms" inside the macro so the alert would be more informative and approximate what the printfs did. Otherwise, it just says "val" with no clue about why.
It is hard for an outsider to tell from the discussion when a bug fix is supposed to show up in the nightly build, so I'll just note here for the infomation of Mozilla maintainers, that as of the 2001051220 nightly build, [which is now part of the 0.9.0 effort, I suppose], when StarLogo 1.2 is running (not hung, just running at all), Mozilla blocks at launch before the splash panel is displayed, and, however much later, finishes its launch when the StarLogo app is exited. This is described in bug 74295, which I reopened earlier as it seems not to be an exact duplicate of what is being described here, which latter seems to focus on other apps which are misbehaving, though that may be merely my lack of understanding.
*** Bug 74295 has been marked as a duplicate of this bug. ***
+// Start: Tries to find the "message window" to determine if it can you make that a /* comment? bad indent: + retval = LoadString( (HINSTANCE) NULL, id, (LPTSTR) nameBuffer, sizeof(nameBuffer) ); + if ( retval == 0 ) { r=timeless, let's get this in. We need get people testing it. If you don't want to have this in on the trunk yet, could we please spin a test build and stick it on ftp.mozilla.org so people who have seen bugs which we claim are this can test it?
Summary: Mozilla won't start if another Windows DDE app is frozen → Mozilla won't start if another Windows DDE app is frozen or blocking DDE requests
*** Bug 80585 has been marked as a duplicate of this bug. ***
I have personally experienced undesireable DDE behavior on Win98. For Acrobat 5, I had to put some workarounds for this unexpected behavior. For example, if you start Windows Media player on Win98 and make a DDE call, your application will hang. Now we have code that says "if you are on Win98 and Windows Media player is running, try not to use DDE. If you must use DDE, then tell the user to exit windows media player before proceeding."
Wow. do you have a list of applications or is WMP alone? And has anyone considered complaining to microsoft?
Another data point - ActiveState's Komodo, and Python itself also has this problem. We have had reports that running mysql or SQL Server on the same machine can cause the same problem - these apps are not processing a message queue, and can cause Mozilla to refuse to start. The "correct" solution appears to be to drop the DDEML libraries that Mozilla (and many many other apps) use, and instead roll your own using SendMessageTimeout.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I confirm this fix has repaired the problem reported in bug 74295; Mozilla now launches successfully with a Starlogo 1.2 for Java project running. Thanks!
Apache with PHP module and Mozilla builds with the fix also run together perfectly now. TUVM!
My issue with an unknown DDE server blocking Mozilla's startup has also been resolved. Much appreciated! Now I don't have to reboot my computer before trying to start Mozilla.
*** Bug 81411 has been marked as a duplicate of this bug. ***
*** Bug 79754 has been marked as a duplicate of this bug. ***
*** Bug 76432 has been marked as a duplicate of this bug. ***
Veryfying on my own (very positive) experience since the check-in and all the other comments. Good job. Thanks!
Status: RESOLVED → VERIFIED
*** Bug 76663 has been marked as a duplicate of this bug. ***
*** Bug 76366 has been marked as a duplicate of this bug. ***
*** Bug 84442 has been marked as a duplicate of this bug. ***
*** Bug 63383 has been marked as a duplicate of this bug. ***
No longer blocks: 75599
Blocks: 75599
Product: Core → Mozilla Application Suite
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: