GNOME Bugzilla – Bug 616546
On dual screen maximized windows dragged to the second screen no longer update their contents
Last modified: 2010-04-27 19:48:29 UTC
I just compiled the new gnome-shell from jhbuild this morning. Upon dragging a maximized window to the second display it no longer updates its contents and instead just shows the shadow. Events still propagate as mouse clicks still get through and pop up menus and clicking in the location of where the close button should be closes the app. A non maximized window can be dragged with no noticeable ill effect except when maximized it stops updating its contents. e.g.: d 1. open a terminal 2. type something into it 3. drag it back and forth 4. type more into it (this should work) 5. maximize 6. try to type into it (doesn't work anymore)
Created attachment 159348 [details] A shot of a window being dragged between desktops. It shows up only as a shadow
Problem is presumably that we mistrack effects being in progress when dragging a maximized window between displays, then the window gets stuck in the frozen state.
hmm ... for me, the content does not get updated as soon as i maximise an app 1. open new terminal 2. click maximise button as soon as the button is clicked the window does not get redrawn anymore. using latest git mutter, gnome-shell and mesa, clutter 1.2.6. ~ $ xrandr -q Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 8192 x 8192 DVI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 360mm x 270mm 1280x1024 84.8*+ 75.0 1280x960 85.0 1152x864 75.0 1024x768 85.0 832x624 74.6 800x600 85.1 640x480 118.8 85.0 60.0 720x400 70.1
i just looked at the last commit ... i wonder, does freeze_count get initalized somewhere? also, i think, in the case of maximize freeze never gets called (as the only freeze call is in start_simple_effect and there shoule be an assert if it is called with MUTTER_PLUGIN_MAXIMIZE).
Created attachment 159461 [details] [review] Fix accounting of frozen with maximize/unmaximize The beginning maximization/unmaximization don't go through start_effect_simple(), so we need to freeze the window separately. Change MutterWindow.freeze_count to a signed integer for consistency with other counts, and so the logic for checking for errors works properly.
ah ok, freeze_count was an unsigned, that explains the total freeze if thaw was called without freeze. i was wondering why i did not get the debug message. will test as soon as i have time.
Review of attachment 159461 [details] [review]: I'm not very familiar with mutter-window.c, but this patch looks right to me.
works ok now. one thing i noticed (but i think this is another bug): 1) open terminal on screen 1 2) maximize 3) drag maximized window to screen 2 -> window does not follow to screen 2, everything else works as expected. 4) unmaximize window -> unmaximized window appears on screen 2 5) maximize -> maximized window appears on screen 1 the same happens if i switch screen 1 and 2. as soon as the unmaximzed window is moved the behaviour is reset.
(In reply to comment #8) > works ok now. > > one thing i noticed (but i think this is another bug): > > 1) open terminal on screen 1 > 2) maximize > 3) drag maximized window to screen 2 > -> window does not follow to screen 2, everything else works as expected. > 4) unmaximize window > -> unmaximized window appears on screen 2 > 5) maximize > -> maximized window appears on screen 1 > > the same happens if i switch screen 1 and 2. as soon as the unmaximzed window > is moved the behaviour is reset. s/screen/monitor
works for me too
Attachment 159461 [details] pushed as d8b0f21 - Fix accounting of frozen with maximize/unmaximize Florian - would you mind filing comment 8 as a separate bug? It doesn't immediately sound related. I don't have a multihead setup here at the moment to test with, so I can't try reproducing it.
*** Bug 616795 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 616795 has been marked as a duplicate of this bug. *** I'm not sure how much it is a duplicate - I had only one workspace.
(In reply to comment #13) > (In reply to comment #12) > > *** Bug 616795 has been marked as a duplicate of this bug. *** > > I'm not sure how much it is a duplicate - I had only one workspace. See comment 3, etc. It's the underlying problem (now fixed) that is duplicated, not the original bug report.