22270 - Text field in profile-"wizard" changes size on click

Status: VERIFIED DUPLICATE of bug 29198

(Core :: XUL, defect, P2)

Description

[Daniel Mouritsen]

In step two of the profile-wizard, the textfield (defaulted to "myMozilla") has
a little bug. If you highlight/markup the text in the field, it resizes to about
20% of its original size...

Comment 1

[Daniel Mouritsen]

You seem to have some sparetime :o)

Comment 2

[Syd Logan]

XPToolkit bug it seems, reassigning to Peter so it can be triaged.

Comment 3

[Peter Trudelle]

textfields are not XPToolkit widgets, changing component to Editor, reassigning.

Comment 4

[rubydoo123]

assigning to buster -- this sounds like a dup of one that is already in your
list (21177 or 21919)

Comment 5

[buster]

I think this is a box layout bug.  I think nsGfxTextControlFrame::Reflow() is
doing the right thing, given the input it recieves.

All form controls size themselves according to their reflow state's
mComputedWidth data.  See nsFormControlFrame::GetStyleSize(). The relevant code
is:
  if (aReflowState.mComputedWidth != NS_INTRINSICSIZE) {
    aSize.width = aReflowState.mComputedWidth;  // you've been given a width
  }
  else {
    aSize.width = CSS_NOTSET;                  // figure out your own width
  }

In the test case for this bug, during initial reflow mComputedWidth is
NS_INTRINSICSIZE and the text control decides it should be 2160 twips wide.
Then in the resize reflow, mComputedWidth is set to a value (5628).  The
text control sees this and uses it directly. This is how it displays initially.
Clicking on the text control generates an incremental reflow.  mComputedWidth is
again NS_INTRINSICSIZE, so the text control again compuates its own width to
2160, and displays more narrow.

I don't know how to read BOX XUL, so I don't know what the intended size is here
(wider or more narrow.)  But it's pretty clear that mComputedWidth should be the
same for resize and incremental reflows in this case.  However, it is the box
layout code that's generating the reflow state that is ultimately used in the
text control, so I think the bug must be there.  I traced this back into
nsBoxFrame::FlowChildAt(), but I don't know enough about the code to go much
further without some pain.

Comment 6

[buster]

*** Bug 21919 has been marked as a duplicate of this bug. ***

Comment 7

[Eric Vaughan]

pushing to m14

Comment 8

[buster]

changing component to XP Toolkit

Comment 9

[Eric Vaughan]

retargeting

Comment 10

[Eric Vaughan]

*** This bug has been marked as a duplicate of 29198 ***

Comment 11

[Blake Ross]

*spam* changing qa contact from [e-mail] to me ([e-mail]) 
on 121 open or resolved (but not verified) bugs.  sorry for the spam everybody, 
but most of these bugs would just remain dormant and not checked by QA 
otherwise.  I'm not sure how so many bugs have nobody as their QA contact, but 
I suspect this is the fault of some sort of bugzilla corruption that happened 
at some point (most of these bugs are in the 20000-26000 range, and I don't see 
where in the activity log that QA contact explicitly changed to 
[e-mail])

Anyways, sorry again for spam.  If you really get annoyed, I'm usually 
available in #mozilla on IRC for torture.

Comment 12

[Matt Perry]

Verified duplicate.