Closed Bug 257955 Opened 20 years ago Closed 20 years ago

A horizontal bar is surely displayed by MozillaZine Japan.

Categories

(Core :: Layout: Form Controls, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sugar.waffle, Assigned: bernd_mozilla)

References

()

Details

Attachments

(7 files, 1 obsolete file)

The trunk version of 2004-09-03 In nightly build, since a horizontal bar is
always displayed, access of a page becomes difficult.

The trunk version of 2004-08-31 There is no problem in nightly build.

Reproducible: Always
Steps to Reproduce:
1. Open http://ryuzi.dyndns.org/mozillazine/html/modules/news/

Actual Results:
display the horizontal bar

Expected Results:  
don't display the horizontal bar

Mac OS X 10.3.5
There is no problem in this build.
What about the 09-01 and 09-02 nightlies?  Having a one-day regression range
would help a lot.

This is very unlikely to be a parser bug.  Over to layout, but we need a minimal
testcase to figure out what's up.
Assignee: parser → nobody
Component: HTML: Parser → Layout
QA Contact: core.layout
The Mac version of 09-01 There was no nightly build.
And tt reproduced also by 09-02.
One more question... When are those nightly builds made?  That is, what's the
hour in the timestamp?
The time stump of mozilla is as follows.
It is displaying by TZ of Japan.

-rwxr-xr-x    1 sek  unknown  115708  3  9 01:59 mozilla-bin

oops...
comment#6 is 09-02 nightly build.
I meant the timestamp in the title bar of the browser..
It is displayed on the title bar as follows.
   Build ID:2004090208

And this was also reproduced, when it checked now, since there was Firefox of
2004-09-01-08-trunk .

I see it with 2004090105 winxp.
A reduced testcase would be nice.
Attached file testcase
Assignee: nobody → bernd_mozilla
Status: UNCONFIRMED → ASSIGNED
Component: Layout → Layout: Form Controls
Attached patch patch (obsolete) — Splinter Review
Attachment #157876 - Flags: superreview?(roc)
Attachment #157876 - Flags: review?(roc)
One question: should nsHTMLReflowMetrics::SetMEWToActualWidth include
borderPadding for the percentage-width case?

Shouldn't nsFieldSetFrame::Reflow initialize aDesiredSize.mMaxElementWidth to
the borderpadding instead of zero, in particular for the case where there's no kid?

What happens when the legend is percentage width?
>Should nsHTMLReflowMetrics::SetMEWToActualWidth include borderPadding for the
percentage-width case?

That might be a good idea, if the content width is zero  the box has anyway the
dimensions of borderpadding.left + borderpadding.right.
Attached file minimal fieldset
there is no empty fieldset
line 024E3350: count=1 state=block,clean,prevmarginclean,not impacted,not
wrapped,nobr[0x804] {24,0,7104,259} <
                FieldSet(fieldset)(1)@024E3128 {24,0,7104,259} [state=00800004]
[content=024EDBB0] [sc=024E307C]<
                  Area(fieldset)(1)@024E317C {144,91,0,0} [state=00900004]
sc=024E31FC(i=1,b=0)<
                    line 024E32F0: count=1
state=inline,clean,prevmarginclean,not impacted,not wrapped,nobr[0x800] {0,0,0,0} <
                      Text(0)@024E32B0[0,2,T]  {0,0,0,0} [state=51100024]
sc=024E3284<
                        "\n "
                      >
                    >
                  >
                >
              >
Attached file minimal legend
content model for the legend case:
  body@024E8D18 refcount=3<
    Text@024BD540 refcount=2<\n  >
    fieldset@024BC6C0 refcount=3<
      legend@024BC7B8 refcount=2<
        Text@024BCAE8 refcount=2<\n >
      >
    >
  >
legend frames dont honour any width spec. They are currently pure content driven.
See the regression testcases that I checked in.

http://lxr.mozilla.org/seamonkey/source/layout/html/tests/formctls/base/legend_strict.html
*** Bug 258945 has been marked as a duplicate of this bug. ***
Attached patch revised patchSplinter Review
this also defaults the mew to borderpadding. As the previous testcases show
there is always a child to a fieldset frame. This might change.
Attachment #157876 - Attachment is obsolete: true
Attachment #157876 - Flags: superreview?(roc)
Attachment #157876 - Flags: review?(roc)
Attachment #158834 - Flags: superreview?(roc)
Attachment #158834 - Flags: review?(roc)
Attached patch the real patchSplinter Review
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: