Closed Bug 246805 Opened 20 years ago Closed 19 years ago

Selecting a window does not raise it when several windows are present

Categories

(Firefox :: General, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED EXPIRED

People

(Reporter: cmhofman, Assigned: bugzilla)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When I have several windows open and I select a window in the back by clicking
inside the window, but not on the titlebar, the window is selected but does not
raise above the front window. Also, even though the backmost window is now
selected, any keypress moves the selection to the front window, which responds
in an eratic way. When I however first move out of the application (e.g. by
clicking the dsktop), I can normally select and raise the back window (but
moving back to the first window gives the same problems again). 

Even when I do raise the other window using the title bar, which does raise it, 
keypresses will affect the first, nonselected, window. For example closing and
opening tabs will happen in the other window that was moved to the back. Again,
things go normally when I move to the other window by first going to another
application. 

This started for me in Firefox 0.9rc1, and remains in Firefox 0.9. 

Reproducible: Always
Steps to Reproduce:
1. Open two windows
2. click inside backmost window, but not on titlebar
3.

Actual Results:  
The back window is selected (title bar changes color), raises for a fraction of
a second, and is covered again by the former front window.  

Expected Results:  
The backmost window should be raised above the front window and stay there.
Do you have a set of steps that consistently shows this problem for you?  
(In reply to comment #1)
> Do you have a set of steps that consistently shows this problem for you?  

It always happens when changing the focus to another window. 
For example: 

1. Open two browser windows
2. make sure one window is selected properly (e.g. by clicking the desktop and
then selecting the browser window). 
3. try to select the other browser window by clicking in the view area

After these steps the second widnow does not get the focus, and key events are
not directed to it. 
I also have seen this behavior. I believe it is related to/same issue as bug
246981, as it only occurs (for me) when running CodeTek's Virtual Desktop.

As stated in the mentioned bug, this does not occur when not running CTVD, or
running an alternative such as Desktop Manager.
(In reply to comment #3)
Confirmed, I also am running CodeTek's Virtual Desktop. The window focussing
problem disappears when I do not use it, however focussing of textfields still
appears  without CTVD (e.g. location field or search field, e.g. try opening a
search field with Command-F). Therefore it seems to be a bug of Firefox, also as
Firefox 0.8 did not have the problem. It seems that my bug 246218 about the full
application menu not appearing is also related to this bug. That problem was
also mentioned in bug 246981. 
I am sorry, but is anyone still concerned with this bug? It is 5 month later and
we now have 1.0, which should be the stable release, and it's still there! It is
a very annoying bug which was created along the way - it was not there in 0.8 -
so is indeed a FF bug, and should be fixed. Also the roadmap page does not know
about this bug, I hope it is not forgotten, or I will have to forget about FF.
I have not been able to reproduce this problem.  Have you talked to the
developer of CTVD about this?
(In reply to comment #6)
> I have not been able to reproduce this problem.  Have you talked to the
> developer of CTVD about this?

Have you got access to a Mac with CTVD? I mailed with them including links to
these bug pages. They say they are working on it, I have no idea if they have
anything. I have now seen several bug reports about focussing behavior of FF on
Mac, with windows, menu bars and text fields, which I think are the same problem. 

Somehow the OS is not notified properly about a changed status of a FF window,
being key focussed or raised. I don't know what notifications CTVD uses to place
the windows. It looks like for a fraction of a second the window that is clicked
gets raised, but then it goes back again. 

I guess a developer should get in touch with CTVD. 
Some parts of the bug still exists in Firefox 1.0, it's better, but there are
still problems. Specifically I have seen (under CTVD):

    Text Input Fields won't take focus w/o switching to another app and
    back to firefox.

    Menubar selection stops working (e.g., selecting a bookmark does nothing.

Since this only happens in firefox, and did not occur in earlier releases it
seems to me that this is a firefox bug and not a CTVD one.
(In reply to comment #8)
> Some parts of the bug still exists in Firefox 1.0, it's better, but there are
> still problems. Specifically I have seen (under CTVD):
> 
>     Text Input Fields won't take focus w/o switching to another app and
>     back to firefox.
> 
>     Menubar selection stops working (e.g., selecting a bookmark does nothing.
> 
> Since this only happens in firefox, and did not occur in earlier releases it
> seems to me that this is a firefox bug and not a CTVD one.

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7)
Gecko/20050414 Firefox/1.0.3:

WFM.

Window switches as described in the original complaint function fine. Mac X.2.8
here. Window raised in front of other window when selected on window regions
other than the title bar.

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.