Closed Bug 404732 Opened 18 years ago Closed 18 years ago

Firefox switches to current virtual desktop when opening new link

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jkt, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1 For all I know this is intentional, but is definitely a change in behavior from Firefox 1 and 2. With an already running Firefox session on virtual desktop 2 (for example) go to desktop 1 or 3 (anything but two) and choose to open a link. The current Firefox window will jump to that desktop and open the link, leaving any other Firefox windows on desktop 2. I'm seeing this under RHEL 5.1/x86 on a Lenovo T60p laptop. Reproducible: Always Steps to Reproduce: 1. Open firefox on one virtual desktop 2. Open a link from a different virtual desktop 3. Actual Results: The active firefox window will relocate to the current desktop and away from other open firefox windows. Expected Results: Link open in current firefox window, but the window itself stays on the desktop where it was originally active and doesn't "jump" to the active desktop.
With compiz effects enabled on Ubuntu Gutsy and using FF3b1, the cube rotates to the original desktop and opens the link in that window. Here are my steps to reproduce: 1. Open firefox 2. Browse to www.digg.com 3. Switch to another desktop 4. Open xchat and sign on 5. Have someone message me a URL 6. Right click on the link and select "Open Link in browser" Results: Cube rotates to the original desktop and the URL is opened in the original Firefox window in a new tab. Could you try these steps that I indicate above and let us know what happens?
I'm not running compiz, just multiple desktops via GNOME with RHEL5.1. Following your reproduction steps above, selecting "open link in browser" results in the Firefox window moving to the current desktop (the one running xchat) and opening the selected link in a new tab.
Just out of curiosity, could you try running firefox with a new profile and follow these steps? If you need help doing this, let me know.
Creating a new profile didn't change the behavior. The firefox window still jumps to the active window in which I've indicated a link is to be opened.
Do you know which Fedora version RHEL 5.1 is based on?
RHEL5.1 ships with firefox-1.5.0.12-3.el5, but I've installed 3.0b1 via tarball and that's where I'm seeing the problem. I do not see the issue with either 1.5 nor with 2 . . . just with the 3.0b1 code.
Is there any other information you can give me, like install locations or anything else. I want to create a VM that mimics your current configuration as accurately as possible. Thank you.
tarball exploded to /usr/local/firefox3. I'm running RHEL5.1 with SELinux running in enforcing mode with the targeted policy (just for info . . . I'm getting no messages from selinux, so I don't think this has anything to do with it.) I'm running on a IBM/Lenovo T60p laptop with an ATI Mobility FireGL V5200 video card and the GNOME desktop. I'm running 6 virtual desktops. Some other possibly important items: xorg-x11-server-Xorg-1.1.1-48.26.el5 xorg-x11-drv-vesa-1.3.0-8.1.el5 (I'm running with the vesa driver) Not really sure what other information would help, but let me know and I'll be glad to collect it.
I do not know a lot about RHEL except that it is typically based on a version of Fedora. Do you know what version of Fedora RHEL 5.1 was based off?
FC6 IIRC.
ok, I will work on getting a FC6 vm set up for testing since I cannot get access to RHEL 5.1 without shelling out some cash. I will let you know what I come up with.
Sorry, I have not been able to check into this yet as it is exam time. Rest assured that I have not forgotten about you. I will investigate this further next week.
I can confirm identical results running FF3b2 under Ubuntu 6.06. From both my email client, and xchat, FF3 is brought to focus in the current workspace instead of the one in which it was residing.
Ok, I confirm this using Fedora 6 and Firefox 3 Beta 2. I am also able to confirm on Ubuntu 7.10 but only if the visual effects are disabled. (ex. if desktop cube is enabled, the cube rotates to the correct virtual desktop for firefox to load the website).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Since there doesn't seem to be any priority or target version info on this bug, I just want to point out that, in my very humble opinion, this bug desperately needs to be fixed before Firefox 3 is released. It's extremely annoying to the point where I think I am going to downgrade from beta 2 to stable (and I've run a lot of beta versions of Firefox).
Turns out that sitting around the lunch table talking to the GNOME developers is a good thing. This doesn't appear to be a Firefox bug. Instead it appears to be a metacity bug (http://bugzilla.gnome.org/show_bug.cgi?id=482354)
This behaviour is new to beta3 though - why is the window being gtk_window_present()ed at all? A common use case is to click through links in say, an email application, and then switch to the workspace (or manually present firefox) with firefox in it and going through the tabs - without having firefox present itself on each click.
The following diff fixes this bug and numerous other incredibly annoying focus stealing bugs. Please apply. :~/src/mozilla/widget/src/gtk2 $ diff -upd nsWindow.cpp nsWindow.cpp-fixed --- nsWindow.cpp 2008-03-14 12:17:34.000000000 +1100 +++ nsWindow.cpp-fixed 2008-03-14 12:16:53.000000000 +1100 @@ -783,6 +783,7 @@ SetUserTimeAndStartupIDForActivatedWindo NS_IMETHODIMP nsWindow::SetFocus(PRBool aRaise) { +/* // Make sure that our owning widget has focus. If it doesn't try to // grab it. Note that we don't set our focus flag in this case. @@ -883,6 +884,7 @@ nsWindow::SetFocus(PRBool aRaise) LOGFOCUS((" done dispatching events in SetFocus() [%p]\n", (void *)this)); +*/ return NS_OK; }
Component: OS Integration → Widget: Gtk
Product: Firefox → Core
QA Contact: os.integration → gtk
Version: unspecified → Trunk
This bug, as filed, is not new to beta3, since the first 15 comments were about beta2. If you have a different bug that is new to beta3, please file it.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
(And please hassle the GNOME people to fix that Metacity bug.)
Sorry, I meant new to firefox 3 beta X, as opposed to firefox 2.0.0.12. I don't understand why firefox is now calling gtk_window_present() - the fact metacity does annoying things is irrelevant - I'm not sure why the window is being presented when clicking links from external apps.
(In reply to comment #21) > Sorry, I meant new to firefox 3 beta X, as opposed to firefox 2.0.0.12. I don't > understand why firefox is now calling gtk_window_present() - the fact metacity > does annoying things is irrelevant - I'm not sure why the window is being > presented when clicking links from external apps. > Because when you click a link, that means you're interested in looking at the site, no? Anyway, if you want sane behaviour use Compiz, they switch to the desktop that the window is on.
It does mean that, but not necessarily straight away. I regularly click several links from external applications, and then go to the browser to go through them - I don't want it presenting itself each click. Judging by the other comments in this bug, this is a fairly common use case.
The problem is if you have several browser windows floating around, possibly on different desktops, and the window that receives your external load doesn't present itself, then you have to dig around through all the windows and desktops looking for where the load ended up. That *really* sucks. A lot of users will assume the loads simply aren't working. Anyway, the GNOME people agree this is their bug and haven't suggested we change our behaviour. In fact I originally did the notification stuff to better integrate with GNOME so we could have this behaviour. So we're keeping it. It might be possible to implement what you want with an extension.
You need to log in before you can comment on or make changes to this bug.