Version: unspecified (using KDE 4.6.0) OS: Linux I have a laptop that I'm using both in screen-attached and screen-detached mode. Whenever there is a screen attached to the HDMI output, it will use that, otherwise X.org will start on the laptop monitor. The two screens differ in size - my external monitor is 1920x1200, while my laptop monitor is 1600x900. Whenever I'm logging in, I always need to hit the panel settings -> other settings -> maximize panel button, as this is what happens: * Using biggest screen (1920x1200), maximizing panel * Log out, shut down * Detach monitor, restart, laptop monitor is used * KDE/Plasma starts, main panel is now still 1920 width and f.ex systray is unusable since it is now off-screen * Right-click panel -> settings -> other settings -> maximize * Panel is now correctly set to 1600 width The "same" happens when I'm done using my laptop monitor and reboot with my external monitor attached, only then the case is that the panel is now only 1600 px wide, and not using the full width. This is to be "expected" though, as I'm aware that the "maximize panel" does not function as a "setting", but rather as a shortcut to maximize the panel instead of having to use the sliders. Slightly unintuitive, but easier to live with than the other way around (going from 1920 -> 1600 with 320 px panel off-screen). Reproducible: Always Steps to Reproduce: * Using external screen (1920x1200), maximizing panel * Log out, shut down * Detach monitor, restart, laptop monitor is used * KDE/Plasma starts, main panel is now still 1920 width and f.ex systray is unusable since it is now off-screen * Right-click panel -> settings -> other settings -> maximize * Panel is now correctly set to 1600 width Actual Results: KDE/Plasma starts, main panel is now still 1920 width and f.ex systray is unusable since it is now off-screen Expected Results: KDE/Plasma starts, main panel should only be max the size of the screen space available - in this case 1600 px max.
if you stop plasma-desktop, remove plasma-desktoprc (note: NOT plasma-desktop-appletsrc) and then start plasma-desktop again does it start behaving properly? if not, can you please attach your plasma-desktoprc to this report. thanks.
*** Bug 218686 has been marked as a duplicate of this bug. ***
I stopped plasma-desktop and removed the plasmadesktoprc file ~$ kquitapp plasma-desktop && mv ~/.kde/share/config/plasmadesktoprc ~ Plasma quit, and upon restarting plasma, I noticed that the panel layout (I have a second panel that is aligned center-top) was now reset. Upon reboot, when detaching the external monitor, the reported behaviour still persists. I'm attaching both the old plasmadesktoprc and the one generated after removing it, here.
Created attachment 56729 [details] plasmadesktoprc file initially used, experiencing error described in the bug
Created attachment 56730 [details] plasma-desktoprc file autogenerated after removing original file
This causes quite some pain for me. I also would be happy if there would be an option to always make the panel stretch to the whole display width or height.
*** Bug 265261 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
I am quite curious wether we see a fix for this in 4.6.2 or .3 Every major breaks some critical things for me, in the other side most fixes are only pushed to the next major. I wouldn't have upgraded to 4.6, if there wouldn't have been some ugly bugs in 4.5.5 without any hope for fixes.
I confirm the bug. I have a laptop capable of 1920x1200. When I am at work, I use the laptop connected to an external monitor only capable of 1680x1050. I go to work, I attach the monitor, I use xrandr to activate it and disable the laptop screen. Panel does not realize it and keeps stretching outside the available space. Need to unlock widgets, go to panel settings, maximize panel, lock panel settings. Boring to to it every day.
Behaviour is not limited to reboots. Also exists when switching Monitors (e.g. when putting a Laptop on a Docking Station). I am using an nvidia card and disper to change the monitors.
I confirm the bug. KDE 4.6.1 - Kubuntu 10.10 64bit
As one disturbing bug is fixed, others are introduced. I haven't had that I felt comfortable with since KDE-3.5.10 - there the only problem I has was kicker crashing from time to time. Guys, would it be so hard to make 4.7 a stabilization release only, with a longer release cycle to get all that problems ironed out, instead of the usual catch-up with bug-reports?
Clemens: I totally agree with your statement - but I doubt that a "minor" ticket is a good place to raise such issues. I have seen many users confirming this back so far; but no reaction from KDE developers. Maybe you should turn to the KDE forums with such proposals (forum.kde.org). Who knows who is really following up what is happening in this ticket ... obviously "confirmed by popular vote" doesnt mean that someone started working on it ... or?
Duplicate of bug209962 ?
(In reply to comment #15) > Duplicate of bug209962 ? Hopefully ... as the one you are pointing to just to a fix ...
This bug is not a dupe... I keep switching between laptop and external screen, for a few years now, and this bug hit me first with kde 4.6 beta 1, whereas bug209962 seems to be much older.
+1 same annoying bug here (KDE 4.5.1, Kubuntu)
I'm experiencing a similar problem that started with KDE 4.6.0. Steps to reproduce: 1. get a laptop and plug an external monitor with higher resolution than the laptop's display. 2. use xrandr to set the resolution of this monitor and place it to the right/left of the laptop's display. Now I cannot resize the main panel to full width of the monitor. As a workaround, I have to turn the laptop's display off with xrandr, resize the panel, and then turn it on again.
Are there _any_ KDE developers reading this? I mean, we have some votes for this bug; we have many many repros ... but no developer to take care of it?! This is somewhat annoying. I would assume that it is NOT rocket science to fix such problems?!
Nope, nobody reads this. They are all busy implementing social media integration and hyper-realtime-indexing fluff which is far more fun than to work on the Taskbar/Panel.
Remember Poe's law before making such comments. After all, FOD (fun oriented development) is an established practice.
Jep, I am sorry. I am glad you guys work on KDE, however its a bit disillusioning to see *core* things broken from release to release and to see some core-feature (like the Task Manager) only very limited bug-fixing at all simply because, well, its not that cool to work on such stuff. And if things get fixed, often its only fixed in the next major, guess what ... where other things are broken again.
There are definitely Developers reading this, but you rambling on about Votes and enough reproductions of the bug does not help. Maybe they are already on it, it just turns out to be more difficult than they imagined. Also: Most KDE-Developers give a sh** about the votes, most probably would like to see the voting system dismantled as it is not a good indicator for the severity of a bug. It mostly just means that someone has convinced a lot of people to "vote" for said bug…
One could reverse the argument that "rambling doesnt help". As on the other hand, it doesnt "help" if someone starts to work on a ticket ... but doesnt tell. The point is: a KDE user has problem and reports it ... and then just stares at his ticket that gets not updated by a developer - not exactly motivating, too. Worse - because there is no visible indication that someone "in power" sees the problem ... people get the feeling that nobody is listening. Therefore more complaints ... and rambling. A simple status change to "assigned" or a message from a developer who intends to work on the problem would stop the discussions that we now have in the first place. Even a "I started to look at it, and it is really complicated to come up with a good solution; and that will take some time" feels much better than the no-updates-at-all that we users witness in here for days, weeks, almost months ... Communication is key; and it _could_ be a great differentiator between KDE and gnome.
still in 4.6.2
Confirmed for Kde 4.6.2 in Kubuntu Natty Beta. After attaching a larger external monitor I need to first change the screen edge forth and back to be able to maximize the panel. Why isn't this happening automatically and is there a possibility to do this via a script (as a workaround)?
Confirmed openSUSE 11.3 and openSUSE 11.4 -- KDE 4.6.0 Seems to be the same as Bug 266112 and Bug 249524.
I keep my panel on the right hand size and after removing the external monitor and running xrandr --auto it is still on the left hand size which is *outside* of the laptop's screen. This makes it downright impossible to use KDE after undocking.
So this is the panel - one KDE's core components. Its broken for a not-so-uncommon situation (switching resultions), even worse its a regression introduced in 4.6. The report has been filed almost 3 months ago, has 174 votes and even a polite mail to the kde-devel list hasn't tracked any attention to it. Basically this means I need to find another desktop environment.
@clemens There is a continuation of the KDE3-branch called "Trinity", if that's what you are looking for: http://www.trinitydesktop.org/
@Alvaro: that sounds like a step backwards. I think that NOONE who starts using KDE today would seriously regard 3.x as an option. This means that the user base is never going to grow. So instead of keeping something alive that WILL die anyway ... why not help making KDE 4 better? KDE 4 is now a pretty decent desktop environment; some of its applications are really really great. But obviously there is a quality problem. That should be addressed in the very first place. For myself, I installed xubuntu 11.04 on my machine; and if it doesn't fail too miserably, KDE is out of the game for me.
@Ed: I haven't had a bug-free* KDE desktop since I switched to 4.1 - always believing the promises that the next version will be much better. The next major appeared, fixed a few things and broke others. I am too tired of that game. Sure 3.5 is a step back, but I don't have much hope for quality improvements. The quality problems are going on far too long - and in my opinion are caused by the way things are done. Way too many features and different programs and too short release cycles for the few developers working on it. * bug-free in the sence that I did not have to arrange myself / work arround with broken core components like panel, plasma, dolphin, kwin or kmix. And yes, pluging out a usb-soundcard and having kmix crash every second time is what I call a fail - also having kopete kill plasma each 3rd time I exit it is a joke.
Could you people PLZ go to the KDE forums and have this Meta-Discussion there? That's what they're there for…
Agree about moving the meta-discussion, but the bug remains. Once you fill your monitor with windows you're working on, THE kde thing you still see are window decorations and the panel, so IMHO this is not a minor bug. Anyway, I'm grateful for the developers' work (although now i moved to Gnome 2.x beacuse of this).
That was fast! Coming back from Unity and Gnome Ubuntu mess... Please... solve this bug (or perhaps a workaround: a keyboard shortcut to max the panel). (In reply to comment #35) > Agree about moving the meta-discussion, but the bug remains. Once you fill your > monitor with windows you're working on, THE kde thing you still see are window > decorations and the panel, so IMHO this is not a minor bug. Anyway, I'm > grateful for the developers' work (although now i moved to Gnome 2.x beacuse of > this).
Created attachment 59485 [details] Screenshot showing wrong width of panel tool box Let us be objectively again, please. I'm going to try to give some more details on this problem in my setup (laptop with external monitor). My guess is that the panel gets maximized - but at the wrong size. If you take a look at the panel tool box, you can see that it has always the width of the internal monitor. If you choose "maximize panel" the panel is brought to this width. After flipping the panel to another border of the screen and back to the bottom, the width of the panel tool box is correct. Then you can choose "maximize panel" to get it across the entire width of the screen. When rebooting without an external screen the panel tool box keeps the width of the external monitor - which is wider than the laptop-monitor. So in both cases the width isn't recognized correctly. The attached screenshot shows the wrong-sized panel tool box with the panel in the correct size as it appears for example after hibernation.
I'm sure this bug isn't resolved yet only because the maintainers lack the time or motivation to fix it. The problem with the panel is something very easy to notice, reproduce and probably to fix too. We should stop wasting our time "confirming" this bug. It will obviously stay there until someone intentionally fixes it and closes this report.
This bug made me switch to XFCE. After absolutly no response to an email to kde-dev (read: no one cares at all), I have no hope for KDE to get better anytime soon. I have 45 open bugs, many filed during the kde-4.2/4.3/4.4 beta testing era, there is just nobody fixing that stuff. Every release other stuff gets broken and I have no hope left that things will change for the better.
(In reply to comment #38) > I'm sure this bug isn't resolved yet only because the maintainers lack the time > or motivation to fix it. The problem with the panel is something very easy to > notice, reproduce and probably to fix too. We should stop wasting our time > "confirming" this bug. It will obviously stay there until someone intentionally > fixes it and closes this report. Yes, you're right. But I hate this bug and I hope, the KDE devs fix it soon. But I have a "workaround": 1.) Here is a Javascript-File: ----------------------------------------------------------- panelById(panelIds[0]).length = screenGeometry(0).width; ----------------------------------------------------------- Save this as "panel.js" 2.) Here is a (bash-)script: ----------------------------------------------------------- #!/bin/bash qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /home/......./panel.js xdotool key ctrl+e xdotool key alt+F4 ----------------------------------------------------------- "xdotool" simulate keys. It's in the repository of (K)ubuntu. If you change your display, you should run this script. PS.: Sorry for my english. ;-) I hope you understand me.
Created attachment 59494 [details] Javascript-File
Created attachment 59495 [details] Bash-Script
For those willing to take a look the code of the panel is here: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/show/plasma/desktop/containments/panel It seems there has been an attempt to fix the issue "make autoresize work again": https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/6a3aeff8ce3fb3a7787233fdb3fbfebdce7514d2 but, as it seems, it's just not enough. BTW: comment #37 is related to bug #256377
This is the KDE 4.6 version of the patch: now I'm wondering why it's not working. Is anyone in here able to debug the code? https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/0d44a8a4c6a7c7a9d4a2c2aa8ce31805862711e6
I created a thread in kdeforums to move the "meta discussion" there: http://forum.kde.org/posting.php?mode=post&f=15&sid=4f69c8d5e2919738ba19dc22cc464cf8
Damn, wrong link. http://forum.kde.org/viewtopic.php?f=15&t=94870
@Ed do you realize that you are polluting the thread just like the others, right? Besides, even though the KDE developers have a strange fascination for meta-data, I don't think that labeling this thread "meta"-discussion will attract any extra attention. I might be wrong though.
Can someone please provide some explanation/reference to the proposed workaround? I would be pleased to hear it to see if it can be adapted to my situation. #!/bin/bash qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /home/......./panel.js xdotool key ctrl+e xdotool key alt+F4 What is the javascript interactive console? Can someone provide best link to docs about it? I've found http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting is there anything better? Is it possible to execute a script without opening the interactive console? The alt+F4 is to close the console? What is the ctrl+e? An execute command? Many thanks
please move this discussion to the forums. this report has become utterly unusable for development at this point. from a quick reading, i believe there is actually more than one bug reported in this discussion, at least one of which i believe has already been fixed. and yes, all the discussion about us not working on a "core component" is really discouraging. i do a fraction of the work i would LIKE to do because i'm working on things i don't personally use but know are important to others. and then i get to these kinds of comments. maybe one of you who are so obviously concerned about this can find someone with multiple screens who would like to work on these issues and keep an eye out for regressions between releases.
Dear AAron and all developers, while I surely agree that this report has become unusable, as a reporter of one bugs that made their way into this one as a duplicate, I am concerned about the best way to assure that the individual issues are anyway tracked. What is the best way to proceed now? Should I open a new bug for my specific issue (still hoping that it is the one that is in the process of being fixed?) Thanks! PS: most LCD TVs have now a VGA port. Even without the need to acquire a projector or a second monitor, the quick connection of a laptop to the TV set can be an easy way to check the consistency of the plasma desktop behavior when multiple screen are connected. I would recommend just a quick test in clone mode and in non-clone mode (eg TV screen above the laptop screen or on the side of the laptop screen), after attaching and after detaching. The fact that the TV set will likely have a resolution different from that of the laptop screen will certainly help spotting inconsistencies.
"What is the best way to proceed now?" my recommendation is to wait for 4.7 to come out and test against that; i'm fairly confident that at least some of the issues reported here have been resolved. (making matters more complex is that some of the problem may exist outside of plasma, in kephal or even the x.org drivers) in any case, if your issue remains in 4.7, please re-report (assuming there is no duplicate already) or you can let us know and we can de-duplicate your report from this one at that time (assuming that your report hasn't been obliterated as this one was)
(In reply to comment #49) > maybe one of you who are so obviously concerned about this can find someone > with multiple screens who would like to work on these issues and keep an eye > out for regressions between releases. It isn't necessary to be a dual screen user to have this problem. Some of us still use CRT screens to facilitate web page development and testing at multiple resolutions. App devs who don't do the same aren't being thorough testers of their own work. Each switch brings the wrong size back, extending past the actual screen, to less than full screen, or at least did from 4.6.0 through 4.6.2, since I've not seen 4.6.3 yet. Bug noise annoyance isn't justification to mark an actual bug invalid, and based on the summary, there's only one bug here.
"It isn't necessary to be a dual screen user to have this problem." thank you for pointing out the obvious. now let me return the favor: someone who uses this feature on a regular basis is more likely to notice regressions and have more motivation to fix them. ergo my recommendation. "and based on the summary, there's only one bug here." based on the comments, there isn't. "Bug noise annoyance isn't justification to mark an actual bug invalid, this bug tracker is open to all who wish to participate. when you, the participants, turn a report into something utterly unhelpful and unusable, then you, the participants, have ruined the value in the system, or at least in this report. due to the open participation, this is very much a cooperative affair and you can, indeed, as the users of it utterly wreck a report beyond use. the volume of reports on bugs.kde.org is very high and we receive duplicates of just about every report. its not like we're somehow lacking in or missing out on input. in this particular case, i can at best try to deal with the original report (which is likely a duplicate, but whatever) but then have to deal with the rest of the peanut gallery who has decided to tag along for the ride. i've been down that road before and it's not worth it. another option that would make bugs.kde.org reliably usable would be to turn off access to the general population past the act of the initial report. i hear regularly from other developers how bad bugs.kde.org is in addition to witnessing it myself. there appears to be no attempt by the user base to try and create some basic level of conduct expectations. most of you certainly expect it out of the developers, which leads me to believe you are aware of the value of such things but unaware of the need or unwilling to do what it takes to put such a thing in place amongst the user base. perhaps some things to think about. in any case, this particular report will remain marked as it currently is. my compile is done, i need to get back to working on things. cheers ....
This could be very easily resolved if the users wouldn't be automatically notified each time someone adds a comment. Once I reported a bug I don't care about following the bug-report anymore, but then I start receiving flames and must comment. Try disabling the automatic subscription and you'll see. I wouldn't be so hard on the users because of duplicate reports. Bugzilla sucks big time in that regard. Since I don't want to irritate the developers any longer, this is my last comment in this thread. May this bug be solved some day.
(In reply to comment #53) > "Bug noise annoyance isn't justification to mark an actual bug invalid, > > this bug tracker is open to all who wish to participate. when you, the > participants, turn a report into something utterly unhelpful and unusable, then > you, the participants, have ruined the value in the system, or at least in this > report. due to the open participation, this is very much a cooperative affair > and you can, indeed, as the users of it utterly wreck a report beyond use. > the volume of reports on bugs.kde.org is very high and we receive duplicates of > just about every report. its not like we're somehow lacking in or missing out > on input. Volume is precisely a major reason not to mark a valid bug invalid, not to mention others have been marked duplicates of it. This makes any but the most clueful upon first encounter with a problem believe it to be WAD or fixed when searching the DB and deciding whether to file a bug on account of the same behavior. Noise is undoubtedly detrimental to progress, but so are several other things: 1:Leaving all CC'd (validly interested or otherwise) left hanging if and which bug replaces it or not, to go get CC'd again so as to keep tracking any progress that may eventually occur 2:those CC'd opening clones of it themselves, since it is not factually WAD and thus still broken behavior 3:first encounterers thinking they found a new problem and filing a bug as though it were new 4:belittles the good information lost amongst the noise, and the efforts of those who provided it 5:even more work for triagers, who themselves have to sort out the validity problem before they can proceed on the same subject IOW and IMO, marking a tracker bug that is nevertheless bad behavior and thus a real and unwanted behavior an invalid bug in a tracker due to tracker noise is worse than the noise itself. Of course, what would I know about the subject, as I've only been filing, searching, tracking and triaging bugs in public bug trackers for 122 months. At the very least, open a new one, and whiteboard it, restrict it, or whatever else is necessary to inhibit noise. In any event, regardless of its marking or the noise herein, invalid this bug is clearly not.
I don't really understand what all the comments above are about and whether this bug is now being ignored or not but as a laptop user who frequently docks (1280x1080 screen) and undocks (1024x768 screen) a laptop, the malfunctioning of the panel to automatically resize is quite a nuisance. I understand that developers are limited and have limited time but unfortunately I am unable to offer anything other than testing as I know nothing about coding. So do I open a new bug as this one has been marked invalid or continue to monitor this bug?
So why has this bug-report marked INVALID after all? Personal revenge? It describes a _single_ bug, and lot of users are affected.
Summary: 1 (?) Bug (at least one initially reported) 57 Comments Describe & Additional info (duplicates): 14 Confirmation & Wkrnds 14 Expression of Wish 5 Meta-discrussion and critics to the system: 24 Diagnose: bad signal to noise ratio. Philipp: "KDE-Developers give a sh** about the votes... we like to see the voting dismantled" Aaron: "thank you for pointing the obvious" " The participants have ruined the value in the system" Now: despite the risk of being accused of continuing the meta-discussion: 1. The bug still EXISTS (denial doesn't help) 2. If KDE developers can't handle 57 comments on one bug, then YOU WON'T BE ABLE TO HANDLE (AND DON'T DESERVE) ANY LARGER USERBASE. 3. No need to be rude (Aaron & Philipp) 4. If I find this attitude in further KDE-related bugs, I'm out of here. I'm a doctor (not developer) and small-business owner trying to support FOSS. I expect at frome the community working software and respect (I used to get both, then software became less stable, then discussion level drops). Again: thank you all developers for your work, but without users I don't think it makes much sense developing a DE. Marcelo
I also can confirm this bug (using KDE 4.6.3 on openSUSE 11.4). The interesting thing is that this bug was not present with KDE 4.6.0 on openSUSE 11.4, only after I upgraded to KDE 4.6.3 this bug appeared. The comments above indicate that some users also suffered from this bug with KDE 4.6.0, so maybe openSUSE had a fix for it. It is not only the auto-resizing that doesn't work but also all panels that have the "auto-hide" setting enabled, are not auto-hiding anymore when the screen-size is changed. The same is for the "centered" option. I should also mention that I have a notebook with multi-monitor setup and at home I connect an external monitor with different resolution that that I use at work. Also all panels that are placed on the internal monitor and having the "auto-hide" and/or "centered" option enabled are also affected when the resolution of the external monitor is changed.
Aaron J. Seigo: in the end you cause harm to the KDE project by marking this bug report as invalid. The bug will stay unfixed for an even longer time, and more people will switch to a different desktop environment.
@Clemens: dont worry. There is at least one other (untouched-and-open-for-month) bug entry in the database for this problem. I dont link there; just to ensure that our evil offtopic discussion wont continue there; you know, as this discussion prevents the developers from fixing problems.
Of the bugs filed since this was marked invalid, all remain unconfirmed, and none have a subject line that actually describes the real problem, which is that choosing to maximize only works once, and doesn't autocheck at appropriate times to ensure that the panel width stays matched to the screen width.
I confirm the behavior. user@host:~$ kwin --replace and following reboot works for me! System: Host/Kernel/OS "XXX" running Linux 2.6.39-1.slh.5-aptosid-686 i686 [ sidux 2010-01 Ύπνος - kde-lite - (201006131622) ] CPU Info 2x Intel Atom N270 @ 512 KB cache flags( sse3 ht ) clocked at [ 1333.000 MHz ] Videocard Intel Mobile 945GME Express Integrated Graphics Controller X.Org 1.10.2 [ 1440x900@59.9hz ] Network cards Realtek RTL8101E/RTL8102E PCI Express Fast REALTEK USB 10/100 LAN Atheros AR928X Wireless Processes 135 | Uptime 24min | Memory 553.2/999.5MB | HDD WDC WD1600BEVT-2 Size 160GB (9%used) | Client Shell Version: user@host::~$ kwin -v Qt: 4.7.3 KDE: 4.6.3 (4.6.3) KWin: 4.6.3 (4.6.3) greetz ab
(In reply to comment #63) It is already annoying to re-configure the panel, your workaround is far far away from being decent. Regards Juan
Someone claimed in some forum that it is resolved with 4.6.4 Anyone tried here and can say for sure?
No, not solved in 4.6.4. I have yet to test 4.7. Beta2, but I'll probably switch with RC1.
Definitely not solved in 4.6.4.
I can confirm the bad behaviour of the panel when switch screen resolutions. This is also an issue in latest stable 4.6.4.
Tested on 4.6.5: still has the bug. Tested on 4.7: bug gone. So in 4.7 the bug is fixed, for those living with 4.6 series the only option is to look in the git history for a patch and backport it. Not trivial.
(In reply to comment #69) Not really. For my usecases the problem still exists. Maybe now it's the time to open a new bugreport (Without the flamewar).
Ok, one of the developers just blogged: http://www.afiestas.org/an-extremely-productive-weekend-plasma-kwin-bluedevil/ With this ( https://git.reviewboard.kde.org/r/101968/ ) patch (I applied it to the 4.7 branch by hand) it now shows the correct behavior. Hopefully it will make it into 4.7.0, otherwise it will probably be in 4.7.1.
please, backport it to 4.6.x, otherwise this is still a bug for millions of users as nobody uses 4.7 and many distros will not update to 4.7 in months!
(In reply to comment #72) Since there will be no more point release of 4.6 I'd say the chances of that are nonexistent. You would have to talk to your Distro if they could patch it themselves.