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)
Tracking
()
VERIFIED
FIXED
M15
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>
Updated•25 years ago
|
Component: Layout → HTML Form Controls
Comment 1•25 years ago
|
||
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. :)
Reporter | ||
Comment 2•25 years ago
|
||
I know that the password element is not affected -- it comes up correctly
prefilled. I haven't tried any other elements.
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.
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.
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 6•25 years ago
|
||
Reopening. Does not work for me using a tree that I just pulled (12-31-99 at
9AM).
Reporter | ||
Updated•25 years ago
|
Resolution: WORKSFORME → ---
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.
Reporter | ||
Comment 8•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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.
Assignee | ||
Comment 11•25 years ago
|
||
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
Assignee | ||
Comment 12•25 years ago
|
||
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.
Reporter | ||
Comment 13•25 years ago
|
||
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
Comment 14•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Summary: Text controls in centered table do not display pre-filled text → [beta1] Text controls in centered table do not display pre-filled text
Summary: [beta1] Text controls in centered table do not display pre-filled text → Text controls in centered table do not display pre-filled text
Reporter | ||
Comment 15•25 years ago
|
||
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
Reporter | ||
Comment 16•25 years ago
|
||
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
Assignee | ||
Comment 17•25 years ago
|
||
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 ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 18•25 years ago
|
||
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.
Description
•