Opened 9 years ago

Closed 9 years ago

#10707 closed defect (fixed)

AccordionContainer: not properly resizing its children when it is resized (IE)

Reported by: Jared Jurkiewicz Owned by: bill
Priority: high Milestone: 1.5
Component: Dijit Version: 1.4.0
Keywords: Cc:
Blocked By: Blocking:


This problem only shows itself on IE (IE7 is what I tested). FF, others are fine.

The problem appears in the Editor fullscreen tests, specifically this test fails:

AccordionContainer?: Go Fullscreen, Reduce AccordionContainer?, Exit FullScreen?, Validate Resize 46 ms

What this test does is push the Editor to Fullscreen mode, resize the containing accordion container by reducing its width and height by a set amount of pixels, then drops out of fullscreen mode.

On every other browser except IE, the Editor resize() function is properly called and passed in the new width/height for the accordion container child (content pane). On IE ... it passes in the wrong original size), value.


IE: GROUP "FullScreen_tests" has 1 test to run Resizing: w:590 h: 292 eWdiff: 0 eHdiff: 102

FF/Others: Resizing: w:188 h: 292 eWdiff: 402 eHdiff: 102

Notice that the Width difference is a large number (expected) on FF, Safari, etc), but on IE it returns a width diff of 0, and that's because the accordion container content pane called the editor and told it to resize to a wrong value.

This exact same test works perfectly on Dojo 1.4.1

I don't know if this is related to Lucid changes or not, but something is definitely brokwn/wrong in the accordion container resize code.

Change History (6)

comment:1 Changed 9 years ago by Jared Jurkiewicz

If I inspect the DOM:

In Firefox (Firebug): I see the width/height properly set on the inner ContentPane? that wraps the editor

In IE if I use the IE Dev Toolbar and inspect the same DOM node (the content pane wrapping the editor), width and height are not set.

The According Container is apparently failing to properly resize its children and assign them width/heigh, which then in turn causes the ContentPane? to size its children wrong (calling resize on editor with its original dimensions instead of what should be the new ones)

comment:2 Changed 9 years ago by Jared Jurkiewicz

If I inspect the DOM in 1.4.1 on IE, I see what I would expect, the wrapping contentpane is properly styled with width/height and thus rescales right

The issue was introduced in trunk somewhere in either AccordionContainer? or one of its imports.

comment:3 Changed 9 years ago by Jared Jurkiewicz

I suspect it is this changeset:

r21162 | bill | 2010-01-15 03:04:54 -0500 (Fri, 15 Jan 2010) | 10 lines

AccordionContainer infrastructure changes to support lucid theme. Lucid needs a wrapper <div> around each accordion pane, so this checkin basically reinstates the !Acco rdionPane widget of old, but as a (hopefully) completely hidden widget.

Unit tests (including some new ones) are all passing, but there might be issues with child.getParent() returning the hidden AccordionInnerContainer (aka AccordionPane) widget, or with sizing of nested layout widgets.

Also, this revision maintains AccordionButton as a separate widget, although that's only for backwards compatibility reasons; maybe it's better to just have a single !Ac cordionInnerContainer widget similar to TitlePane.

The original lucid code didn't have a AccordionInnerContainer widget, but rather just created a wrapper <div>. I promoted it to a helper widget in order to get automat ic hover/selected class setting via _CssStateMixin.

Refs #10527 !strict.

comment:4 Changed 9 years ago by bill

Component: GeneralDijit
Summary: [REGRESSION][IE]: Accordion Container not properly resizing its children when it is resized.AccordionContainer: not properly resizing its children when it is resized (IE)

Hmm, it's all working for me. I tried Editor_FullScreen.html on IE8, IE7, and IE8 in IE7 compat mode. I also tried editor/runTests.html on IE7. They all pass for me.

comment:5 Changed 9 years ago by bill

Status: newassigned

Oops, actually I can reproduce it after all. I have a fix that I'll check in, although not sure exactly why my change fixes it.

comment:6 Changed 9 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [21301]) Avoid unnecessary contentBox() which apparently avoids strange sizing bug on IE, fixes #10707, refs #10527 !strict.

Note: See TracTickets for help on using tickets.