Dragging windows in another workspace using Workspaces makes their contents visible on the current workspace in case they redraw themselves.

[HaikuBot]

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.

[HaikuBot]

Bug in action.

[X512]

The same problem with downloads window of WebPositive. BViews redrawing on wrong workspace.

[stippi]

Please use descriptive ticket titles such that someone can actually search the tickets before posting a new ticket.

[humdinger]

(In #7359) It is. Closing as duplicate. Thanks for noticing.

[jstressman]

Still present in hrev44335

[ttcoder]

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).

[jstressman]

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.

[jstressman]

app continuing to draw on wrong workspace after being moved to new workspace using Workspaces

[stippi]

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.

[anevilyak]

(In #9762) Possibly related to #6722.

[dillcn]

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.

[ttcoder]

(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)

[dillcn]

Still present in haiku-nightly-hrev48636-x86_gcc2_hybrid.

[ttcoder]

Note to self: check again after hrev53711 & friends.

[AlienSoldier]

Still present in hrev55726 (32bit for me).