Open Bug 388267 Opened 13 years ago Updated 2 years ago
XUL deck shows a child panel not matching its selected
Steps to reproduce: (1) Build trunk XULRunner. (2) Download http://downloads.mozdev.org/verbosio/snapshots/branch_20070713_tag_006.tar.gz (3) tar -xzvf branch_20070713_tag_006.tar.gz (4) ./xulrunner (path_to_verbosio_unzipped)/default/application.ini (5) Verbosio -> Open testing verbosio.xul (6) When the inner frame finishes loading, go to the inner frame's File -> Open Application... menu item and click it. Expected results: A XUL box floating, with "XUL menuitem" selected in a menulist, and several XUL textboxes with labels preceding them. Also two buttons, "OK" and "Cancel" are present. Actual results: A XUL box floating, with "XUL menuitem" selected in a menulist. The XUL textboxes and their labels are missing. Two buttons, "OK" and "Cancel" are present. (7) Click on the menulist and change its selected item to "(create new template)". Observe the debug console. Expected results: The XUL textboxes and their labels disappear. A new button appears, labeled "Open new template". Actual results: The XUL textboxes and their labels appear. In the debug console, you will see a serialization of the deck's selectedPanel property. It reflects the button I expect to see: <vbox xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" id="newTemplatePanel" menulabel="(create new template)"><hbox><button label="Open new template"/></hbox></vbox> Filed as UNCO because (a) Verbosio is not a mozilla.org product, (b) I am so far the only person working on Verbosio, and thus I haven't gotten independent confirmation.
on bz's advice, cc'ing roc, eli - can either of you lend a hand here?
So, what happens is the XUL deck expects its children to have a display property of -moz-box, -moz-grid, -moz-something-else, etc. Feed it a child which is display:block, or display:inline, and the child doesn't show up as you might expect. More interestingly, the child of the display:block child, which has a display: -moz-box setting, shows up as the second frame in the deck.
Now that I have a minimalized testcase for Firefox 1.9 trunk, I can confirm this bug. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/200707190101 Minefield/3.0a7pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
<bz> 235 nsIBox* box = GetChildBox(); in nsDeckFrame::DoLayout If that first child is not a box, this will return null so the rest of the code there won't run I bet if you switch the order of the description and text it will all work frankly, there's no reason for boxes here, imo should just work with frames that should also give you enough to go on to fix it, I think...
Maybe try changing GetChildBox() to GetFirstChild(nsnull) and changing box->GetNextBox() to box->GetNextSibling()? (It shouldn't matter whether the children are boxes or not.)
The problem here is not that the box pointer becomes null prematurely. At least for the reduced testcase, GetChildBox() and GetFirstChild(nsnull) return the exact same pointers. The list of child frames for the deck(s), in addition to the block frame for "foo", also has two empty inline frames, also for "foo": one preceding and one following. Thus, instead of the two visible content items (block frame for foo, area frame for description) being located at indices 0 and 1, they are located at indices 1 and 3. Tweaking the test case to show those selectedIndex values will show the "expected" content. The superfluous inline frames are added here: http://mxr.mozilla.org/mozilla/source/layout/base/nsCSSFrameConstructor.cpp#6104 That's as far as I've traced it at the moment; I don't really know enough about layout to go much further.
Oh, that makes sense then: the display:block rule isn't getting applied, so foo is actually an inline. Then foo is getting split because it has a box child, leading to three child frames in the frame tree. Properly applying the display:block style leads to expected behavior. It's sort of difficult to say what we should be doing in a case like this... I think we were discussing forcing inline children of XUL elements to be wrapped in blocks at one point.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.