Bug 339711 - Firefox triggers compiz bug causing compiz to cube rotate when firefox issues an activity notification
Firefox triggers compiz bug causing compiz to cube rotate when firefox issues...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: compiz (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-19 09:45 EDT by Jesse Keating
Modified: 2014-01-21 17:59 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:07:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2007-10-19 09:45:39 EDT
Given that you have a firefox window on one face of the cube, and you are on
another face.  If you click a link firefox will issue a notification to the WM.
 This will cause compiz to rotate the cube to the face that has firefox.

In the past I could have sworn that what would happen instead is the window list
in the gnome panel for all the faces would grow a firefox entry that would
pulse.  When you were ready to go read the links you have opened (many of us
open a large set of links as a read queue) you could click the pulsing window
entry and /then/ compiz would rotate you to the desktop that had firefox.

Even if the above isn't viewed as a "bug" then there is an actual bug with the
current behavior in that when the cube does rotate, the firefox window isn't
brought into focus.  If it had been behind say your email window you'll get
rotated to a cube and be looking at email instead of firefox.  If we decide that
rotating the cube instantly is the way to go than this bug should be fixed.
Comment 1 Rex Dieter 2007-10-19 10:04:19 EDT
afaik, no other WM switches virtual desktops like this, so imo, neither should 
compiz.  Otoh, it *is* a (arguably nice) new feature, so making the behavior 
configurable (default off) may be a nicer way of initially introducing it.
Comment 2 Jakub 'Livio' Rusinek 2007-10-19 10:07:59 EDT
I want it to be disabled by default and changeable.
Comment 3 Simo Sorce 2007-10-19 10:09:54 EDT
It's an incredibly awful "feature".
Many times I get a list of links I want to click (Ie in a mail on or IRC), I
don't want to need to switch virtual desktops at every click, nor I should be
forced to keep firefox in the same virtual desktop to avoid the problems of this
feature.
A pulsing tab is all we need, users can understand perfectly what it is about,
and, rotating when clicking on such pulsing tab would be ok.

My 2c
Comment 4 Seth Vidal 2007-10-19 10:10:53 EDT
blasphemy: make it an option
Comment 5 Charles R. Anderson 2007-10-19 10:15:09 EDT
I agree with those above that this "feature" is bad.  I'm already upset that
Metacity steals focus away from me when a new application launches on the *same*
desktop, right when I'm typing e.g. my password into a gnome-terminal. 
Switching workspaces/cube faces would be even more annoying.  I like the idea of
the pulsing window list entry on every desktop, like how Metacity works now in
this regard.
Comment 6 Mamoru TASAKA 2007-10-19 10:18:32 EDT
While usually I don't turn compiz on, I dislike the recent feature
of firefox that when I click some link  firefox immediately jumps to
the working desktop and I have to move back to the original desktop...

If this feature is configurable, I would appreciate it.
Comment 7 Tomasz Torcz 2007-10-19 10:20:58 EDT
Metacity pulsing bahaviour is good. Compiz rotating is bad.
Comment 8 Thorsten Leemhuis 2007-10-19 10:22:56 EDT
same here -- this "feature" would totally destroy my normal workflow (which is:
reading rssfeeds in thunderbird using rss2email and clicking on lots of links
(sometimes about twenty or more links for my morning mail session); those are
opened in Firefox which runs on a different virtual desktop; once I'm through
all my mail and rss feeds I switch to Firefox and read everything)
Comment 9 John Dennis 2007-10-19 10:24:54 EDT
This feature is really really annoying. Make it configurable, set it OFF by default.
Comment 10 Will Woods 2007-10-19 10:28:56 EDT
There's a damn good reason that the "When I open a new tab, switch to it
immediately" behavior is *optional*. If that setting is disabled the user is
clearly saying "I want to be able to open a bunch of dang links in the
background, and read them at my leisure." This is especially true when combined
with "open new windows in a new tab". 

The desired behavior - "don't bother the user by switching windows when s/he
opens a new tab" - should be the same whether you're loading links from within
Firefox or from outside it. 

If adding an option flag for this is too difficult (remember, OS X will have
virtual desktops starting next week) I'd really prefer the all-desktop
pulsing-window-item, as with metacity. 

If that's too tricky to do in time for F8 I suggest that at *least* the
workspace/desktop change should only happen when "When I open a new tab, switch
to it immediately" is set. 
Comment 11 Emmanuel Seyman 2007-10-19 10:31:57 EDT
Agree with comment #7.
Pulsing sounds like a logical consequence to clicking on a link,
rotation less so.
Comment 12 Thorsten Leemhuis 2007-10-19 10:36:43 EDT
BTW, it's IMHO bad enough already that we have two different window managers for
Gnome already (Compiz for composing desktops and Metacity for the others); but
if they act differently like in this case then users just get annoyed and
totally confused -- we should really try to avoid that the best we can. There
are IMHO way to many small things that feel differently already when using gnome
with metacity and using gnome with compiz. 
Comment 13 Kir Kolyshkin 2007-10-19 10:39:26 EDT
To my mind, a sane behavior would be to add a flashing firefox item in a window
list, and only when you click on it, it will take you to whatever desktop your
firefox is. Changing desktops after link clicking is insane.
Comment 14 John Sage 2007-10-19 10:46:27 EDT
My two cents:

Please disable the automatic rotation, I want to read the links when I've
finished whatever my current activity is.  I don't necessarily need a pulsing
window list entry, but nor would it bother me.

thanks,
john

Comment 15 Jesse Keating 2007-10-19 10:49:21 EDT
http://www.pastebin.ca/742422  Here is a patch from Danny Baumann to implement
the pulsing window list entry option.
Comment 16 Jesse Keating 2007-10-19 10:53:44 EDT
(In reply to comment #15)
> http://www.pastebin.ca/742422  Here is a patch from Danny Baumann to implement
> the pulsing window list entry option.

http://www.pastebin.ca/742437 is a better version of said patch.
Comment 17 Danny Baumann 2007-10-19 11:01:21 EDT
I'd like to point out that my patch linked in comment #16 works with libwnck >=
2.20 only. Older versions of libwnck don't show taskbar items for windows with
demands_attention hint in other viewports.
Comment 18 Douglas Furlong 2007-10-19 11:02:49 EDT
I just wanted to say that I echo Jesse Keating's desire mentioned on his blog.

"What I would /love/ to see is that when I click on a link and firefox opens it,
every cube face's window list grows a firefox entry that pulses. At my choosing
I can click on this pulsing item and /then/ compiz would spin the cube to
wherever firefox happened to be."

http://jkeating.livejournal.com/46640.html
Comment 19 Peter Robinson 2007-10-19 11:24:28 EDT
Firefox has an option for when you open something in a new tab whether to switch
to it immediately. Maybe you could check that setting. If set move to the
window, else just open the tab and leave it on the current vDesktop
Comment 20 Mark Knoop 2007-10-19 11:41:17 EDT
I would like to see (at least an option for) a slightly different behavior.
Instead of a link opening in firefox on another desktop, a new browser window
should open on the current desktop. 

Use case: coding a website on one desktop with a text editor and firefox to view
the result; reading email and news feeds on another. 

I don't want the youtube link emailed to me to open in the firefox on my coding
desktop, and I don't want to have to think to open a blank firefox window on my
email desktop.

I seem to remember this was the gedit behaviour for a while, at least with
metacity, but just tried it with compiz and the cube spins as this bug
describes. So it would seem that this is not just about firefox.
Comment 21 Colin Walters 2007-10-19 12:27:10 EDT
Can someone tell me what behavior Compiz has in the single-desktop case?  If a
friend sends you a link in say X-Chat or Pidign, and you click on it, does the
browser appear or does it pulse in the taskbar?  I would like to share the
behavior on this instance with Metacity, which is to have the browser appear.
Comment 22 Pablo Mejia 2007-10-19 12:37:39 EDT
Changing desktops when I click a link is insane.  I regularly queue up a bunch
of links from email.  It would be *extremely* annoying to have the window
manager switch desktops for me.  I haven't seen this yet (still use metacity),
but I'm sure I'll switch to compiz.

However, I do think adding a pulsing entry to the window list in every workspace
is useful.  I think that should happen for any window that wants attention.  If
some people insist on being automatically switched to those windows, they can
have a configuration entry.

I really can't stress enough how annoying this behavior would be.
Comment 23 Toshio Ernie Kuratomi 2007-10-19 14:37:13 EDT
I was thinking that a notification bubble would be better for my usual behaviour
which is:
  1) Click lots of link.
  2) When I have a few moments switch to the desktop with firefox.
  3) Read and close some of those links.

In this case the notification would tell me that firefox had loaded the page and
then get out of my way so I'm not feeling pressured to click on this throbby
button in my taskbar.

OTOH, there are a few times when I click on a link and want to go to firefox
immediately.  When this happens, having a button in the taskbar might be nice
for clicking on.  However, for my particular usage, I'd much rather click the
link and then use a keybinding to rotate to the desktop which has firefox.

So my vote is for a notification message rather than a button in the taskbar.
And definitely no desktop switching.
Comment 24 Christopher Aillon 2007-10-19 16:43:50 EDT
I see a lot of people who use metacity on this bug.  Metacity is a whole
different issue and *fixed already*.  This is for compiz only.
Comment 25 cam 2007-10-19 18:46:55 EDT
I think this is clouded by it involving Firefox and cube workspaces. Ask
yourself if any other app was involved instead of Firefox, what would the
solution be?

I imagine any other app would be expected simply to open a new window on the
current desktop.

If we are to make special provision for Firefox, why? Because it has tabs?
Because it's such a focal application?

The glowing tab idea is a great start. But if we give Firefox special treatment
I'd personally like to see it extended to the full range of mouse clicks used in
Firefox being available on URLs in other apps - left click to open in a current
window; middle click to open in a tab (with options in Firefox for that to be in
the background); right click to give the drop down menu "Open in window... Open
in Tab... Save As... Bookmark etc.

That would give a consistency and utility that makes it worthwhile going against
 the rubric of simplicity. Somehow I doubt it will happen; even Thunderbird has
different click semantics for URLs in mail messages.
Comment 26 Toshio Ernie Kuratomi 2007-10-19 20:37:29 EDT
(In reply to comment #25)
> I think this is clouded by it involving Firefox and cube workspaces. Ask
> yourself if any other app was involved instead of Firefox, what would the
> solution be?
> 
> I imagine any other app would be expected simply to open a new window on the
> current desktop.
> 
There was a comment on Jesse's blog that this should be decided on an app by app
basis which I actually agree with.  For firefox, opening a tab in the background
is ideal.  For gedit, opening a new window on the current desktop would be best.
 (incidentally, both of these currently take me to the desktop that already has
an open application window instead of my ideal behaviour.)

I think a new window would be a reasonable default (as long as focus doesn't go
to the new window).  I haven't been able to imagine any apps for which changing
workspaces is my ideal action.
Comment 27 David Timms 2007-10-20 10:03:12 EDT
If I were to use compiz, I would definitely dislike the different workspace
being brought in to view. Mostly for the same reasons:

1. I know most web sites wont be instantly visible even with ADSL2 internet
access speeds. Forcing me to view the browser while it goes of and does it's
thing would be a waste of time and disruptive. {As an example: click a redhat
bugzilla link - this takes close to a minute before the page finishes displaying}.

2. I often read an email that presents short summaries and provides links to
articles. In terms of reading the email - I prefer to completely finish the
email by scanning the summaries, and either ignoring or clicking {to open in new
tab} each interesting site, and then deleting it.

3. On average I think people don't have internet access and throughput speeds
that mean that any site selected could instantly {<0.5sec} be displayed. This is
one of the great things about tabs - google search: search, scan, ctrl-click,
ctrl-click, next, scan, next, ctrl-click etc.

Some text for thought - if you have a 1920xwhatever screen, it could be nice for
a link click to cause the web page to load in the background and then when it
completes, shrink the current app to half screen width, and then place the
completed web page load in the second half of the screen.
Comment 28 Oron Peled 2007-10-20 15:59:47 EDT
Many multi-workspace window managers behave as you proposed:
1. Pulse a entry on the taskbar.
2. Clicking on a taskbar entry (pulsing or not), brings the relevant window
   to focus and (if needed) moves to the owning workspace.

So making compiz behave accordingly keeps a consistent user experience and does
not need adding an extra option.

[for the record, I use KDE with kwin]
Comment 29 Charles R. Anderson 2007-10-26 20:49:14 EDT
I'm no longer seeing this issue.  Now instead links open in the Firefox on the
other desktop, but no throbbing taskbar item is created either.  I think it
would be nice to have the pulsing taskbar.

Re Comment #21, how do I change the number of desktops in GNOME/compiz to 1 so I
can test what the behavior is with a single desktop?
Comment 30 Charles R. Anderson 2007-10-26 21:15:16 EDT
Ah I found out how to configure compiz:

yum install gnome-compiz-manager
gnome-compiz-preferences

I set the Workspaces to Classic, 1 desktop.  When right-clicking a link in
gnome-terminal, Firefox opens the link immediately but it doesn't steal focus
UNLESS you are using "Select windows when mouse moves over them" and the pointer
happens to end up in the Firefox window when it is raised to the top.  With
standard click-to-focus, Firefox isn't raised to the top at all.

I set the Workspaces to Cube and Rotation, with Number of Desktops set to 1, and
the behavior is the same as above.

I set the Number of Desktops back to 3, and it continues to work fine (i.e.
Firefox does NOT warp to the current desktop, and the current desktop is NOT
changed to the one where Firefox lives).

Overall, this seems to be the desired behavior, except for the possible
enhancement of the throbbing/pulsing task bar entry.
Comment 31 Danny Baumann 2008-03-04 03:44:06 EST
The patch in comment #16 is now commited in upstream Compiz. While testing them,
I found a problem in libwnck's handling of demands_attention windows (AKA
glowing task bar entry) in other viewports.
There's a fix available (see http://bugzilla.gnome.org/show_bug.cgi?id=520124),
so if a version of Compiz from git head from today onwards is packaged, this
libwnck patch should be used as well.
Comment 32 Bug Zapper 2008-05-13 23:26:34 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 33 Bug Zapper 2009-06-09 18:58:00 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 34 Bug Zapper 2009-07-14 14:07:19 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.