Resizing is done badly, upper left corner isn't anchored.

[Shawn Smith]

When opening the nikon website a strange painting error occurs with the safari window.  Not even sure how to describe it.

[David Kilzer (:ddkilzer)]

Confirming bug.  This is not a regression--it happens on Safari 2.0.3 (417.8) on 10.4.4 as well.

I would describe the behavior as "bouncing", although the entire window contents bounces inside its boundary, not just the HTML content area.  FREAKY!

[Joost de Valk (AlthA)]

I'll reduce this one... Assigning to myself :P

[Joost de Valk (AlthA)]

Created attachment 6281 [details]
Testcase

This testcase shows issues with how we handle setTimeout, don't know if this is a bug. 

This occcurs repeatedly in the code for the site:

  if ( ( ismc ) && ( document.all || issafari ) )
        {
            clearTimeout(macTimeout1);
            clearTimeout(macTimeout2);            
            macTimeout1 = setTimeout("window.resizeBy(1,1);",100);
            macTimeout2 = setTimeout("window.resizeBy(-1,-1);",200);
        } 

this causes the "shake". The testcase shows this as well and shows that we handle timing differently then Firefox.

[Joost de Valk (AlthA)]

As the reduction shows, this is not a painting issue, the scripts do multiple resizes on purpose and just for Safari. If i use User-Agent Mozilla 1.1, this does not occur and the site works fine. So these guys need to be evangelized, CC-ing Mark Malone for that.

The other issue here is that the timers fire in the wrong order it seems. Renaming, attaching better testcase with larger timeouts in a sec.

[Joost de Valk (AlthA)]

Created attachment 6282 [details]
Testcase with larger time outs

1000 instead of 100 and 2000 instead of 200 ms.

[Joost de Valk (AlthA)]

Created attachment 6283 [details]
Better testcase

Now correctly.

[Joost de Valk (AlthA)]

Ok, this bug will be on resizing the window. The upper left corner isn't anchored and resizing in general looks weird, flashy and slow and not clean like f/i Firefox. This bug will track that. Timing issues, if any, will be tracked in another bug. Reassigning back to webkit-unassigned.

[Joost de Valk (AlthA)]

The timing issues are filed in bug 7099.

[Joost de Valk (AlthA)]

*** Bug 9285 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

This actually looks like a Safari issue: the calculations that WebKit performs before asking Safari to resize the window seem to be correct.

Also, Safari is apparently setting window minimum size as a result of this test - manual resizing no longer works correctly.

[David Kilzer (:ddkilzer)]

<rdar://problem/5665174>

[Alexey Proskuryakov]

*** Bug 31033 has been marked as a duplicate of this bug. ***

[Tony Sung]

*** Bug 68419 has been marked as a duplicate of this bug. ***

[Tony Sung]

Created attachment 120996 [details]
A test-case exaggerating the behavior.

Attached another test case which exaggerate the behavior:

Resize the browser window (making it smaller) using window.resizeTo() will cause window's title to be clipped.

To reproduce

1. Open the attached test-case in a new browser window (not in a tab, because window.resizeTo() doesn't work in a tab).
2. The test-case will automatically resize the browser for 5 times with an interval of 1-2 seconds.
3. Observes the window's title being clipped during each resize.

[Robert Hogan]

Is this still a valid bug? I can't recreate it at all but I'm not sure that I'm doing it right!

[Ahmad Saleem]

@Alan - I think browsers are now evolved and we have hardware which can manage these resizing issues. Plus I am not able to reproduce this bug, can we mark this as 'RESOLVED CONFIGURATION CHANGED' or 'RESOLVED WONTFIX'?

[zalan]

The attached test case looks performant to me.