[Patch] scrollbars

[Germain Garand]

Le Vendredi 06 Août 2004 09:28, Stephan Kulow a écrit :
> Am Mittwoch 04 August 2004 18:30 schrieb Stephan Kulow:
> > > do you feel the patch can go in today?
> >
> > I do actually.
>
> I updated http://ktown.kde.org/~coolo/regression/output/ to KDE_3_3_BRANCH.
> It still shows some noise as widgets disappeared from the dump. But there
> are also some test cases, where I'm not sure, my favorite is

> http://ktown.kde.org/~coolo/regression/tests/css1/test5525.htm

this is downright a fix, consequence of #85150. Floats are now positioned 
taking into account the bottom margin of the previous block element.
Here, it hangs a bit below and hence shifts the table to the left.
Try increasing/decreasing the font-size, you'll see what I mean.

- Other fixes of the same kind are: 

    tests/css1/test5525c.htm
    meyerweb.com/css2-tests/sec*
    fast/block/margin-collapse/103.html

- remaining inline-block changes:

    meyerweb.com/unsorted/float-inline.html
      is correct. cf. CSS 2.1-8.3.1 Collapsing margins:
      "Margins of inline-block elements do not collapse (not even with their
      in-flow children)."
      h3 and h4 have both a .25em margin, hence the resulting .5em margin.

    webcore/fast/inline-block/005.html
      looks correct to me for the same reason. It's the same testcase
      than 004.html, except the inline-block children is floated. That
      shouldn't remove the green margin.

- remaining vertical-align changes:

    meyerweb.com/unsorted/vertalign-cases.html
      this one change appears correct (the red boxes
      should be aligned with the surrounding "x...x").
  
- unsorted/RESOLVED-57087-1342.html

  is due to the Marquee now correctly layouting itself (same commit as #85150)

- webcore/fast/block/positioning/060.html

  is the min-width/max-width fix (same commit)

- the scrollbars changes:

  - those that rightfully gain a horizontal scrollbar (they were already
    larger than 800px in baseline):

    basics/nobr-66867.html
    mozilla/css_1/white_space_nowrap.html
    mozilla/dom/dom-html/hapl001.html
    mozilla/dom/dom-html/hhed002.html
    mozilla/dom/dom-html/hopg004.html
    mozilla/dom/dom-html/h(prm|tbl)*
    mozilla/html_401/pre.html
    mozilla/html_401/pre_width.html
    mozilla/html_401/th_nowrap.html
    tests/unsorted/75806.html
    unsorted/RESOLVED-43426-355.html
    unsorted/RESOLVED-49992-342.html
    

  - changes affecting the layout because the computed viewport width/height
    of baseline was either too small or too wide with respect to scrollbars'
    final state:

    webcore/fast/block/float/012.html => baseline float goes to next line, but 
                  should have fit in viewport, as in output
    webcore/fast/table/023.html => baseline is too tall, useless blank space
                  at bottom
    unsorted/69190-3.html => baseline computed 85% of a viewport *with* vsbar
                  but did not need one. Does not have an hsbar but
                  needed one.
    webcore/fast/block/float/013.html => 100% width + 10px of staticX for the
           positioned blue bar == must overflow in width.

    webcore/fast/block/float/019.html => baseline's green right floated div is
         too far from the right, it must be 10px from right border as in
         output (10px is from the margin of body)
    
  - suspicious changes that might indicate true regressions:
    
    webcore/fast/flexbox/016.html 
    webcore/fast/block/positioning/auto/004.html
    webcore/fast/block/positioning/auto/005.html
    webcore/fast/block/positioning/auto/006.html
    unsorted/RESOLVED-39866-2424.html
    => interestingly, the last 4 testcases involve RTL direction layout.

>
> If someone got some ideas on a) to restore the widgets without having a
> timeout of two seconds per test case and 

 ;(

> b) what test cases I should update
> the baseline, let me know.
>
> Greetings, Stephan