86498 - style="overflow: auto;" doesn't work as expected on rows of XUL grids

Status: REOPENED

(Core :: XUL, defect)

Description

[Roger D]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607
BuildID:    2001060703

I have a grid whose second row has style="overflow: auto;". When I resize the
window, the range of heights over which a scrollbar appears and the height of
the row is willing to vary depends not on the difference between the minimum
heights of the second row and its contents, but on the variation in height of
the contents of the first row.

Reproducible: Always
Steps to Reproduce:
1. View the following XUL file:

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window id="main"
 align="center"
 debug="false" 
 valign="middle" 
 
 xmlns:html="http://www.w3.org/TR/REC-html40" 
 xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" 
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:nc="http://home.netscape.com/NC-rdf#" >

  <box style="border: 1px black solid; padding: 1px;" flex="1" >
    <grid flex="1">
      <rows>
        <row />
        <row flex="1" min-height="20px" height="20px"
             style="overflow: auto;" />
      </rows>
      <columns>
        <column >
          <box style="border: 1px black solid; padding: 1px;" >
            <text value="Column 1" />
          </box>
          <box style="border: 1px black solid; padding: 1px;"
               flex="1" >
            <box style="border: 1px black solid; padding: 1px;"
                 min-height="400px" height="400px" >
              <text value="Tall contents" />
            </box>
          </box>
        </column>
        <column flex="1" >
          <box style="border: 1px black solid; padding: 1px;" >
            <text value="Column 2" />
          </box>
          <box style="border: 1px black solid; padding: 1px;"
               flex="1" >
            <text value="Small contents" />
          </box>
        </column>
        <column flex="1" >
          <box style="border: 1px black solid; padding: 1px;" 
               orient="vertical" >
            <text value="Column 3" />
            <text value="has 2 lines" />
          </box>
          <box style="border: 1px black solid; padding: 1px;"
               flex="1" >
            <text value="Small contents" />
          </box>
        </column>
      </columns>
    </grid> 
  </box>
</window>

2. Vary the window size vertically


Actual Results:  The range of window sizes over which a scroll bar appeared on
the second row and the second row compressed is only one line of text.

Expected Results:  The range of window sizes over which a scroll bar appeared on
the second row and the second row compressed should be 500 - 20 = 480 pixels.

Comment 1

[Roger D]

Attachment: XUL file for test case

Comment 2

[Roger D]

We really need this functionality to work right in order to get the layout we
need for the main view of the enterprise calendar client, so we will need a fix
for it in Netscazpe 6.1

Perhaps you could try out the attached test case and at least get the bug out of
status: UNCONFIRMED?

Comment 3

[John Morrison]

-> evaughan, and cc: Acting Deputy Bugmeister pinkerton

Yes, I see the problem. It's a little odd to set the overflow on the <row>,
but specify the content column-wise, but even if I rearrange it to be row-wise,
I can't get the right overflow.

Comment 4

[Roger D]

Thanks for moving on this.

We are building the intended content for the enterprise calendar client from
templates and XBL, and it will be a _lot_ easier to do it column-wise: basically
the effect we want is an arbitrary number of columns (one per day the user is
looking at), each with a header that doesn't scroll and a column body that
scrolls together with all the other bodies. Admittedly a solution that would
make it work right only if the content is listed row-wise would probably qualify
as a workaround. 

However, given the behavior I'm seeing, my suspicion is that it's a simple
confusion bug where the code is taking the difference between the wrong pair of
variables: I'm hoping that once located it will be easy to fix. If it would
help, I can play around with the test case some more to see if I can pin down
e.g. what happens if you put the style="overflow: auto" on the first row, or if
you try the same thing with rows and columns swapped.

Comment 5

[Roger D]

I note this has been targeted for Mozilla 1.0. Is there any chance we could get 
this into 0.9.3? As I mentioned above, it's pretty much a blocker for layout 
work on the main view of the enterprise calendar client (and my suspicion from 
the observed misbehavior is that it is probably a rather simple bug).

Comment 6

[Roger D]

Having poked around in the code a bit, I strongly suspect that this bug is in 
the interaction between the nsBoxSizeListNodeImpl tree / nsBoxSizeListener 
mechanism that communicates size information between the two nsTempleLayouts of 
a grid and the extra GfxScrollFrame and ScrollPort frames introduced by 
nsCSSFrameConstructor::BuildScrollFrame when a row is scrollable. I note that 
Eric Vaughan checked in a change to thie grid code to handle this sort of thing 
back on Jun 2 2000 ("Made grids scroll for dogfood bug 30511"): possibly this 
particular case wasn't handled at that time.

Based on this, I tried moving the cell contents from being listed in the columns 
to in the rows, putting them in the same temple as the GfxScrollFrame and 
ScrollPort rather than the other one (John Morrison suggested this above but 
claimed that it didn't help.) At least in my test case, I'm no longer seeing a 
problem if I do it that way. I havn't yet tried it on our full view layout, but 
I'm assuming that it will and dropping this bug's severity to Minor on the basis 
that it now has a known workaround (I'll have to do three parallel XUL 
templates, one for the columns, one for the header cells in the header row, and 
one for the body cells in the body row, but that's do-able: I just hope they 
don't rebuild at different times and give us more cells in a row than there are 
columns or the like - if they do, I don't know if the grid code will crash - I 
have more than once crashed it by feeding it inconsistent row and column 
contbnets - , or just do something visually ugly until both the other templates 
have rebuilt, or whether it will cope in some smart way). If I can get this 
workaround to work on our full layout and play nice with templates, I will then 
remove the nsenterprise keyword.

Comment 7

[Roger D]

Calendar client group has decided to use a non-XUL interface for version 1.0, so 
this is no longer nsenterprise.

Comment 8

[Eric Vaughan]

The problem here is simple. You have put overflow on the row but there is 
nothing in that row. You must overflow something that has content. In this case 
all you content is in you columns. You would need to put overflow on one of 
them.

Comment 9

[Roger D]

We will be creating our content using templates and this requires us to generate
the data by columns (that way one template entry can generate an entire column -
if we tried to use multiple templates, one per row, they wouldn't necessarily
update at exactly the same time and then we'd be trying to draw a grid with more
items in some rows than in others, which is a good way to crash Netscape).
However we need the scrollbar created by the style="overflow: auto;" on a
particular row (the body of the data) and not one the row above (the column
headers).

So we need this functionality to work correctly with the style="overflow: auto;"
on a single row even though the data is in the columns. [While doing it the
other way does avoid triggering the bug, it is not a usable workaround for us.]
Thus I don't think the bug is invalid: the code does not do what it's supposed
to, and there are circumstances where one really does need it to do so.

Since we have gone with a non-XUL UI for our calendar client version 1.0, this
is less urgent, but we still hope to port it to XUL for our 2.0 version next year.

Comment 10

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 11

[Thomas]

As of comment #8 "You have put overflow on the row but there is nothing in that
row. You must overflow something that has content. In this case all you content
is in you columns. You would need to put overflow on one of them."

If I understand this means this is no Mozilla bug then? So one can make it
"WONTFIX"?
AT least someone ought to change the target miestone ;)

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.