Closed Bug 108653 Opened 23 years ago Closed 21 years ago

keyboard focus is still in mozilla when changing application

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

PowerPC
Mac System 9.x
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mac.bjarnedm, Assigned: joki)

References

Details

(Keywords: dataloss, regression)

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
Closed: 23 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.
Depends on: 112258
greg : please re-read the first paragraf of original report :-)

additionally, please see bug #112258
QA Contact: madhur → rakeshmishra
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.
Keywords: dataloss
*** 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.
Keywords: mozilla1.3
QA Contact: rakeshmishra → trix
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 <sdagley@netscape.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
Closed: 23 years ago21 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. ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.