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)

123.png (417.6 KB ) - added by HaikuBot 14 years ago.
Bug in action.
screenshot11.png (2.3 MB ) - added by jstressman 12 years ago.
app continuing to draw on wrong workspace after being moved to new workspace using Workspaces
drag error.png (48.3 KB ) - added by dillcn 11 years ago.

Change History (21)

by HaikuBot, 14 years ago

Attachment: 123.png added

Bug in action.

comment:1 by X512, 14 years ago

Component: Applications/MediaPlayerServers/app_server
Owner: changed from stippi to axeld

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

comment:2 by HaikuBot, 14 years ago

Summary: [MediaPlayer] Bug[App Server] Bug

comment:3 by stippi, 14 years ago

Summary: [App Server] BugDragging 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 axeld, 14 years ago

Owner: changed from axeld to stippi
Status: newassigned

comment:5 by humdinger, 14 years ago

Blocking: 7359 added

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

comment:6 by mmadia, 14 years ago

Blocking: 7593 added

comment:7 by jstressman, 12 years ago

Still present in hrev44335

comment:8 by ttcoder, 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 jstressman, 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 jstressman, 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 stippi, 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:11 by anevilyak, 12 years ago

Blocking: 9762 added

(In #9762) Possibly related to #6722.

comment:12 by dillcn, 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 dillcn, 11 years ago

Attachment: drag error.png added

comment:13 by ttcoder, 10 years ago

Cc: degea@… 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)
Last edited 6 years ago by ttcoder (previous) (diff)

comment:14 by dillcn, 10 years ago

Still present in haiku-nightly-hrev48636-x86_gcc2_hybrid.

comment:15 by humdinger, 8 years ago

Blocking: 12989 added

comment:16 by ttcoder, 6 years ago

Cc: ttcoder added; degea@… removed

comment:17 by ttcoder, 5 years ago

Note to self: check again after hrev53711 & friends.

comment:18 by AlienSoldier, 3 years ago

Still present in hrev55726 (32bit for me).

Note: See TracTickets for help on using tickets.