Just go to http://www.world-direct.com/mozilla/dom/starter2.html and resize the browser window to about half screen width & height. Now cou can easily change to full-screen and this smaller size by double clicking on the applikation-title-bar. Whend doing so all, apart form the dynamically positioned news-scroller, are repositioned immediately. testing on latest 1.0 branch and trunk build (28th april 02).

I don't see the "news scroller" repositioning at all on window resize.... I also see JS errors about attempts to set the window.moveTo property in the JS console as I load the page....

I see what's up. I have window.moveTo disabled so sites will not abuse it. You likely want to name your function something that does not collide with a built-in function.

Function named differently. btw: the repositioning lasts more than 1 seconds on my 1.1ghz,512ram workstation. During that time I get the screen (screenshot as attachment).

Ah, I see it now... interestingly, for about 3/4 of a second there is no repositioning and no cpu use! After that, moz uses cpu for a fraction of a second and repositions...

If I am not wrong, the page will reload when the windows has been resized right? // Initializes event capturing window.onresize = reloadPage; I am seeing this code outside the if (ns) {} block ... and I suspect the 3/4 second delay mentioned by Boris is in fact the time to reload the page (either from cache or from the net ...)

Yep, that's it. The other elements all reflow normally, this one is pixel-positioned and the onresize event blows away the whole page instead of repositioning it..... Matic, this looks invalid to me. :)

The problem is that all other elements are immediately repositioned whereas the news-scroller divs need one second to be repostioned (as you mentioned)! It would be not such a problem if the repositioning in general would take 1 second so that in this time the screen as seen in the attachment would be avoided. Both MSIE and NS4.X are repositioning all elements (also the news-scroller) simultaneously.

So in other words NS4 and IE fire the resize event _before_ reflowing and then don't bother to reflow because they're in the middle of a reload? Or do they reposition the news-scroller div as they reflow and _then_ fire the resize event? (Stick an alert in the resize handler to see the order of things?) There's the separate issue that onresize=reload(); is something we tend to evangelize... :)

So... some testing shows that NS4 reflows _after_ the resize event is fired. So in this case it fires the resize event and reloads the page, so the reflow never happens. We reflow _before_ the resize event is fired (which is more correct, imo). The reason there is a delay is because the page uses pixel positioning and does not reposition on resize. Instead it reloads and the paint suppression delay of the new pageload is what is seen as the "delay" between the resize and the repositioning. I believe this is invalid (and the page author needs to be thwacked on the head).

If we fire onresize at a different time from other browsers, that could be considered a bug since IIRC onresize is defined simply by backward-compatibility.

Should be handle this in here or open a new one?

I've been idly looking to see where the onresize event gets fired.... no luck yet. This should be addressed in this bug; no reason to open a new one.

Changing priority to P4.

So nsViewManager::SetWindowDimensions seems to set the root view's dimensions (presumably triggering the DOM event handler) and to only reflow after that....

removing bogus dependency; this is not a dhtml issue nor a performance issue. It's purely an event ordering issue.

reassigning to bz as he has already done some investigation

I don't know where the resize event is dispatched from (it may in fact be OS-specific). More to the point, I have no interest in ever working on this bug.

bryner, any idea where we fire onresize events?

What does IE do wrt onresize and reflow? As far as I can tell, people use onresize to move stuff around to new positions based on the new layout, so they expect the new layout to be in place when onresize is fired.....

One other issue here. If the onresize _is_ fired before the reflow, the new load will start, but the old page is still live and the reflow still happens. So it's not clear to me whether we're firing resize before or after reflow... either order could lead to this "bug". We can't really freeze the existing page while the new one loads, since the new load may give no data... In any case, what's needed here is a minimal testcase; that will allow easy debugging of what's going on.

A more reduced version is available at http://www.world-direct.com/mozilla/dom/testpage.htm [also removed the JS alert call]

Hmm.... Is IE hitting the server at all when location.reload() is called here? Mozilla seems to be doing it, which could be leading to the lag... When I load the testcase from a file:// url, the problem disappears. There is also an innerWidth issue, maybe, but that seems less important.

(In reply to comment #23) > Hmm.... Is IE hitting the server at all when location.reload() is called here? > Mozilla seems to be doing it, which could be leading to the lag... When I load > the testcase from a file:// url, the problem disappears. Mozilla and IE load in about the same time for me.

Ok. So on the original testcase, does the alert come up before the reflow in IE?

(In reply to comment #25) > Ok. So on the original testcase, does the alert come up before the reflow in IE? IE's behaviour: 0. (Window is not maximized) 1. Maximize 2. Alert. Page is drawn: same size, same proportions, but in the corner of the screen. 3. Immediately after the alert, the "Mozilla Plattform online" stays in the same place, everything else shifts to the center. 4. Page reloads. 5. Everything gets drawn fine.

> 3. Immediately after the alert, the "Mozilla Plattform online" stays in the > same place, everything else shifts to the center. That's the behavior this bug is filed on! Do you see the same thing on the testcase in comment 22?

(In reply to comment #27) > That's the behavior this bug is filed on! Do you see the same thing on the > testcase in comment 22? Comment 22's behaviour in IE: 1. Resize 2. "Mozilla Plattform online" box sticks near the left of the window 3. Page reload 4. "Mozilla Plattform online" box goes nearer the middle

OK. That's our behavior too. Marking invalid, then.