388267 - XUL deck shows a child panel not matching its selectedPanel

Status: NEW

(Core :: XUL, defect)

Description

[Alex Vincent [:WeirdAl]]

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.

Comment 1

[Alex Vincent [:WeirdAl]]

on bz's advice, cc'ing roc, eli - can either of you lend a hand here?

Comment 2

[Alex Vincent [:WeirdAl]]

Attachment: minimalized testcase

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.

Comment 3

[Alex Vincent [:WeirdAl]]

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

Comment 4

[Alex Vincent [:WeirdAl]]

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

Comment 5

[Eli Friedman]

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

Comment 6

[Ben Karel [eschew]]

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.

Comment 7

[Eli Friedman]

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.