browser window resize doesn't resize layout widgets on IE9

[Eric Wang]

dijit layout failed on IE9.

the root cause is IE9 need to bind "onresize" event on window.global, not as IE6/7/8 bind on domNode.

the testcase file and patch as follow.

[Eric Wang]

Testcase for layout on IE9.

[Eric Wang]

patch of dijit.layout._LayoutWidget.js

[bill]

When you say that "dijit layout failed on IE9" what do you mean exactly? I'm guessing you mean that resizing the browser window doesn't resize the widget.

If so, good catch. I wish we could feature-test for this, but on IE9

"onresize" in document.createElement("div")

returns true even though that onresize handler never fires.

So, your fix seems good; I'll check that in... or possibly just remove the IE path altogether.

[bill]

In [27007]:

Remove IE branch to monitor resize events per node, rather than on the browser window. Although theoretically more efficient, it doesn't work on IE9, and I've heard stories of endless resize loops when myWidget.resize() (incorrectly) changes the size of the widget, rather than just doing internal layout.

Fixing on trunk, refs #14247 !strict.

[bill]

In [27008]:

Remove IE branch to monitor resize events per node, rather than on the browser window. Although theoretically more efficient, it doesn't work on IE9, and I've heard stories of endless resize loops when myWidget.resize() (incorrectly) changes the size of the widget, rather than just doing internal layout.

Fixing on 1.7 branch, fixes #14247 !strict.

[bill]

In [27262]:

[27007] updated the browser-resize detection for subclasses of _LayoutWidget, but not for subclasses of ContentPane. Adding in code for ContentPane too. However, that exposes the infinite loop problem, where ContentPane.resize() causes a(nother) browser resize event, so have to add guard code to detect spurious resize notifications, hence a new !Viewport.js helper module.

Also modifying Dialog to leverage the viewport resize events it gets as a ContentPane subclass, rather than setting up it's own listener.

Also modifying robotx.js so that it sets the iframe size before dojo loads (inside the iframe), rather than after. The !BorderContainer_full.html test was hitting a corner case (on IE) where DOH resized the iframe after the BorderContainer layout() ran, but the BorderContainer didn't get a resize event (like on a true browser resize), so it didn't resize itself.

Refs #14247 !strict.

[ben hockey]

Replying to bill:

fyi - you left in some debugging in r27262.

[bill]

In [27283]:

remove console.log() statements, refs #14247 !strict.

[adros]

There is still a problem with same behaviour in Chrome 15, IE 9, FF 4. If I resize window only verticaly, width of the BorderContainer? stays unchanged. Then resizing the window horizontaly causes adapting width of the BorderContainer? to the width of the window. But height stays unchanged.
The same behaviour applies for resizing the window the other way around.
I'll attach a small sample.

[adros]

Testcase

[bill]

Hmm, too bad, OK I'll take another look.

[bill]

PS: @adros - You must work with, or are the same person as matej, this is the same format of test file he attached. Your test case is not self contained, it shouldn't reference a file called sample.js.

[bill]

In [27427]:

fix typo preventing resize code from getting called if only horizontal or only vertical size is changed, fixes #14247 on trunk/ !strict

[bill]

Actually, this problem doesn't occur on the 1.7 branch / 1.7.1 tag (and I fixed trunk in the above checkin).

[haysmark]

Test case for 1.6 branch.

[haysmark]

This also works just fine in 1.6, attaching the test case I used to reproduce. I don't think it needs to be backported (thankfully)!

[bill]

In [31402]:

remove no-longer used dependency after [27262], refs #14247 !strict.

[Bill Keese <[email protected]…>]

In bfcc0886bf28d6bb222df9e1e8b93e7a9d4fedb6/dijit:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled?