Opened 14 years ago
Last modified 3 years ago
#6722 assigned bug
Dragging windows in another workspace using Workspaces makes their contents visible on the current workspace in case they redraw themselves.
Reported by: | HaikuBot | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Servers/app_server | Version: | R1/Development |
Keywords: | Cc: | ttcoder | |
Blocked By: | Blocking: | #7359, #7593, #9762, #12989 | |
Platform: | All |
Description
100% reproduceable:
1) Open MediaPlayer and start some movie. 2) Go to another workspace. 3) Drag MediaPlayer window in Workspaces applet. 4) Profit!
See attachment for more detail.
Attachments (3)
Change History (21)
by , 14 years ago
comment:1 by , 14 years ago
Component: | Applications/MediaPlayer → Servers/app_server |
---|---|
Owner: | changed from | to
The same problem with downloads window of WebPositive. BViews redrawing on wrong workspace.
comment:2 by , 14 years ago
Summary: | [MediaPlayer] Bug → [App Server] Bug |
---|
comment:3 by , 14 years ago
Summary: | [App Server] Bug → Dragging windows in another workspace using Workspaces makes their contents visible on the current workspace in case they redraw themselves. |
---|
Please use descriptive ticket titles such that someone can actually search the tickets before posting a new ticket.
comment:4 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 14 years ago
Blocking: | 7359 added |
---|
(In #7359) It is. Closing as duplicate. Thanks for noticing.
comment:6 by , 13 years ago
Blocking: | 7593 added |
---|
comment:8 by , 12 years ago
In addition to mediaplayer dragging and switching workspaces with Alt-Fn when WebPositive/downloads is active, I also see this even with Pe's text selection caret sometimes (with the same use-case: switching workspaces with keyboard combo Alt-Fn or Alt-²). Hard to reproduce, but occurs several times a day.
At first this ticket reminded me of #7738 but that seems more exotic, different behavior (the out-of-window drawing remains until the application is quit, by opposed to this ticket where the dirty clipping occurs just once).
comment:9 by , 12 years ago
Still present in hrev45324
I can easily replicate this with other applications. For instance if you start a Terminal and do a tail -f /var/log/syslog and let it run... then drag that window using Workspaces onto a different workspace, then continue doing things as normal on the same workspace, as the other Terminal window updates, it will draw that new information on your current workspace.
This will persist until you switch to that new workspace you moved the app to (which seems to update its awareness of where the app actually now resides), or close the app doing the drawing, or drag a different window using workspaces that doesn't auto-update itself and thus show the problem.
Adding a shot showing this version of the problem.
by , 12 years ago
Attachment: | screenshot11.png added |
---|
app continuing to draw on wrong workspace after being moved to new workspace using Workspaces
comment:10 by , 12 years ago
Thanks! The symptoms of this problem and how to reproduce it are understood, see comment:3. Unfortunately, noone had the time and/or motivation to look into fixing it, yet.
comment:12 by , 11 years ago
Still present in haiku-nightly-hrev47149-x86gcc2hybrid-vmware.
When I drag mediaplayer window from workspace1 to 2 in Workspaces applet.Some remainings ,generally the progress bar, appeared in both workspace1 and 2, see attchment picture 'drag error'.Unless using another window to cover the remainings in either workspace will let them disappear.
by , 11 years ago
Attachment: | drag error.png added |
---|
comment:13 by , 10 years ago
Cc: | added |
---|
(for me it also sometimes occurs even without changing workspace at all, just opening new windows, pretty much like in ticket:3615 which I've just discovered)
EDIT: I suppose the unclipped FillRegion() call in here: http://xref.plausible.coop/source/xref/haiku/src/servers/app/View.cpp#1182 is a possible candidate for the "out of bounds ViewColor" painting I sometimes see; enabling the commented-out debugger() call might be interesting.
if (fViewColor != B_TRANSPARENT_COLOR) { // fill visible region with view color, // this version of FillRegion ignores any // clipping, that's why "redraw" needs to // be correct ... drawingEngine->FillRegion(*redraw..... fViewColor)
comment:15 by , 8 years ago
Blocking: | 12989 added |
---|
comment:16 by , 6 years ago
Cc: | added; removed |
---|
Bug in action.