Closed Bug 22497 Opened 25 years ago Closed 25 years ago

Text controls in centered table do not display pre-filled text

Categories

(Core :: Layout: Form Controls, defect, P2)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: morse, Assigned: troy)

References

Details

1. Bring up a page containing the HTML shown below
2. Fill in username, password, and press submit
3. Answer yes to the single-signon question about saving username and password
4. Leave the page

Note: Steps 1 to 4 need be performed only once.  To demonstrate the problem
thereafter, start with step 5.

5. Return to page containing the HTML shown below
6. Page comes up with password prefilled but not username
7. Click on username field -- the prefill value suddenly appears.

An alternate to 7 would be to switch to another window that covers the username
field and then switch back to the browser.  The prefill value will appear then
as well.

If the <CENTER> </CENTER> tags in the HTML are removed, the problem is gone.

*******************************

<HTML>
  <BODY>
    <CENTER>
      <FORM>
        <TABLE>
          <TR>
            <TD>User Name</TD>
            <TD><INPUT TYPE="TEXT" NAME="name"></TD>
          </TR>
          <TR>
            <TD>Password</TD>
            <TD><INPUT TYPE="PASSWORD" NAME="pswd"></TD>
          </TR>
          <TR>
            <TD><INPUT TYPE="SUBMIT" VALUE="ENTER"></TD>
          </TR>
        </TABLE>
      </FORM>
    </CENTER>
  </BODY>
</HTML>
Component: Layout → HTML Form Controls
Could this be a painting problem with text inputs?  Are other form elements
affected too?  Adding Steve to CC.
That bit about removing the <CENTER> tags fixing the problem sure is strange. :)
I know that the password element is not affected -- it comes up correctly
prefilled.  I haven't tried any other elements.
Assignee: troy → buster
As indicated in the bug report obscuring the window and then exposing it fixes
the problem. It seems to be a painting problem

Could be a block issue, but it's strange that the pasword field
displays okay. Re-assigning to buster.
Status: NEW → ASSIGNED
I seem to remember there was a bug like this having to do with box layout not
properly passing down an incremental reflow to the text control.   Maybe this is
another situation where the incremental reflow isn't getting sent down properly?
 I'll look into it.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Priority: P3 → P2
Resolution: --- → WORKSFORME
Target Milestone: M13
worksforme, debug build from late pm 12/23.  Please re-open if you still see
this problem, and I'll investigate further.
Status: RESOLVED → REOPENED
Reopening.  Does not work for me using a tree that I just pulled (12-31-99 at
9AM).
Resolution: WORKSFORME → ---
Status: REOPENED → ASSIGNED
sometimes this works.  hmmm.  one way I seem to reliably get it to fail is to do
the first steps in one browser window, then open a second browser window and do
the second set of steps.
What about doing the first set of steps in one browser session and doing that
only once.  Then do the second set of steps in future browser sessions.  Do you
reliably get the failure then?

It fails consistently for me.  My tree was pulled on 1-1.  I don't want to
update my tree right now because I'm in the middle of some massive changes.
Depends on: 22765
Summary: Centered tables are not getting prefilled properly → Text controls in centered table do not display pre-filled text
changed summary to more accurately reflect what is going on.
Troy, I think this is very closely related to bug 22765.  It looks like what's
happening is the paint request is coming along at the time that the line is
still 0 width and 0 height.  For the given test case, this _only_ happens with a
text control in a table in a center tag when the page is wide (relative to the
page content, moving the text control off the left edge.)  Even if I force an
Invalidate when the text is set during a reflow, it still doesn't paint.  I'll
bet the invalid rect is getting applied against the left edge, and not against
the ultimate offset of the text control.

I'll try to build a similar test case using DOM that doesn't involve wallet.
something is broken in incremental reflow/repaint.  Might be in block code
since CENTER is required to produce the bug, but might also be in table code
since a TABLE is required too.

Here's the sequence of events I get at the text control level, annotated
C++-style:

/* first, I get an initial reflow */
gfxTCF: reflow reason=0
  /* at the time of the reflow, the frame looks like this */
TextControl(input)(0)@012096A4 {0,0,0,0} [state=00000427]<
<
  Block(-1)@0222B880 {30,30,2475,300} [state=00080405] sc=02940550(i=1,b=0)<
    line 02917830: count=1 state=inline,,,[0x400] {0,0,0,0} <
      Text(-1)@0222B8C8[0,0,T]  {0,0,0,0} [state=40000004] sc=02940140<
        ""
      >
    >
  >
>

/* the document finishes loading */
Document file:///s:/testcases/x.html loaded successfully
Document: Done (0.297 secs)  /* boy, are we fast! */

/* the text control is told to paint before the wallet code has done anything */
012096A4 paint layer 0 at (0, 0, 2535, 360)
012096A4 paint layer 1 at (0, 0, 2535, 360)
012096A4 paint layer 2 at (0, 0, 2535, 360)
gfxTCF: PaintChild rect=(0, 0, 2475, 300)

/* wallet sets the text of the control */
gfxTCF: SetTextControlFrameState("abc")

/* this generates an incremental reflow of type ContentChanged */
gfxTCF: reflow reason=1
  /* at the time of the reflow, the frame looks like this */
TextControl(input)(0)@012096A4 {0,15,2535,360} [state=00000025]<
<
  Block(-1)@0222B880 {30,30,2475,300} [state=00080405] sc=02940550(i=1,b=0)<
    line 02917830: count=1 state=inline,,,[0x400] mew=360 {0,0,360,240} <
      Text(-1)@0222B8C8[0,3,T]  {0,0,360,240} [state=40000004] sc=02940140<
        "abc"
      >
    >
  >
>

/* then we get a resize reflow */
gfxTCF: reflow reason=2

/* then another incremental reflow, not sure why...*/
gfxTCF: reflow reason=1

/* a resize reflow */
gfxTCF: reflow reason=2

/* and that's it, no repaints at all get through to the text control after all
these reflows.  Even though I've changed the text content, and even though I've
forced an invalidate when I set the text in the first incremental reflow.
*/

If the window is narrow, I get an additional paint call after the last reflow
and all is well.  If that page is wide, I get the above sequence and no final
paint.
What you're describing all sounds very reasonable. Because there's a CENTER
tag involved it very likely could be the problem we discussed today

The reason we see it for tables is that tables behave differently than other
blocks. Normally what happens for a block is that the block's line boxes are
centered, but the block itself is not centered. In the case of a table for
backwards compatibility reasons the table itself is centered
That leads me to believe that it's a DUP of the other block bug (now assigned to
me I think), and it will be fixed when the block code is fixed to correctly
position the block-level element before reflowing it.
In case you need a real website to demonstrate this, it's bugsplat.  The html
that I included in this bug report is a stripped-down version of what was on the
bugsplat page.
Assignee: buster → troy
Status: ASSIGNED → NEW
Target Milestone: M13 → M14
assigning to troy, probably a dup of 22765 but worth keeping open because the
test case is very different.  Setting to M14 because Troy is unlikely to land
his block code changes in M13.
Status: NEW → ASSIGNED
Blocks: 7530
Summary: Text controls in centered table do not display pre-filled text → [beta1] Text controls in centered table do not display pre-filled text
Target Milestone: M14 → M15
Summary: [beta1] Text controls in centered table do not display pre-filled text → Text controls in centered table do not display pre-filled text
Re-adding [beta1] notation to summary line so this bug gets the attention of the 
PDT team.  Single signon is on the beta1 list and this bug affects the behavior 
of single signon.
Summary: Text controls in centered table do not display pre-filled text → [beta1] Text controls in centered table do not display pre-filled text
Oops, I just realized that I'm supposed to be adding the [beta1] notation to the 
keywords field and not the summary line.  Correcting this.
Keywords: beta1
Summary: [beta1] Text controls in centered table do not display pre-filled text → Text controls in centered table do not display pre-filled text
Your test case works fine now with the change I made. I changed the block code 
to better calculate table's x-offset when reflowing it. This means we don't move 
 it later which was causing the painting problem

The files changed were: nsBlockReflowContext.h nsBlockReflowContext.cpp in 
layout/html/base/src if you want to try out the fix
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Yep, that fixed it.  Thanks.  I'll mark this bug verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.