According to Talkback, Firefox 1.0 and Firefox 1.5 crash 5 or more times a day at MyActivateTSMDocument(). In some cases, I believe the Flash Player is to blame, and in order to fix the crash, a code modification needs to be made to both Firefox and the Flash Player. The situation is this: In order for Input Method Editors (IME) to work between plug-ins and Mozilla, back in 2002 Frank Tang of Mozilla and I put code in Mozilla and the Flash Player using Apple's TSMDocument API. The Flash Player currently uses bottom-line input, and Firefox (and all other browsers that support IME) use inline input. In order to allow the Flash Player to do bottom-line while Firefox does inline, the TSMDocumentID of the active application or plug-in is activated. Specifically, when the Flash Player gets focus, the player caches the browser's TSMDocumentID (that is, the currently active TSMDocumentID). Then, the player deactivates the browser's TSMDocumentID, and activates the player's ID. When the player loses focus, the player deactivates it's own TSMDocumentID, and then activates the cached browser's TSMDocumentID. The same thing is done when the player is shutdown. Unfortunately, if the cached TSMDocumentID is released or otherwise trashed before the Flash Player loses focus or is shutdown, then when the Flash Player calls ActivateTSMDocument() on the cached pointer, the player causes a crash in OS-level function MyActivateTSMDocument(). With Firefox as it stands today (even in Firefox 1.5), if the Flash Player does not reactivate the browser's TSMDocumentID, then Firefox ends up using bottom-line input, which is bad. According to Apple, there is no way (or at least, no sanctioned way) for the Flash Player to be aware that the TSMDocumentID is no longer valid. So, to solve this issue, instead of the Flash Player reactivating the browser's TSMDocumentID, the browser should instead take care of reactivating its TSMDocumentID, both when the Flash Player loses focus and when the Flash Player is shutdown. There may be other times when the browser is required to reset its TSMDocumentID. When the browser is fixed to make this change, then the Flash Player also will need to be changed to stop activating the browser's TSMDocumentID. Given a browser version number that has this fix, I can remove this code from the player. I do not have a reproducible test case that exhibits the crash. Camino dealt with related bug 183313, but their issue is somewhat different, as they don't seem to support IME at all (at least in my testing). None of the Camino test cases for this bug cause a crash in Mac Firefox in my testing. Safari does something completely different that doesn't require any of this TSMDocumentID mucking. The Flash Player doesn't have to activate or deactivate its TSMDocumentID with Safari. Note that Opera also uses this TSMDocumentID logic and I am pursuing a bug fix with them too. Some Talkback id that may exhibit this issue is: Talkback 12325110, Talkback 12318520, Talkback 12261317 I will attach a simple HTML and SWF that can be used to trace through the TSMDocument code.
I am running W98se in a Compaq desktop and in a Compaq notebook... The last three formats and reloads I did on these two, didn't start having shutdown and freeze-up problems until I installed a flash player... I finally figured it out, and uninstalled the flash players today.. and all the freeze-up glitches went with them.. as did ALL the SeaMonkey 1.5 troublesome glitches too... Finally, ah see'd duh light... It seems that flash player and shockwave are way too "state of the art" for the old coal-burning steam-powered Windows system, and maybe for those microsoft systems between 98 and XP as well... If the users who are experiencing freeze-ups and crashes dump their flashplayers and shockwaves, I'm bets the Mozilla bugs backlog will probably be reduced by 2/3rds or more...
I wish I knew about this bug sooner. I heard about it in bug 345010.
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year).