Closed Bug 118347 Opened 23 years ago Closed 20 years ago

Tasklist won't always switch to Mozilla (neither will ALT+TAB)

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: rockowallaby, Assigned: mkaply)

References

Details

Sometimes in Mozilla build ID 20020103 (I can make it happen after only a few
minutes of browsing sometimes) when I put a maximized or otherwise large
application window over Mozilla and I later try and ALT-TAB or CTRL-ESC to bring
up the Mozilla window, it doesn't come up.  It acts like I never requested it to
come to the forefront.

The solution seems to be to minimize/move all windows in Mozilla's way and click
it to the forefront.  Oddly enough, it will then start responding to ALT-TAB or
CTRL-ESC again.

I'm running SDD Beta 44 and warp 4 Fixpack 15, with the latest kernel.
.
Assignee: asa → mkaply
Hardware: Other → PC
*** Bug 126873 has been marked as a duplicate of this bug. ***
I don't think it has to do with WarpCenter.  I ran this test:
1. Started three browser windows, and got into a situation where one of them (a
Yahoo! news page, as it happens) couldn't be surfaced from the Window List. 
(Tile was also ineffective, as it turns out.)
2. From the Window List, ended the WarpCenter.
3. Tried to use the Window List to surface the stubborn browser window.  Didn't
work.
I have a theory about this, though, but it might require a slower network
connection (or modem connection) to replicate, because things happen too fast on
office networks.  Try opening three browser windows or so.  Click on a hyperlink
in one, then immediately switch around (with the Window List or Warp Center)
while the page is loading to the other(s), then try to go back. On my system
that replicates the problem *fairly* consistently.  It also appears that, once
you get focus back (by minimizing other windows, for example), you can switch
again, as long as you don't repeat the click-on-a-hyperlink bit.  Also, I've
always run this exercise with the windows maximized, so you might start there --
but I don't know if that's required.  In this test Tile doesn't seem effective,
by the way.

Could Mozilla be dropping a focus message or something when in this "vulnerable"
state of operations?
The only program I run consistantly with Mozilla open is NPSWPS.  I disabled
WarpCenter completly (As far as I can tell), so I would have to agree that
WarpCenter is not a factor.
We have disabled all Mozilla code that messes with the task list and this
problem still happens.

Right now it is looking like an OS/2 bug.

We'll keep you updated.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Clicking "Tile" or "Cascade" from the tasklist helps to get mozilla back.

*** Bug 187830 has been marked as a duplicate of this bug. ***
I'm experiencing the exact same problem. ACP2, fixpack 3, running Styler/2
1.6.4.22, XWorkplace/2 1.0.0 and CAD Commander.

Can you possibly release some sort of debugging release of Mozilla or something
which logs of all PM events (focus or otherwise) that interact with Mozilla so
we can see what's going on from Moz's end when from our point of view it is dead.
Actually, we've debugged this and it is an OS/2 focus problem. Even if we remove
all code where Mozilla messes with the tasklist, it still happens.
Do you know specifically what conditions trigger it? If not, I would still be
suspicious of Mozilla itself.

More to the point, Mozilla is the *only* application I've ever had this problem
with, and I've run hundrends of apps in the past few years.

That aside, what do we do now? How do we track the problem down?
It is a Mozilla issue but an OS/2 bug.

I have the documentation at home, but basically you can get OS/2 to a point
where the task list entries are out of sync with the windows that correspond to
them and there is no way to put them back in sync.

The Os/2 team has seen the problem with other applications.

We could only recreate it if we switched windows really fast.

If you could find a much easier way to reproduce it, we might be able to look at
it better, but honestly it is such an obscure problem, we never considered it an
issue.
<sigh> Well, I for one consider it an issue.. but then, that's not a surprise :)

You mentioned you could recreate it if you switched windows really fast. Could 
you not possibly create some automated testcase which triggers PM window focus
change very fast and reproduce this for you on a consistent basis?

Sure this issue might not take down Mozilla, but I see it often enough that it
has become a real bother. Besides, Mozilla's stability and UI are pretty stable
right now anyway.
I have this problem every time I run mozilla and I also see a related problem
with the z-order of mozilla child windows. If there is a popup window visible
and the mozilla main window is not visible, I click on the main window in the
task list but the popup gets the focus and the main windows remains hidden. If I
then minimize the popup and click on the main window entry in the task list,
both the main window AND the popup appear. I think that mozilla does a lot of
bad things with the windows.
As I have always pointed out with focus problems, if you can give me VERY
SPECIFIC recreation scenarios, we can look a them.

I mean VERY.

Bring up browser. Click here. Do this. Do that.

Can anyone do this? 

It would really help.


Can someone try this with 1.3b? I changed how frame windows are created and I am
hoping it helps this.
I had these problems mainly in combination with ProNews and PMMail.
I will download 1.3b in the next 2 weeks and try it.
Hi,
I am Naveen from IBM India.
I too faced the same problem of setting the focus for IWB window on OS/2.
I am using ACP2 with XRC_003 Fixpak.

The recreation scenario is as below.

On OS2 Load IWB.
Go to Edit, Preferences,Advanced options and  Clear the cache.
Go to Edit, Preferences,Navigator option set when navigator starts up display,
Last page visited.
Click on OK.
Close IWB.
Reload IWB.
In URL specify some address www.yahoo.com
Within the time the page gets loaded, click on File New Navigator window(Or ctrl+N).
This page starts with your old page, stop it and type some other URL.
Like this open some 6 to 8 IWB windows, all with different pages.
Now press Control+Escape key.
You will get all the windows (IWB)list which are loaded.
Using arrow key select an IWB window, Press enter key.
That IWB window comes front.
Repeat the same steps for other windows, some of the windows will not come front.
Try to do the same with Alt+Tab key.
Some of the window will never come front.

But there is a work around for this.
Drag the windows manually aside one by one.
You will find the window which is not comming fron between them and it can be
moved after that.

I tested it with 1.4a and it still happens. I can't say if it is more or less
frequent.
As said before, this is an OS/2 bug so there is not much I can do.
Mike, I know you keep on pointing out this is an OS/2 bug, but the fact of the
matter is that Mozilla and Netscape/2 are the only apps I have ever experienced
this bug with. Whatever it is that is being done in both these apps, you should
undo or at least work around this bug.

In terms of pinpointing this as an OS/2 bug, do you have a testcase to prove
this? Are you getting invalid behavior/output when you call certain API functions?
I had one of my developers kernel debug this and he pinpointed exactly what the
OS/2 problem was.

Ok, here it is.  Timing issue in PMWIN.

In bad case:
------------------
1) Frame created due to "Open in new window" click
2) focus set during nsDocShell::EndPageLoad's call of global->HandleDOMEvent(
NS_PAGE_LOAD ) to a child of the new frame
2) frame->pwndFocusCurrent set to this focus window
3) focus changes due to alt+esc
4) window set as pwndFocusCurrent destroyed during nsDocShell::EndPageLoad's
call of presShell->UnsuppressPainting

problem is that the window stored in frame->pwndFocusCurrent is now invalid and
freed up.  It'll get filled in during the next window allocation, but then
pwndFocusCurrent won't be a child of frame anymore.  That's why focus is set to
the wrong window.  It gets set to the frame that pwndfocuscurrent is a real
child of.

In working case:
-----------------------
1) Frame created due to "Open in new window" click
2) frame->pwndFocusCurrent set during nsDocShell::EndPageLoad's call of
global->HandleDOMEvent( NS_PAGE_LOAD )
3) window set as pwndFocusCurrent destroyed during nsDocShell::EndPageLoad's
call of presShell->UnsuppressPainting
4) focus changes during WinDestroyWindow to give focus to next item in the
focuschain, which'll reset frame->pwndFocusCurrent

****************************************************************

In wincreate.c in FreeWindow() there is a check where when a pwnd is getting
freed up it will go up the OWNER chain looking at the owner's pwndFocusCurrent
to see if it is equal to pwnd and if it is it is nulled out.  But in our case,
owner window isn't set.  Looks like you can get by with setting up the owner,
but I don't know if that'll work in the context of things.  Something to try,
though.


Is there anything in the Netscape 4.61 source that would be useful in solving
this problem? I don't think I've ever seen the problem in that version. Or in
Web Explorer, for that matter. Am I foolish for even suggesting a look-see at
closed source for an open source project, Mike? :-)
Why does this bug happen mainly when I have Pronews/2 running?
I think this might be fixed with something I just put in.

When 1.4.1 (or 1.5b) is released, we'll need to do some more checking.
Can someone try this with a recent build?

I'm pretty sure it's fixed.

Otherwise, I'm going to close it.
I'd love to verify for you but for some reason I can no longer find VAC builds
of Mozilla anywhere. Where do I find these nightly builds?
You can get the latest 1.4 VACPP build from here:

http://ftp34.newaol.com/pub/mozilla/nightly/2003-08-25-08-1.4/
Bad news. I just reproduced the bug using build "Mozilla/5.0 (OS/2; U; Warp 4.5;
en-US; rv:1.4) Gecko/20030825".

Specifically, I didn't have problems with ALT-TAB, CTRL-ESC but I *did* have a
problem selecting Mozilla from the Window List. I was inside one Mozilla window,
I hit CTRL-ESC and selected the other one and hit ENTER to change focus to it
and nothing happened. Doubling clicking with the mouse didn't work either. It
just refused to work. I then minimized Mozilla and tried again and this time it
worked.

So for now I would say we still have a bug.
It has become much better with 1.5b, I see it very seldom now.
Now with 1.5rc1 there is another funny behaviour: now and then the mozilla
window pops to the foreground if it was minimized. 
Today while browsing with the new 1.5rc1 I had 2 Mozilla windows minimized and
when I tried to switch back, it was impossible - I had to kill the mozilla
process.  I've never seen this problem before.
I hate to break it to you guys, but this is an OS/2 bug. It was tracked down and
fixed in the operating system.

No idea when a fix will be released.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.