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
•