Closed Bug 20367 Opened 25 years ago Closed 25 years ago

[dogfood] text and password fields in nested table display in wrong location

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rods, Assigned: troy)

References

(
URL
)

Details

To make sure you have GFX scrollbars turned off, do this:

PRBool
nsCSSFrameConstructor::HasGfxScrollbars(nsIPresContext* aPresContext)
{
    nsCOMPtr<nsIPref> pref;
    aPresContext->GetPrefs(getter_AddRefs(pref));
    PRBool gfx = PR_FALSE;
    if (pref) {
	    pref->GetBoolPref("nglayout.widget.gfxscrollbars", &gfx);
    }

#if 1
    return PR_FALSE;
#else
    return gfx;
#endif

  /*
  nsWidgetRendering mode;
  aPresContext->GetWidgetRenderingMode(&mode);
  return (eWidgetRendering_Native != mode);
  */
}
Here is another URL that is even more dramatic:
http://www.mirc.com/mailing.html
Assignee: buster → troy
URL: http://www.slashdot.org/ → http://www.slashdot.org/, http://www....
Summary: Click in text field causes reflow and a different layout → [dogfood] text and password fields in nested table display in wrong location
reassigning to troy.  chris k. and I discussed this, and he suspects the
changes you made recently having to do with how views are positioned.  I'm
still catching up on my mail from vacation, so I don't know all the
details about those changes.  anyway, let me know if I can help track this down
any further.  details of my investigation below:

--------------------------------------------------------------------------------

basically, the problem seems to be that the text control view is getting
positioned incorrectly by the table reflow code.  the frame output looks
reasonable:  the text control frame seems to be inside the inner table's cell at
offset 0,0.  But the text control displays above the inner table, as if the view
nested inside it is at the wrong offset. I don't know how to interpret the data
given by dump views, but I don't see any negative offsets.

To reproduce the problem, it seems that all these things matter:
1) the text control is in a nested table
2) the text control has a webshell (hence the use of a password, takes some
complexity out of the problem)
3) the outer table must not have a border ????
4) the text in the first cell in the outer table must wrap:  you must shrink
your window so the text takes up at least 2 lines.  the more lines the text
takes up, the more the text control will be displaced.  that should be some sort
of clue....

here's a tiny test case that shows the problem:
<HTML><BODY>
<TABLE BORDER="0" BGCOLOR="#FFFFEF" >
<TR>
  <TD>
    It is now possible to get a notification by E-mail blah blah blah blah
    <FORM>
    <TABLE BORDER=0 >
    <TR>
      <TD BGCOLOR="#FFFFCC">
        <input type="text" name="address" size="20" value="">
      </TD>
    </TR>
    </TABLE>
  </TD>
</TR>
</TABLE>
</FORM>
</BODY></HTML>


for the PDT team:  this same problem happens when you click on a text control in
any of the 2 urls given above.  I've changed the subject so we can deal with the
problem with fewer steps to reproduce, but when considering whether this should
be dogfood or not, keep in mind this happens on normal text fields, not just
password fields.  so users see password fields in the wrong place, and they see
text fields jump on initial focus.
Assignee: troy → buster
When I look at the page, http://www.mirc.com/mailing.html, what I see is the
edit field looks to be in the correct place. Then when it is clicked in it
displays itself in some wacky place

Dumping the view hierarchy before and after clicking in the edit field I see
what looks like a new view (with a widget) that exists after that didn't exist
before clikcing in the edit field

Yes the rules for how DidReflow() notifications and view positioning/sizing work
have changed, and yes that may be related to the problem, but I have no idea how
the edit field code works and so there's not much I can do about this

You're going to have to take a look at it. Maybe if you describe how it works
I'll be able to comment on what's wrong
Assignee: buster → troy
I was able to verify the problem using a SELECT instead of an edit field
troy:  did you try the test minimized test case that used a password field
instead of a normal text control?  in that case, the view is created imediately
rather than being deferred.  does that help?

basically, the password control creates a webshell to hold a subdocument.  the
embedded webshell creates its own view.  the text control frame does not have a
view of it's own, and does not have any code that I know of to do anything
special with views, just the webshell.
I found the problem and will be checking in a fix. It was in the row frame code
when we optimize the case where the cell frame doesn't need to be reflowed
because the new available width is the same as the last time we reflowed the
cell.

Even though we don't reflow the cell frame we need to make sure that any views
are properly positioned

There are probably still a couple of more places in the table code where this
could be an issue. If I can make a test case that verifies my suspicions I will
fix them as well
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
QA Contact update.
Marking VERIFIED FIXED on:
- Linux6 2000-03-07-09 Commercial build
- MacOS9 2000-03-07-08 Commercial build
- Win98 2000-03-07-09 Commercial build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.