140748 - Positioning of dynamic Div layer very slow on window-resize

Status: RESOLVED INVALID

(Core :: Layout, defect, P5)

Description

[Markus Hübner]

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).

Comment 1

[Boris Zbarsky [:bzbarsky]]

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....

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Markus Hübner]

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).

Comment 4

[Markus Hübner]

Attachment: Screenshot after maximizing the browser-window (lasts over 1 second).

Comment 5

[Boris Zbarsky [:bzbarsky]]

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...

Comment 6

[Chu Alan #2]

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 ...)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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. :)

Comment 8

[Markus Hübner]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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... :)

Comment 10

[Boris Zbarsky [:bzbarsky]]

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).

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 12

[Markus Hübner]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.

Comment 14

[Chris Petersen]

Changing priority to P4.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Markus Hübner]

reassigning to bz as he has already done some investigation

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

bryner, any idea where we fire onresize events?

Comment 20

[Boris Zbarsky [:bzbarsky]]

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.....

Comment 21

[Boris Zbarsky [:bzbarsky]]

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.

Comment 22

[Markus Hübner]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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.

Comment 24

[Jason Barnabe (np)]

(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.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Jason Barnabe (np)]

(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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 28

[Jason Barnabe (np)]

(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

Comment 29

[Boris Zbarsky [:bzbarsky]]

OK.  That's our behavior too.

Marking invalid, then.