SUMMARY STEPS TO REPRODUCE 1. With Chrome: visit http://opentarget.org/test/stupidchrome/winpos/ 2. click Launch: this will open a popup 3. Drag the popup to move it around OBSERVED RESULT The x and y values printed in the popup don't change while you are dragging the window. They only get updated when you drop it. EXPECTED RESULT They should keep gettig updated. In fact, the contents of the window keep getting redrawn and the javascript in the html page in Chrome keep running, and the contents of the text keep getting updated. However, the values for the x and y coordinates of the window, returned by javascript, are always the same while dragging, equal to their value an instant before you started to move the window. THIS ONLY HAPPENS IN KDE: if you try the exact same example in the exact same Chrome browser in Cinnamon or Gnome 3, it will work as expected and the values will keep changing while you drag the window. Since this only happens in KDE, it appears that the application running in the window (in this case Google Chrome) doesn't get informed by KDE that the window is being moved around, until you are done dragging, and then it is informed all of a sudden of its new position. This breaks existing web content in the case of a browser, and I can imagine it breaking other applications that relying on knowing the position of their window on the screen in real time. SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-40-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz Memory: 7,6 GiB of RAM ADDITIONAL INFORMATION
>This breaks existing web content in the case of a browser, Can you give an example? How is that content going to work on wayland?
> Can you give an example? The test case I provided in the report is one. But if you mean something more "meaningful" than displaying x and y coordinates for the sake of it, I think this one will break as a consequence of the issue (though I haven't tested yet): http://stewd.io/pong/ > How is that content going to work on wayland? I have no idea. I don't know what wayland is. All I know is the test case in the report works on most browsers on Windows, Mac OS, and Linux with Gnome, Unity, and Cinnamon. Plasma is the only environment where I've ever seen it fail.
>I don't know what wayland is. Upcoming replacement for X. No windows will know their own position. Regardless of the desktop environment. Firefox on gnome running wayland would undoubtedly hit the same issue. --- I did look this up, the code in kwin is very deliberate about deferring the synthetic configure events on moves. a04e9cbc6f0547aa10ab8ce457ef0aa008d72997 Optimize away XMoveWindow() calls in the common click-and-drag case This implements an optimization similar to one in compiz which defers updating the backing X window during a window move until the move is terminated. This helps alleviate some choppiness when using composite + vsync. It's a trivial one line change to make but I'm relunctant to make a change that would flood all clients with pointless configure events without hearing a better use-case than "browser pong". Especially if they're going to have to be broken soon anyway.
> I'm relunctant to make a change that would flood all clients with pointless > configure events "Pointless" according to what criterion? I'm not sure we really need "events", though. In the case I'm considering, the application is not listening for an event (at least from the point of view of the JavaScript code), it's actively querying for a given property when it needs it, and you are returning an obsolete value. Now I don't know if the only way for the application to know its configuration is to listen for events and store the values when they change. IF that is the case and it impacts efficiency (that is, IF an application has no way of querying for a given window parameter at a given time without "subscribing" for being notified of events, AND being flooded by those events without doing anything more than storing the values it needs to read later is costly), then it means the overall architecture is poorly designed. > without hearing a better use-case than "browser pong" What criteria does a use case need to meet to be good enough for you? Does it need to be "useful"? Where do you draw the line between useful and not useful? Does it need to save lives? (note that I didn't create "browser pong", I just spent a couple of minutes to look for a random use case because you asked) What even is a use case? What if the use case is something genius that neither you nor I have even thought about yet? You shouldn't ask for a use case for a feature. The mere thought of a feature should be enough to require its existance. To me, when I can describe a feature with words, that automatically translate to a use case: "Someone might want to do that", that's it. And if the feature has existed for the last 20 or 30 years in every major OS, then before you take it away, you need to be able to prove that a use case can't possibly exist (which is usually impossible, that's why you usually just don't remove a feature that has existed for ages). Unless of course you gain something huge by removing it, but that's obviously not the case here. That "flooding" that you are afraid of is already happening in all the other major desktop environments, and I don't see them become slow or unresponsive when I move windows around. If KDE did, then probably that would mean there's an issue elsewhere that needs addressing. > Upcoming replacement for X. > No windows will know their own position Wow. Looks to me like someone had a really, really stupid idea there.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Not sure why this was set to NEEDSINFO.
The code was changed deliberately. If it breaks something that isn't an abuse of windows to begin with we can change it. But so far it seems we would just be creating overhead and achieving nothing tangible. >I'm not sure we really need "events", The discussion needs to happen in the form of the X11 wire protocols. How chrome exposes this to your application isn't very relevant.
> But so far it seems we would just be creating > overhead and achieving nothing tangible. If making it *possible* for an application to know its window's position while moving creates overhead even for those applications who never take advantage of it, then something in the system is very badly designed and that needs to be fixed. If only those applications who actually "query" for their window position will suffer from the overhead (and if the overhead is not bigger than it needs to be), then it's up to the applications whether or not to use the feature. > If it breaks something that isn't an abuse of windows to begin with we can change it What is "an abuse"?? You can't just say some use case is an abuse because you hadn't thought of it or because it's useless to you. Any use of windows (or of any other feature) should be assumed to be legitimate unless you can prove the contrary. You should approach it the other way around: if it breaks something (and it does, I have already provided an example, no matter how stupid), then it needs to be changed, *unless* you can prove that every single use case that gets broken, is an abuse. Which means: 1. you need to be able to give a very, very precise definition of what you mean by "an abuse" in the first place 2. you need to be able to argue not only that the particular case that is known to get broken is an abuse, but that ANY possible use case that you may have not thought of yet, is also an "abuse". And yes, that's basically impossible, which is precisely my point: the mere fact that I can make up a use case, no matter how stupid, basically means it has to be supported. There's (almost) no such thing as an "abuse", or a not-good-enough (i.e. "better than Browser Pong") use case. Consider this other use case: A window with a background that acts like....... well, a literal window. That is, a window with a "virtual background" image that is anchored to the screen, and has the size of the entire screen, regardless of the position and size of the window. You move the window, you move the "hole" that lets you see the background. Why would I want that? For the sake of it. Because it's aesthetically pleasing (to someone). That's a good enough reason as far as the OS needs to be concerned. Now, regarding the supposed overhead. EVERY other operating system and every other major desktop environment except for Plasma has this. As far as I know, they don't become sluggish or less responsive when you move windows around.