Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#2415 closed defect (invalid)

inputs bleed through on ContentPane in TabContainer

Reported by: [email protected] Owned by: bill
Priority: high Milestone:
Component: Widgets Version: 0.4.1
Keywords: TabContainer ContentPane selectChild bleed through Cc:
Blocked By: Blocking:


Background: In out (intranet) single page ajax-app we make use of the TabContainer? widget. All the pages of the app stay in the dom and whenever someone returns to a page where there is a TabContainer? on it, we use the TabContainer?.selectChild() method to reset the TabContainer? to show its first ContentPane? again. Up to dojo 0.4.0 this worked fine.

Problem: But with dojo 0.4.1 the input elements on the ContentPane? that was selected in the TabContainer? before it was resetted by .selectChild() bleed through with all the inputs showing their outlines. When you then select the ContentPane? bleeding through and then select another ContentPane? the effect is gone for the moment. This occurs on Internet Explorer 6 and 7 and in Firefox 2.

See this screenshot, since this app is not on the internet:

Thanks so far.

Matthias Krappitz

Change History (7)

comment:1 Changed 15 years ago by alex

bill: sounds like a regression. Ideas? Opinion on 0.4.2 acceptance?

comment:2 Changed 15 years ago by [email protected]

Well of course we would love to see this resolved for 0.4.2, what would also make sense, since the 0.4.x branch was the "widget release".

Probably this has to do something with transparent backgrounds and/or z-index? I already spent half a day in the widgets source code without any success yet and would appreciate any hint.

comment:3 Changed 15 years ago by bill

Can you provide a small testcase? The bleed through problem for select elements doesn't occur on IE7 nor on FF (any version); and also it shouldn't occur because all but one of the tab panes is set to display:none.

comment:4 Changed 15 years ago by guest


here is a testcase, although not small, since it contains one very extensive mask of our app:

Please change to some other tab on the initial screen (which is "mask 2"), then scroll down and press the button to change to "mask 1" and then change back to "mask 2" and then I got serious display problems on ie7 and ff2. This time it is not only a bleed througt but a complete disappearance of the ContentPanes? content. Do you got any idea why? Note the call of


in the onclick of the "mask 2" button.

Or is this whole thing about the quite fuzzy html in the contentpane, which is, since entered by my customer, not very clean?

comment:5 Changed 15 years ago by bill

Resolution: invalid
Status: newclosed

The problem in the testcase (in the URL above) is that when you switch to mask 1, and then back to mask 2, the TabContainer? tries to redraw itself, but the browser hasn't finished calculating sizing, so we end up making the tab contents 0x0 rather than 1000x500 (or whatever the correct size is). It's probably because you are calling selectChild() while the tab is hidden. Try first showing the page w/the tab and then calling selectChild(). If that doesn't work you should be able to correct the problem be calling TabContainer?.onResized() after a small delay.

As for the bleed through problem, I still can't reproduce it, although I can see it in your screenshot. Surely it was because you were showing Mask 2 but not hiding (display="none") mask 1. Maybe you had code to hide mask 1 but it was not getting executed due to an earlier javascript error.

comment:6 Changed 15 years ago by [email protected]


I just wanted to say, that we solved this issue by calling selectChild before leaving the current mask. Everything else (doing it after the mask is visible or even with a delay) didn't work.

Thanks for the hint!


comment:7 Changed 15 years ago by (none)

Milestone: 0.4.2

Milestone 0.4.2 deleted

Note: See TracTickets for help on using tickets.