Bug 9316 – REGRESSION: text field width shrinks on first keystroke

• Component: Forms
• Status: RESOLVED FIXED

[Tim Coulter]

I haven't noticed this with any other sites but MySpace.

Tab or click into the "e-mail address" field like you're going to sign in, then start typing.  The text field shrinks to 1 column (or less?), and doesn't seem to allow any input.  Screenshot here:

http://www.panic.com/~tim/myspace.png

The text field shrinks so you can't see what it contains, but it does allow for input. This is a regression from released Safari.

Perhaps related to bug 9122

[Alice Liu]

<rdar://problem/4575365>

Created attachment 8739 [details]
Test case reduction

(In reply to comment #4)
> Created an attachment (id=8739) [edit]
> Test case reduction

Great reduction! The empty style element only serves the purpose of invalidating the doctype. If you delete both the empty style element and the doctype tag, the bug still occurs.

I think this is a regression from the fix for bug 8969. The text field's containing block is not taking part in the layout, so its floating objects list contains the text field when the field's width is calculated, so that calculation is based on an incorrect lineWidth.

It can be fixed by not doing subtree layout if the text field is floating, but perhaps there's a more subtle way to fix it.

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

Created attachment 8888 [details]
Disable the subtree optimization if the text field is floating

[Darin Adler]

Hyatt, can you think of a better way to deal with this?

[Dave Hyatt]

I don't understand this one.  Why would you have to disable the subtree optimization?

[Dave Hyatt]

Ok, I get the bug.  Normally floating object lists are cleared during layout so that as a floating object does a layout, it can consume the appropriate amount of line width accounting for remaining space on the line.

However, I think there's a better fix.  If you are the subtree root then your width is never allowed to change.  Therefore you can optimize out calcWidth and not call it at all if you are the subtree root.  (It would be better I think to patch calcWidth itself to check if you are the subtree root, and if you are, it can just immediately return).

Created attachment 8992 [details]
Return immediately from calcWidth() if this is the relayout-subtree root.

There are several calcWidth() implementation, but I think RenderBox's is the only one that's relevant, so I patched just it. I think the condition for when to return is the correct one, but I may have missed a more direct/obvious/efficient way to compute it.

[Dave Hyatt]

Does the FrameView not know the root node of the subtree?   Seems like it could cache it and you could just grab it from the view.

Created attachment 8997 [details]
Return immediately from calcWidth() if this is the relayout-subtree root

Using the layout root from the FrameView.

[Darin Adler]

Comment on attachment 8997 [details]
Return immediately from calcWidth() if this is the relayout-subtree root

r=me

[Alexey Proskuryakov]

Committed revision 15013.