Bug 31033

Summary: resizeBy: window moves before resizing then back to original position.
Product: WebKit Reporter: Marc Bonnier <chrome>
Component: FramesAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ap
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.6   
Attachments:
Description Flags
resizeBy test case.
none
Auto-resize test case none

Marc Bonnier
Reported 2009-11-02 15:24:07 PST
Created attachment 42346 [details] resizeBy test case. Calling window.resizeBy, resizing on the Y axis makes the window move down by that amount before resizing then back to original Y position. Note1: this is also true using resizeTo. Note2: Firefox ok.
Attachments
resizeBy test case. (786 bytes, text/html)
2009-11-02 15:24 PST, Marc Bonnier 		no flags
Details
Auto-resize test case (3.30 KB, text/html)
2010-03-25 23:13 PDT, Marc Bonnier 		no flags
Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2009-11-02 17:08:52 PST
I cannot reproduce this in Safari on Mac OS X. Please be sure to mention what browser version you observed the bug in when filing a bug report.
Marc Bonnier
Comment 2 2009-11-05 23:28:50 PST
"528+ nightly build" Seen in latest build Version 4.0.3 (6531.9, r50377) As well as current Safari: Version 4.0.3 (6531.9) Running on OSX 10.6.1. Load the test case, then manually resize the window to half the height of the screen. Then, press the "Resize by 10" button. When the resize occurs, the window position is not anchored/stable.
Marc Bonnier
Comment 3 2010-03-25 23:13:39 PDT
Created attachment 51716 [details] Auto-resize test case
Marc Bonnier
Comment 4 2010-03-25 23:15:18 PDT
In fact the window does not really moves. It is more like a painting problems including the window's chrome - which is why it looked like a window move (lookin at the chrome's top bar). While it is difficult to see it properly because of the small time it takes to redraw, I've been able to see it much more when my OSX WindowServer process was very busy by another software (VMWare) and thus increased significantly the redraw time for the browser.Maybe you can try reproduce this condition to be able to see it. What I saw: when the window increased in size vertically, the chrome top bar was in the middle of the window for a brief moment (so all the content including the chrome was shifted down) with the upper part being blank (white). Then the repaint kick's in and the window is fuly drawn. I include another test case which display this: start it up, click the "Alternate Increment/Decrement" option then click on one of the "Auto resize by 20" buttons. You should see the content moving. Or use "Auto resize by6" to see the white strip on the edges. Set your desktop background to black to better see the white edges. Note: I also seen repainting problems in the Chrome browser: when the window size is increased, the repainting lags and we can see a white (unpainted) portion. This may be related or the same bug. I hope you get enough to reproduce. Tested in Safari-4.0.5 and WebKit R55834.
Alexey Proskuryakov
Comment 5 2010-03-26 12:44:50 PDT
Duplicate of bug 7092?
Marc Bonnier
Comment 6 2010-03-26 15:04:45 PDT
Indeed, looks like a duplicate of 7092. I also saw the manual resize not working, as per your comment #10 of 7092. This bug makes resizing a window using a progressive animated resize look very ugly on Safari. This is a Safari issue since other WebKit based seems to be ok: Chrome, OmniWeb. It's been two years now ... is this gone be fixed someday ? Doesn't look like a high priority bug for something so visible (and basic). Can you press some button so Safari team will fix it ? Thanks.
Alexey Proskuryakov
Comment 7 2010-03-26 16:18:35 PDT
OK *** This bug has been marked as a duplicate of bug 7092 ***
Note You need to log in before you can comment on or make changes to this bug.