From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5+) Gecko/20011030 BuildID: 2001103008 and later when changing from mozilla to BBEdit 6.5 typing on the keyboard is still happening in mozilla. this is especially evident if the mouse has focus in a HTML-textarea. this might be an issue with carbon applications as this behaviour isn't present in BBEdit 6.1.2 which is PPC native. Reproducible: Always Steps to Reproduce: 1. open a document in BBEdit 6.5 2. open a webmail document in mozilla that displays the text in a textarea 3. copy some text from the textarea and paste it into BBEdit Actual Results: keyboard commands are executed in BBEdit 6.5 mouse works as it should typing text is entered in the textarea in mozilla Expected Results: typing text should be entered in BBEdit 6.5 issue discovered upon updating to BBEdit 6.5 -- which build of mozilla first displayes this behaviour is an open question. it's a regression issue -- works as expected in 20011017 problem might be related to: a) carbonlib -- problem also seen with version prior to 1.4 b) CopyPaste extension (bug 100695 ?? ) workaround : open a html-tag for editing and close the dialog-box again -- no need for making any changes to the html Computer : PowerBook G3 (3500) -- MacOS 9.1 -- carbonlib 1.4 am using the CopyPaste extension (bug 100695 ?)
Reporter, can you reproduce the problem with CopyPaste disabled?
yes -- also present with CopyPaste disabled :-( but at present I'm having serious trouble with my system -- take a look at bug #108674 -- this might be the root cause of this also -- am in the process of findig out where that problem is :-(((
Can confirm the problem -- in no way related to CopyPaste or bug #108674
Bjarne, can you still reproduce this problem using Mozilla 0.9.6?
did some further testing ... tuns out that the problem is dependent on a Control Strip Module: Quit CSM 2.2 from MaBaSoft the problem is in existense when "Hide Front Application before Switch" is turned on, and totally absent when this feature is off. have updated report accordingly will contact MaBaSoft
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
futher comment that might be of interest : the conflict is dependent on Mozilla being the first application the conflict isn't limited to BBEdit 6.5 -- strange things have also been seen when changing directly to MailWatcher 2 general workaround with feature on: instead of swithcing Mozilla -> [application] do this : Mozilla -> Finger -> [application] note: might be an issue with Mozilla after all -- but my experience with programming this kind of thing is absolutely nill somebody knowledgeable might consider reopening ???
I'm reopening -- bug ***NOT*** present in 0.9.5
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I'm unable to reproduce this problem using Mac/2001112011 (0.9.6) and BBEdit 6.1.2.
greg : please re-read the first paragraf of original report :-) additionally, please see bug #112258
I can reproduce the bug on Mac OS 9.2.2 G3 233 beige Build id: 2002041711 The problem is reproduce in FirstClass Client and Msn Messenger FirstClass Client: PPC ONLY MSN Mesenger: Carbon It'nt present in BBedit 4.1 but present in BBEdit 6.5 I don't need to copy-paste to reproduce the bug, just write in the adress bar, and go to MSN messenger, the text I write will be in Mozilla adress bar
Marking confirmed per Comment #10.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can reproduce the bug on MacOS 9.1 an Mozilla 1.0 (it also were in previous versions down to 0.9.7 iirc) workaround instead of swithcing Mozilla -> [application] do this : Mozilla -> Finger -> [application] is working...
this seems to be a Mac OS 9.x problem only. it's not present on Mac OS X 10.1.5 possibly needs to have pp added to keywords bug 108653 & bug 112258 are now identical as all other issues in 112258 have been resolved. I recommend : 1) marking one of these bugs as a duplicate of the other but the information contained in bug 112258 suplements the info here 2) giving the bug a low priority (P5 - Future) as Mac OS 9.x is almost dead as a stand-alone OS a note as to when this bug reared its ugly head: -- it's !NOT! present in 0.9.5 proper -- it appeared in a 0.9.5+ release before 0.9.6 was released
*** Bug 158294 has been marked as a duplicate of this bug. ***
*** Bug 158430 has been marked as a duplicate of this bug. ***
Is bug 153067 a dupe of this one?
*** Bug 159113 has been marked as a duplicate of this bug. ***
This is major, not minor.
Severity: minor → major
joki, is this the right component for this bug?
*** Bug 158953 has been marked as a duplicate of this bug. ***
*** Bug 163201 has been marked as a duplicate of this bug. ***
*** Bug 140506 has been marked as a duplicate of this bug. ***
*** Bug 129348 has been marked as a duplicate of this bug. ***
*** Bug 164820 has been marked as a duplicate of this bug. ***
Adding keyword dataloss, reason for this: When i switch to Sherlock I cannot type into it, so I press Apple + Q to exit Sherlock, But, focus is in Mozilla, so Mozilla shuts down instead.
*** Bug 167340 has been marked as a duplicate of this bug. ***
It seems like the only activity on this serious bug is heavily dupemarking, while we're nearing first anniversary of "cannot use mozilla here". =%-) Can I help in any way? I can reproduce this Bug anytime. I'm not coding on Macs Are there any pro's and con's about my theory that only german OS9 has the problem? I have noticed that not every program has the Problem when interacting with Mozilla. Situation: Mozilla ist open. I send it to background or "minimize" the windows by doubliclicking and start Application $X. For $X=Sherlock the keyboard is "gone" _every time_. For $X=InternetExploiter it is gone very _often_. For $X=MacSSH there is _never_ a problem. If you try to reproduce the Bug: Have Mozilla open, press Apple-Option while clicking on Finder's Desktop and press Apple-F to Start Sherlock. I _never_ can type then anymore. In this context it may be interesting: In Control Panel "Appearance" i haved chosen "Minimize Windows on doubleclick" (Sorry, don't know the exactly english name) So, again: Can I help? Maybe the Apple Licenses allows that I send someone a German OS that already has paid one in another language? If so, I would send a copy to a developer.
It is not a german bug. (Maos OS 9.1, French Build 2002090608) I have it also very often with the script editor. I have also it every time with sherlock if use your tip "Have Mozilla open, press Apple-Option while clicking on Finder's Desktop and press Apple-F to Start Sherlock. I _never_ can type then anymore." Have some noticed the curious appearence of comment 27 title ? The date override the from field. I some one can confirm this i'll submit a new bug.
*** Bug 168187 has been marked as a duplicate of this bug. ***
*** Bug 168801 has been marked as a duplicate of this bug. ***
Mac OS 9.2.2 English-North American. Have ‘Modern’ theme installed. Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2a) Gecko/20020915 Build ID 2002091503. This works for me. The foreground app quits normally, and Moz continues unperturbed.
I still see the problem once in a while (but less frequently than in the past). Build 2002091309 on Mac OS 9.
Severe probs with this bug, though i can't find specific ways to trigger it. However, I'm suffering heavily from this bug, as i usually have lots of apps running, and a very high chance of this behaviour to kick in.. (HTML coding and testing) Here it happens with _any_ app, alas i found out, that i don't need to really quit moz, just closing all of it's windows will do.. (but still sucks, when you have 10-20 unread tabs.. ;) Here means: * Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1) Gecko/20020826 * graymodern theme * german Mac OS 9.1 * powerbook Pismo G3/400 This problem is a big one in my opinion, actually it renders Moz heavilly handicaped.. i started to promote Moz in the recent past, exchanging NS4.x on all of my client's and friend's macs with Moz, but if this ain't gonna be fixed soon, i'll have to supply them with some other UA. Furthermore i'd like to add a few lines to Bjarne D Mathiesen's comment in #13: > 2) giving the bug a low priority (P5 - Future) > as Mac OS 9.x is almost dead as a stand-alone OS This statement is sure wrong. OSX now has reached only some 10% of macs so far, and it won't _ever_ reach a substantional number of them in the near future, as it is only usefull (in terms of performance) on the latest Systems, plus, there is a huge number of macs, who simply can't run OSX in generall! So i'd vote for a high priority for this bug! Mozilla should be a usefull UA for 90% of today's mac users.. those, and the macs they're using won't dissolve into thin air, just because OSX finally gets into a usefull shape. OSX is the Mac's future, but OS9.x will be around for quite some time.. we're talking about the next years, not months or weeks. regards, jan
Try bug 153067, comment 4 to reproduce this. I can do that every time.
It happens with SimpleText and with PowerPoint 2001 so far.
*** Bug 123528 has been marked as a duplicate of this bug. ***
*** Bug 130270 has been marked as a duplicate of this bug. ***
*** Bug 130712 has been marked as a duplicate of this bug. ***
*** Bug 174763 has been marked as a duplicate of this bug. ***
Mozilla 1.2 Beta: The bug is still in there. Please consider to increase importance of this bug. We have no plans here to change to OS-X for a long, long time. It would be great to make Mozilla run under OS 9.
On 9.2.2, I can successfully reproduce the bug by _option-clicking_ to switch to certain other applications, so that Mozilla is hidden. Actually, option-clicking on the application tear-off menu triggers it as well, and option-choosing another application in the finder menu, too. Oddly enough, even choosing "Hide Mozilla" will trigger it, no matter what other application was last in front - but the keys are still only confused in some apps, not all. So, if you are in the finder, switch to Mozilla, hide Mozilla, then go to Explorer, and press Cmd-N, Mozilla gets a new window. Applications I've found it to happen with: - Explorer 5.1.6 - AIM 4.3.1232 - SimpleText 1.4 - Tex-Edit Plus 4.1.1/4.1.2 - Script Editor 1.8.3 Could probably hunt down more :-)
Somewhat of a (lame) workaround: Lately i found out, that switching back and forth (by clicking in the according app's window) between Moz and the conflicting app will set the focus right after a few tries. But there seems to be no distinct pattern, sometimes it's enough to click back'n forth once, sometimes it takes up to 5 times. However what seems to matter is if Moz's window is shaded or not, or if i click only on the windowbar or the rims, versus clicking the window's content. This i wanna add to M Spreij's observation in #41: I do use option clicking a lot (plus using the "ProgramSwitcher" control-panel), which explains why i'm getting the focus prob so often, alas: I do get it as well even i don't use option-clicking.. even if less often. What _seems_ to add to the probability for the bug to kick in, is a shaded Moz window, but again, i can't find a pattern to nail down. Please, if someone feels like to check this, come back, and let us know, if you can affirm my window shade observation or not.. btw: is it correct the bug's owner never showed up here? I'm a bugzilla newbie, so i might get something wrong.. is that person following our lill' log here, or are we talking private? ;) cheers, Jan -- * Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1) Gecko/20020826 * graymodern theme * german Mac OS 9.1 @ powerbook Pismo G3/400
Another crazy behaviour: - I boot my system without opening my keychain - I start mozilla and hide it - I start Interarchy ftp-client (former Anarchy) - I give the command to open an adress. I can type(!!!) this adress - The keychain wants to open to add the password. There i can not(!!!) type the adress So the error jumps over two programms. It looks to me like there are different ways to read from keyboard, and mozilla just blocks one method.
I have maybe 100 Macs to support and its absolute nonsense to say this is not a serious bug. Macos9 is on ALL machines and for me it will be there another year. I can confirm that the bug happens with Mozilla 1.2b and Macos 9.1 to 9.22 (disk version 1.2 latest apple produced on cd). The problem appeared with Netscape7 and Mozilla 1.2b. It did not appear with Netcsape6-6.21 german. Beside Sherlock there is the office 2001 suite affected by this bug. Try to go to an excel datasheet while having the Mozilla Mailclient open in the background. When you delte a cell in the Excel datasheet YOU ACTUALLY DELETE A MAIL in the Mozilla Mail client-very funny. This is serious. I thougt i could change to Mozilla which got great scoring in the last Browser shootout foe Macs in Macwelt (german) as the only browser able to display every page correctly (version 1.2b). But with this bug and incompatibility with so wide-spreadet programms like office 2001 its useless. I hope anyone can fix this or has an idea.
Re: comment #42 from Jan: "Please, if someone feels like to check this, come back, and let us know, if you can affirm my window shade observation or not.." Confirmed! In 1.2b and also 1.3a (build 2002112203), the problem's still there. Re: comment #43 From Jörg Roßdeutscher: As mentioned in comment #41, the behaviour only shows with some other applications, not all; in your case it does happen with the Keychain app (or maybe it's a process? anyway, not strictly part of the Interarchy app), but not with Interarchy. The order in which these applications were launched/activated after hiding Mozilla does not seem to matter.
what's the idea of removing a lot of people from the cc-list ??? as to comment #42: yes, I'm still around. I'm following this closely but as I've no further observations since comment #13 and no experince in programming at this level, I'm keeping mum. Also - to add to the confusion - I've changed email address. Now, at to the latest observations of this bug: take a look at bug 112258 !!! Does *any* of you have something like those system extensions installed ??? Can you pinpoint the cause to something else ???
> Does *any* of you have something like those > system extensions installed ??? Hi, as I wrote above I can reproduce this bug on freshly installed systems with no 3rd-party-Tools on the machine. I am a sysadmin and I install a lot of different types of macs, and I have this bug on every machine. I always do a custom install and just install the plain OS without the goodies on the CD. It looks to me as if all Mac-developers were gone to OS X, leaving us with a broken browser. This is really a problem, because my company _can_ not change to Mac OS X. We'll stay with OS 9 as long as possible.
Jörg: Actually you *haven't* answered my question. Please *do* read bug 112258 and answer my question: do you have something like the programs described in bug 112258 installed ??? Yes / No ??? The problem has *nothing* to do with what on the MacOS 9.x CD !!! It's related to what other programs that are subsequently installed do when communicating with the OS. So, you are saying that you do a clean install. That's fine. !!!BUT!!! what other programs do you install ??? I suppose it's a significant fact, that the bug *isn't* present in BBEdit 6.1.2 but *is* present in BBedit 6.5. The Mozilla coders might ask BareBones what they have changed in the way of keyboard and OS interaction between these two versions of BBEdit. Also, the point at which the bugt was introduced into Mozilla *has* been rather clearly identified to be *after* 0.9.5 was released and sometime *before* 0.9.6. There must be *some* way of discovering what was changed in Mozilla during that time ?!? Now, all of you who have reported duplicates: does the workaround as described in comment #6 work *always* for you ??? It will be of interest to the programmers of Mozilla to know if this workaround is viable in *all* cases of if it breaks with some programs. Now, *please* give the programmers of Mozilla som *usable* feedback !!! They *do* know that switching between Mozilla and many programs keeps the keyboard focus in Mozilla. A new list of programs with this problem is not of much interest to them (I suppose)!!! In my case I've *only* ever seen the problem *if* I've activated the "hide front application when switching" - I've *never* seen the problem in any other case !!! And! the workaround as described in comment #6 *always* works for me !!!
I dont have any of these programs installed mentioned in bug 112258 and I have this problem. Maybe thats why bug 153067 hasnt been duped to this one. Bjarne, what happends if you remove the programs that you think is causing this, follow the instruccions in bug 153067, comment 4?
To Bjarne: > Jörg: Actually you *haven't* answered my question. > Please *do* read bug 112258 and answer my question: > do you have something like the programs described > in bug 112258 installed ??? Yes / No ??? Sorry, but I think you did not read my text. I wrote: > I can reproduce this bug on freshly installed systems > with no 3rd-party-Tools on the machine. I have not installed any software mentioned in any bug, because NO software ist installed except MacOS: - Booting from Installer-CD - Wiping harddisk, write new driver, creating new filesystem, erasing Parameter-RAM - Install "OS 9 minimum" - (Update to 9.2.2 or not, doesn't matter) - Install Mozilla = Bug is there. > !!!BUT!!! what other programs do you install ??? No other software at all. ( Well, certainly later I do :-) ) The workaround you mentioned says: "First switch to Finger". I don't know what finger is except a network-protocol. A 3rd-party-tool? I think, I don't have it. Sherlock finds nothing. It also says something about "hide front application". I think this is an option in a 3rd-party-tool, because I cannot find something like that in my (german) System. If I misunderstood that, please someone correct me. I suspect this bug only occurs in not-english OSes? We have germans in this thread, a (positive) feedback from france, and, errr...emmm... most of the names don't sound very english. :-))) Can anybody reproduce that on an english/american OS9, maybe also without 3rd-party-soft?
*** Bug 181812 has been marked as a duplicate of this bug. ***
As noted in Bug 181812 (duplicate - sorry) I can reproduce this behaviour on both North American OS 9 and International English OS 9 with 9.0.4 through 9.2.2 and Mozilla 1.0 through 1.2b. The bug appears to be in Mozilla's handling of foreground/background changes. Mozilla (appears) to only handle proper switches using the application menu. If an app "pushes through" to the front OR you "hide" Mozilla, Mozilla does not release keyboard focus. However if you use the application menu to switch to SimpleText (for example), THEN "hide others" it's OK.
I've just found this : ================================================= Subject : Changes coming for Mozilla Mac builds From : Steve Dagley <email@example.com> Date : 21/11/02 19:33 Newsgroup : netscape.public.mozilla.macosx ... The Mac Classic build (for Mac OS 8.5 thru 9.2.2) will be downgraded from a primary (tier1 in the old Netscape vernacular) build to 'port' status. While Netscape employeed engineers will no longer be working on pre-OS X bugs we have heard from an external developer that wants to keep this build going (which is why it's being moved to ports rather than simple retirement). More details will follow before the move happens. ... ============================================================== I'm sorry I haven't posted any test result re: the lastes postings here, but I'm almost exclusively MacOS X and don't use my old 9.1 system that much anymore. Additionally I'm quite busy with my studies. I'll try to get some major testing and experimenting done during the upcomming holidays :-)
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: major → critical
It seems like this only affects mac classic for which Mozilla is no longer developed -> Wontfix
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → WONTFIX
*** Bug 196022 has been marked as a duplicate of this bug. ***
*** Bug 230067 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.