*** Bug 125023 has been marked as a duplicate of this bug. ***

*** Bug 155870 has been marked as a duplicate of this bug. ***

Also note that some people have been requesting an option to set the maximum
button width. See bug 111961 for example.

This is quite annoying, and a distraction.
Even changing tabs in firefox will cause the tabs to be resized.

Can a decision please be made on how to fix this, and settle this once and for
all for 2.14?

I filed a bug on gentoo, which was marked UPSTREAM, and took me to a tracker
(bug 125023) - I don't know exactly what that means, but somehow I followed it
through bug 125023 to here.

My point is, I outlined some interesting behaviour in my original bug report
(http://bugs.gentoo.org/show_bug.cgi?id=93633).  I don't know if you're
interested, if you already know, or even if this is the behaviour that this bug
is already talking about, but I thought I'd let you know.  Sorry if its spam :)

Welcome fellow gentooer ^_^

Nightmare of a bug, has been around as long as the hills themselves. I've now
just given up caring.

*** Bug 317787 has been marked as a duplicate of this bug. ***

*** Bug 325411 has been marked as a duplicate of this bug. ***

Hmm, I obviously filed that specific bug (Bug 325411) *thrice* due to reloads and only noticed filing it twice. Anyways: It's also Bug 325439 where we have a patch attached to do the grouping dependend on different factors we chose (usage time being one out of three).
I think it would make sense to merge that bug into this one, but am not quite sure how to proceed with it because of all the comments I added there.

Furthermore we are likely to create a patch that lets you set the *standard* and *minimum* width of buttons. The standard width would always be used, up to the point that the windows don't fit into the tasklist anymore. Then we'll squeeze the windows until the minimum width is reached. At that point grouping starts, grouping that much, that there's room for two more windows to open, so that opening a new window won't lead to new grouping again and hence preventing a lot of shuffeling in the tasklist.

This bug is specifically about button length depending on the titlebar which is independent of grouping.  I appear to have missed or misunderstood your initial comments in 325411 in regards to grouping (otherwise I could have left open and retitled telling you to just take half the issues over to this bug), but your extra comments in bug 325439 make it clear that 325439 is geared specifically at how grouping is done.  So, it makes sense to keep these two bugs split as it really is two separate issues.

The patch you suggest for having a minimum size and a standard size sounds interesting; it would belong here rather than the other bug.  However, what would be the use of the minimum size be at that point?  I can't see any, so it should probably be nuked (and the maximum size too)  We may want to get the other libwnck co-maintainers to comment on whether there are any other reasons to keep those other options.  Anyway, two other points: (1) I like the standard width idea and my opinion would be that it should be active by default (though the amount could be tweakable as you suggested), (2) you need to think about and handle the case where tasklist grouping is turned off since tasklist grouping is, IMO, inherently busted, meaning that lots of people (the sane ones) will have it turned off.

Thanks for working on this.  :)

Also, please read the comments from the previous bugs (see the first comment in this bug for links). It can be interesting ;-)

Well: I've been reading many comments in the last half hour and it seems, that there's no clear direction of where to head with this.

Even after reading comments suggesting the opposite, my take on this still is that the size of the buttons should be independend of the title length. Lengthy titles usually are URL of some kind and are anyway cut off in a way that the important info is not visible. It's a matter of the applications to put the important information up front in a title.

As said above, I'd want to introduce a standard button width and a minimum button width, to resize as little as possible.
When with opening a new window the button size would be smaller than the minimum width, grouping will appear.

With having read Alex comment on some bug, where he complains, that the user should not be asked to define a number of pixels, I figured that instead of asking the user for the standard width, we could just as well asked him, how many buttons there should fit into the taskbar by default and from how many buttons on, grouping should appear (so don't nuke it :) )

This helps us to get rid of the option grouping yes/no, because if a user doesn't want any grouping, (s)he'll just go ahead and put a 1000 into the max number of buttons.

*** Bug 326026 has been marked as a duplicate of this bug. ***

(In reply to comment #12)
> Well: I've been reading many comments in the last half hour and it seems, that
> there's no clear direction of where to head with this.
> 
> Even after reading comments suggesting the opposite, my take on this still is
> that the size of the buttons should be independend of the title length. Lengthy
> titles usually are URL of some kind and are anyway cut off in a way that the
> important info is not visible. It's a matter of the applications to put the
> important information up front in a title.
> 
> As said above, I'd want to introduce a standard button width and a minimum
> button width, to resize as little as possible.
> When with opening a new window the button size would be smaller than the
> minimum width, grouping will appear.
> 
> With having read Alex comment on some bug, where he complains, that the user
> should not be asked to define a number of pixels, I figured that instead of
> asking the user for the standard width, we could just as well asked him, how
> many buttons there should fit into the taskbar by default and from how many
> buttons on, grouping should appear (so don't nuke it :) )
> 
> This helps us to get rid of the option grouping yes/no, because if a user
> doesn't want any grouping, (s)he'll just go ahead and put a 1000 into the max
> number of buttons.
> 

I just wanted to say that having a min/max value for the individual tasks is just simply a must. I bet there are so many people annoyed when XMMS(or some other player) changes to a song with a longer title and the tasks change their size. It's simply distracting.

Bug 339861, which I just filed (with patch), is somewhat related to this.

*** Bug 337123 has been marked as a duplicate of this bug. ***

*** Bug 343901 has been marked as a duplicate of this bug. ***

In regards to David's comment #12:

Until now, I thought it would be a good idea to have the button width determined by the title width. I now believe a fixed width based on a "Maximum visible buttons" setting would be more usable. However, I am not a fan of grouping in the event that more buttons are opened than the maximum number of visible buttons. Scrolling arrows (like those on a scrollbar) should be ever present to handle this.

I think the general consensus of opinion here is that the button widths should be fixed and only change as buttons are added or removed, but not dependent on the ever-changing maximum title width. However, there seems to be a lot of indecision about how to resolve some issues to everyone's liking, so this bug appears to have come to a standstill. I'll name the issues I see and some potential solutions for them in hopes of fueling the discussion necessary for finding an agreeable solution to the maintainers. I am an able coder and am hoping to submit some patches once the maintainers can agree on what needs to be done.

Many find it aesthetically unpleasing to have one button spanning nearly the entire width of their screen. Functionally, I can't see a problem with this besides users not recognizing the button for what it is because of its size. One way to restrict the button width is to have the user set a maximum button width in pixels. A minimum width could also be user defined in this way. However, as others have pointed out, this is not very user friendly as some users won't even know what a pixel is.

I propose having a "Minimum columns" setting which would evenly divide the list's width up among the buttons (basically what David was referring to in Comment #12). But what should be done when all the columns are filled and the user opens another window? The Firefox method is to reduce the widths of the existing buttons (tabs) to make space for the new button, but there is only so far a button can shrink before it becomes unusable. This is where a "Maximum columns" setting would be useful. But let's say the user sets this to 100 columns and they have a list width of around 800 pixels. That would make each button 8 pixels wide, which is not only ugly, but a bit unusable. So, while the layout logic should attempt to show as many buttons as possible, it also needs an internal minimum width to fall back on, which would most likely be the width of the application icon plus padding pixels.

In the event that the number of buttons exceeds the maximum columns, how are the hidden buttons to be accessed? There are four methods that I've seen used to handle this.

1) Add another row
Since users don't tend to be switching between more than five or six windows at a time, I have a hard time justifying eating into the available screen height with extra rows. Not only that, but a frequently growing and shrinking number of rows would be rather unsettling. This does not mean that the users shouldn't be able to have more rows, only that they should have to explicitly request them with a "Number of rows" setting (the default being one).

2) Pulldown menu

The standard way this is implemented is by putting an up or down arrow button (depending on where your panel is) to the right of the window buttons, which reveals a vertically stacked list of the hidden buttons. This can be seen in the "Launcher list" panel applet when space gets tight.

3) Window grouping by application

This is a very application-centric approach. I personally dislike it because it turns some of the visible buttons into grouping buttons, which forces the user to click twice to get to a member button of a given group. Besides, with more and more applications providing tabbing support, the opportunities for exploiting this are becoming increasingly rare.

4) Paging arrows
This has been used with Firefox tabs for some time and basically acts like a bi-directional ticker-tape.

Of these methods, pulldown menus and paging arrows seem equally usable, so I think both options should be available. The implementations of both should be able to handle multiple rows. I have a feeling that pulldown menus would be more usable in a multi-row environment and easier to implement, but since using a single row is the default, it shouldn't be a deciding factor as to which of these methods becomes the default. That should be decided by the results of usability tests.

As far as window grouping by application goes, it feels like a broken paradigm to me, so I'm presently all for ditching it. I'd like to hear the pro arguments for it from those who have it enabled. However, I am not opposed to manual grouping of windows and in fact think this would go a long ways towards reducing clutter and making focusing on the task at hand easier. My preferred method for doing this would be using the existing functionality of workspaces, but that is a topic in and of itself. Go here for a lengthier description of that (among other things UI related): http://live.gnome.org/DesktopInterface.

Hello John, I'd like to say that I'm happy to see someone finally offering to code patches for this after more than a year :) here are my comments on your possible solutions.

1) add another row: I'd kinda say this putting a band-aid instead of fixing the problem, I personally don't want this; besides, the applet already has multiple rows, if you size up the height of the panel enough you will see them spanning into multiple rows

2) pulldown menu: there is a "window selector" applet that does exactly that. HIG-wise, I don't like this being the default solution for "the window list applet", because it *hides* contents into a tiny dropdown menu, I don't think this is very good usability. Again I feel it's a band-aid too.

3) window grouping by application: not sure I'm following you here, doesn't the window list do that already by default? *even* then, the size "jumps around" in a crazy way. I agree with you that this is not really the solution (actually I think it is independent to the problem).

4) paging arrows: I recommend not using this. Epiphany users are screaming EVERYWHERE asking for this behavior to be ridden of with their tabs. See these:
http://ubuntuforums.org/showthread.php?t=124068
https://wiki.ubuntu.com/EpiphanyDefaultBrowser
https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/30749
http://bugzilla.gnome.org/show_bug.cgi?id=330676

I am one of them, I don't like it when I have 30 tabs and 5 of them are shown, even though I can use the mouse to scroll through them. I would even rather have a vertical "sidebar" using a gtk.ListView instead of that!


If you are willing to implement all of the above however, I personnally think it would be no problem. Just don't force them on users though, as I think the "firefox behavior" is pretty much the best out there.






Now, you noticed that I actually rejected all proposals above. I'm sorry, I don't mean to discredit any of your work, I am *GLAD* you have been thinking on this, however, this leads me to the big, nasty question: what the heck are we still doing with that paradigm of a window list on our panel? There HAS to be a better way to handle *lots* of windows without them appearing as 5x5 icons in the corner of a screen or something.

To tell the truth, I removed that applet because I simply could not stand it anymore, the jumping around, on top of the fact that it gets cluttered fast, is no match for accelerated window managers' capacities (I'm specifically thinking about the "scale" plugin from Compiz that is also available in Beryl).

I *think* the reason the Mac OS X dock was invented was to get rid of that problem; it can hold many, many items, but since it zooms, you will always be able to identify what is in it. I'm not a mac user, not an advocate of mac OS, I just read that somewhere on the net, and thought it made some sense. Of course this would need stuff like beryl/compiz, and such "docks" already exist (kiba dock for example).

I really don't know what else to say, except that you have my cheers and that this needs yet more discussion :)

Of course I'm only a HIG-oriented regular user, not a developer, so my opinion here is to be taken as "advice".


Bonus question: would you be willing to implement a way to display the window list correctly on vertical panels? This, imho, would fix a BIG part of the problem because I could use a vertical panel on the left or right of my screen, and it could hold a *LOT* more windows before becoming cluttered.

I hope I can make good on my offer. Although, I'm not about to start anything until I get specific approval from the maintainers.

After spending several hours reading through all those posts you listed, I've had some insights I'd like to add to my comments above.

1) Paging arrows

I don't recall ever experiencing the shock of losing my buttons, but I agree that every precaution should be taken to avoid scaring off new users. Several people suggested that part of a hidden button could be shown, to indicate where the hidden buttons have gone. This seems to be the approach that Firefox has taken. Although, I personally would prefer to just see a highlighted arrow indicating more, with a count of hidden buttons next to it. This may be less discoverable for a new user, so I wouldn't push for it being the default behavoir. Since Firefox uses this method and most users migrating to Linux will be fairly comfortable with it, I think it should be the default.

2) Pulldown menu

I can't think of a method for showing a partial button here, so this method would be less discoverable than the one mentioned above. However, I think it is a faster method for advanced users dealing with copious amounts of windows.

3) Adding another row

There were two quite valid arguments why users want this. First, more buttons can be shown at once, allowing the user to see more text and button highlighting. Second, more buttons are one click away. These are good reasons and so I am all for allowing the user to have this. However, I have yet to see a natural scheme for the movement of these rows in a dynamic environment of opening and closing windows. I personally wouldn't use this method because I would find it very disorienting, but it should still be an option for power users.

The first two methods do suffer from having more buttons hidden and therefore it would be easy to miss an active (highlighted) button. This is easy enough to fix though. They could just both highlight arrows to indicate activity in the buttons they hide. The active items in the pulldown menu would also be highlighted.

I agree with you that a vertical bar does seem promising, but few of us are willing to give up our prized horizontal width for a persistent vertical bar, no matter how useful it might be. I think the widescreens may change this for some. Also, a vertical button might be a bit harder to select. You are right though, the current vertical layout is too broken to be usable. It needs help.

To the extent the problem is gtk layout system limitations, I think things could be made to "just work" with a concept of both minimum and "natural" size in the size request, see:

 http://log.ometer.com/2006-10.html#14

However, panel<->applet API changes might be required also, i.e. it might be necessary to lay out the whole panel in a smarter way.

But then, did John Peterson speak with you devs after all? What's up with this one? Iirc, he was offering help and awaiting approval of some sort.

I don't see much alternative to adding "natural size" to the layout algorithm used, which probably means extending the panel applet API. There is a Summer of Code project to add "natural size" to gtk itself, which would make this easier, but I think it is not strictly necessary for this bug since the tasklist applet could use its own layout algorithm internally, and the panel can use its own layout algorithm also.

Anyway, to me that is clearly the fix and the bug is just waiting for a patch that does that. But I'm not the maintainer, just telling you what I would do.

*** Bug 361944 has been marked as a duplicate of this bug. ***

Created attachment 90415 [details] [review]
Fix the button size to w128/h30

I'm sending the proposed solution already discussed in the mailing-list:
http://mail.gnome.org/archives/desktop-devel-list/2007-June/msg00072.html

At the moment it's only possible to switch from "fixed" to "maximum" buttons size by editing the source code. 

If anyone can take the task to set the property defined in the WnckTasklist struct, which I added :
tasklist->priv->maximize_button

And set some gconf key attached to it, because I really can't do it (never touched gconf before).



Note: it doesn't change anything when using the tasklist applet in a vertical panel. But this is out-of-scope (need more editing).


Please check if the patch is correct, I'm not sure how to format/send it.

If a gconf key is needed I think it's an insufficient patch; it needs to be smarter. People should not have to set the pixel size of various desktop elements before their desktop is usable.

I'm glad to see thought and effort being put into this, but when did hardcoding pixel widths become the desired way of doing things? This seems like an attempt to push the problem under the rug with a hack. With screen sizes varying like they do today, it makes more sense for the user to set a preferred number of visible buttons (generally something between 4 and 8 buttons) and then make the default button width equal to the screen width divided by that number. You could think of this as dividing the screen width into parking spaces, which maintains a desired spacing and keeps things relatively surprise free. The only time this width would need to be violated is when the number of buttons exceeded the number of parking spaces. In this case, the width of all the buttons could just be reduced to allow in another (the current behvavior) or a button could be hidden and side scrolling buttons could be introduced to indicate where it is. Sure this takes more work than hardcoding pixel widths, but IMHO it is the most usable solution.

Havoc: the gconf key should be _only_ to say if you prefer to have big buttons that takes the whole width or not. 

It seems that some people report bugs saying "there is much space left and the button is just x pixels wide". But others like me prefer not to have big buttons that take the whole space.

So a checkbox would be sufficent, but you seems to refuses to add a property anywhere, so I proposed a gconf key. 




John Peterson: it's not possible to have the width space available for the whole applet. But I will try to do something else.

I'd use a number of letters, and not a pixel width. Sounds more sensible. (we should probably change the minimum width to use a number of letters too).

I have tried everything so far, and the only solution that seems to work good enough is the fixed size. I don't find _any_ other way of achieving the same result.

Also I am satisfied with this solution mostly because it fix this issue. And with a little more work it can be easy to switch between both solution, maximum size or not. And I know people want this.

We really need to push for better integration of the maximize_button flag.


I'm posting both results here so you can see for yourself.

maximize_button = FALSE
http://boby.joe.free.fr/files/tasklist-maximize_false.ogg

maximize_button = TRUE
http://boby.joe.free.fr/files/tasklist-maximize_true.ogg

I thought you were proposing a new behavior that while still not ideal, was
better than the old behavior so could fully replace it as the band-aid fix for
now. (Which sounds like an improvement.)

Do keep in mind that it is possible to just get this right for everyone by
default. The behavior shown in http://log.ometer.com/2006-10.html#14 (using
natural size) I think would be exactly what everyone would expect and leave no
reason to configure anything. This is a straighforward algorithm.

If putting in a short-term band-aid improvement, I would suggest leaving the
bug open and trying to get someone to still work on the full fix. In fact, why
not work on the full fix? It's probably not that hard!

I was confused about the gconf key, I thought you meant switch to the new
behavior only but make the pixel width configurable. That doesn't make sense to
me, I think a good pixel width default should be auto-chosen, considering
screen and font size if required.

Re: a gconf key to choose old short-term band-aid fix vs. new short-term
band-aid fix: this is awfully close to a "which bug do you want?" configuration
option. I always find it a bit embarassing to ask the user how they want things
to suck, when it would have been pretty easy to just implement a single working
behavior. "Which bug would you like today?" - the user is going to think "uh,
neither one... ?"

That said, as long as it doesn't make it into the GUI control panels and
remains a hidden setting, I guess it isn't a major crime. ;-)
But if anyone puts "[ ] change exactly how tasklist sucks" in a control panel,
please feel very ashamed.

Created attachment 90421 [details] [review]
Edited previous patch to use DEFAULT_WIDTH/DEFAULT_HEIGHT in place of some random integer.

This bring a new flag in the struct _WnckTasklistPrivate, which say if the buttons in the widget should use the maximum size available.

If set to FALSE, then it will use a limit to each button size which is the DEFAULT_WIDTH.

Havoc Pennington: I read your blog before, twice exactly.

I don't know if it will fix this issue. I have thinked hard about that. That's why I have started to set the fixed size, and it seems to work quite well.


I don't have any better solution yet, or I would go deep into it otherwise. 


Note that if you can explain to me where we should implement your idea, I will try to do it. So we can compare both in the results. 


By now I can't do that because I don't know where to implement this. Do I have to create a new size request function that override the default gtk_size_request behavior of the widgets ?

The implementation will include changes to gnome-panel, libwnck, and the wnck applet, I would guess.

You have to implement the natural size solution starting at the point where you know the maximum size you may want to cover. That is probably inside the panel; you probably have to change the size negotiation between applets and the panel, so the panel can ask the applet for both natural and min size. The panel then gives the applet at least min size, but will give it up to the natural size if the natural size is available, but will never give the applet more than the natural size of the buttons. i.e. there will never be "padding" in the buttons, just the actual text.

Effectively, the natural size is the 'max size' of the entire applet.

So step 1 is to have on the applet a method like:
 get_min_and_natural_size(int *min_size_p, int *natural_size_p);

If you can implement that such that the min_size is the size if every button is only a few pixels, and the natural size is the size if all buttons show all their text, and you set ellipsization on the buttons, then things will be almost good.

To get the final mile, you also have to use a min-and-natural algorithm to lay out the box of buttons. This algorithm is in HippoCanvasBox and could be copied from there.

To get both the individual min-and-natural size of each button, and the total for the whole applet, you would have to use some hack for now; but I think it's as simple as turning off ellipsization and getting a GtkSizeRequest to get the natural size, then turn on ellipsization and get the size request, to get the minimum size.

I don't expect what I just wrote here is 100% right, but it's along the right lines surely.

Maybe worth clarifying is that the size_request stuff in GTK returns the minimum size, not the natural size. For ellipsizable buttons, the min size is some arbitrary small number, and for non-ellipsizable buttons the min size should be the space needed to show all the text.

In a system with both min and natural size, for an ellipsizable button the min size is small but the natural is the full text width; and for a non-ellipsizable button the min and natural size are the same.

A final point is that the size request is only used by the container widget. So if you have a container widget like the GNOME panel or the tasklist widget, you are free to ignore the size_request from GTK (the min size) and instead use your own functions you add that get both min and natural size.

The idea here would be to 1) add "get natural size" functionality to panel applets and the tasklist widget and 2) make the container widgets that contain these two things aware of the natural size.

Using character widths to determine button widths seems like a bad idea to me, because the title won't always be in a monospaced font. When a proportional font is used (which is probably more often than not) the button width will fluctuate as the title changes. This is just what I thought we were trying to avoid.

What you can do though is similar to the "width in chars" you can set on a GtkEntry which really sets a pixel width (but based on the pixel width of some number of chars in the current font). For a proportional font, you just use an average or typical width since there's no fixed width.

The idea is to say "enough space for about 10 chars in current font" instead of using a made-up number of pixels.

(In reply to comment #38)
> Using character widths to determine button widths seems like a bad idea to me,
> because the title won't always be in a monospaced font. When a proportional
> font is used (which is probably more often than not) the button width will
> fluctuate as the title changes. This is just what I thought we were trying to
> avoid.

I was really talking about "average size of a character". We're already doing this in some places, even in libwnck (in the selector, eg). So this size will only change when the font changes.

I already tried to set the width as a number of char, but can't make it work.

Is anyone able to point out what function this is ?

I tried with gtk_label_set_width_chars

I'll attach three patches that implement a limit size for the buttons based on a number of characters. I needed to change libwnck, the window list applet and the panel.

Those changes also mean that the minimum and maximum size of the window list are useless now, but they'll get removed later.

The panel changes are bug fixes that were needed. It's not complete yet, since grouping windows on a non-expanded panels make the tasklist too big. But it's already good enough to use.

Created attachment 90516 [details] [review]
Limit size of the buttons based on a number of characters (libwnck)

Created attachment 90517 [details] [review]
Limit size of the buttons based on a number of characters (window list)

Created attachment 90518 [details] [review]
Limit size of the buttons based on a number of characters (panel)

I'd love to get some feedback from people who can test the patches. It seems to work well for me, but since I'm not a big window list user, I can't be sure that it "feels" right.

(Note: the window list applet is in the gnome-panel module)

Ah, also, there's no guarantee that it will work well on vertical panels, but, well, the tasklist on vertical panels is already totally broken, so...

I can't find a way to test this.

No problem to replace everything in the source code, and to start a new panel with the freshly compiled libwnck shared object. But I can't load any freshly applets. I just don't know how to do this.

I just wanted to test your patchs but I don't know how to.


With only the libwnck patched buttons doesn't shrink less than a certain size. But I suppose I have to use the patched applet to really call it a test.

I will try this when I understand how to.

(In reply to comment #48)
> I can't find a way to test this.
> 
> No problem to replace everything in the source code, and to start a new panel
> with the freshly compiled libwnck shared object. But I can't load any freshly
> applets. I just don't know how to do this.
> 
> I just wanted to test your patchs but I don't know how to.
> 
> 
> With only the libwnck patched buttons doesn't shrink less than a certain size.
> But I suppose I have to use the patched applet to really call it a test.
> 
> I will try this when I understand how to.

If you don't have everything installed in a prefix, I guess it will be difficult. Applets need to be registered for bonobo, and this is done using a file in /usr/lib/bonobo/servers. You can try putting a crafted file for your compiled applet there, but I don't know if it will work.

The best option is probably to compile a nearly complete GNOME stack with GARNOME or jhbuild.

Created attachment 90533 [details] [review]
Limit size of the buttons based on a number of characters (panel - take 2)

Update the panel patch to nicely work on non-expanded panels. It took two or three tries, but it should be okay now :-) The difficult case is when you have more than one applet using size hints on this kind of panel. So basically, the size hints are propagated to the toplevel.

Okay, I guess most people won't understand what I mean because you probably need to know panel code to understand this.

Anyway, please try :-)

Created attachment 90545 [details] [review]
Limit size of the buttons based on a number of characters (libwnck - updated)

Updated the patch to trunk.

After fixing the panel patch to work for drawers, I've committed all of them. It's the best way to have all this tested.

This will be in 2.19.5.

Just confirming that the behavior improved in 2.19.5. It is so much less annoying now, at least I can breathe again! Cheers.

*** Bug 461490 has been marked as a duplicate of this bug. ***