User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8b) Gecko/20050207 Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8b) Gecko/20050207 Scenario 1 If there is nothing but a mailnews window open in workspace 1 and a navigator window open in some other workspace, focusing on the mailnews window and hitting ctl+1 does nothing. Hitting ctl+1 a second time, opens a new navigator window. Scenario 2 If there is nothing but a mailnews window open in workspace 1 and -two- navigator windows open, each in its own workspace, focusing on the mailnews window and repeatedly hitting ctl+1 does nothing. Reproducible: Always Steps to Reproduce: 1. Close all windows in all workspaces to reduce complications 2. Select workspace 1 and launch mozilla as a mailnews window. 3. Hit ctl+1 to open a new navigator window 4. Move the navigator window to workspace 2 5. Return to workspace 1 and focus on the mailnews window 6. Hit ctl+1 (nothing happens) 7. Hit ctl+1 again (new navigator window opens in workspace 1) Actual Results: After step 6, nothing happens Expected Results: After step 6, I would expect a new navigator window to open in workspace 1 Apple Powerbook G4 Linux 2.6.9 gcc 3.4.2 XFree86 4.4.0 GNOME 2.6.3 I admit that the system is a bit on the funky side. I started with a base Debian "sarge" install, bootstrapped a fresh gcc environment, and then built XFree86, GNOME, and mozilla from source. This was necessary to support my video card. I hope the funkiness has nothing to do with the problem I'm seeing.

If I recall correctly, the first Ctrl-1 press will try to locate and raise an existing browser window....

(In reply to comment #0) > 2. Select workspace 1 and launch mozilla as a mailnews window. > 3. Hit ctl+1 to open a new navigator window > 4. Move the navigator window to workspace 2 > 5. Return to workspace 1 and focus on the mailnews window > 6. Hit ctl+1 (nothing happens) Actually it raises the navigator window in workspace 1. It also appears to tell the window watcher that the navigator window is the current window. > 7. Hit ctl+1 again (new navigator window opens in workspace 1) When you hit ctrl+1 and the sole navigator window is the current window then a new navigator window is opened, although my new window opened in workspace 2.

As I see it the only issue here is whether a window should do something different when it's focused and determines that it's off the visible/usable/active part of the screen. The creation of the second browser in workspace 1 implies that we can make that determination. I suppose I could make a case that it should move onto a visible section, though I predict howling among the unix aficionados over a change like that.

Thank you for looking at this report and taking it seriously. I think it might be helpful to back up a bit and look at this from a use case perspective. As the user, my goal is to open a new navigator window in the same workspace as an existing mailnews window. Right now, it looks to me like the use case goes like this: 1) User searches all workspaces for an existing navigator window. 2a) If a navigator window is found, user focuses on it and hits ctl+1 to open a new navigator window. 3a) User moves the new navigator window to the workspace which contains the mailnews window. 2b) If a navigator window is not found, user focuses on the mailnews window and hits ctl+1 to open a new navigator window in the same workspace. If this use case describes the current state of affairs, it seems problematic to me that a user should be required to manually search through all workspaces in step 1. I think it would be better, if possible, to make Mozilla more workspace-aware in this context. I don't know anything about GTK programming, but is it possible to detect that there is an open navigator window and that it is in another workspace? If so, could Mozilla pop up a dialogue box that asks if I (the user) would prefer to open a new navigator window in the current workspace or jump to one of the open windows in another workspace?

I think we're just repeating ourselves at this point, though the idea of an alert asking whether to move the browser window as it gains focus is a new idea. Personally the fewer modal disturbances any application asks of me, the more I like it. I think I would prefer by default to bring the browser window onto the current workspace if it gained focus through a user-initiated action like ctl+1, but leave it where it sits if it gained focus programmatically. But we're probably talking about Yet Another Pref. Offering to switch workspaces for the user is probably not an option available to us. Interestingly on my Windows box (sorry, it's all I have) ctl+1 from the mail window does bring the browser window onto the current workspace/desktop, as does programmatic focus. I think my Windows multiple desktop system is much more simple-minded than the average unix equivalent. Still, whatever we did we'd have to be careful not to break that. We should probably fix this. I'm not the guy though, since I can't even see it happen.

If we change gtk_widget_grab_focus(owningWidget); to gtk_window_present((GtkWindow*)owningWindow->mShell); in nsWindow::SetFocus() as comment #1 in bug 295447. This bug disappears. The behaviour is bring the browser window onto the current workspace. But the "Confirm close" dialog is still wrong. Consider we have a navigator window A with 2 or more tabs in workspace 1, and another navigator window B with only 1 tab in workspace 2. If we press CTRL+Q within the navigator window B. A "Confirm close" dialog will be popped up in workspace 1 but we could not notify it. It's bad as we're going to press CTRL+Q time and time again with no responses.

To solve the "Confirm close" issue I mentioned in comment #6 --- xpfe/browser/resources/content/navigator.js 6 Apr 2005 04:17:42 -0000 1.567 +++ xpfe/browser/resources/content/navigator.js 30 May 2005 07:22:53 -0000 @@ -2484,4 +2484,5 @@ function WindowIsClosing() var shouldPrompt = pref.getBoolPref("browser.tabs.warnOnClose"); if (shouldPrompt) { + window.focus(); var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]

duplicate this, since I posted a patch on bug 295447 *** This bug has been marked as a duplicate of 295447 ***