22325 - selecting text controls changes layout radically on lanebryant.com

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[buster]

clicking in a text control causes a reflow that makes the page almost unusable

Comment 1

[buster]

setting to M14.  The page is difficult to use due to the poor layout behavior.

Comment 2

[buster]

the problem here is there is a table with height=100% that repositions the text
control when it is clicked on.  I suspect this is related to the bug troy has
regarding repositioning of views during reflow, but that might not explain the
whole story.  assigning to troy, cc karnaze.  about to attach tiny test case.

Comment 3

[buster]

Attachment: little test case with <table height=100%> and a form element

Comment 4

[buster]

attached the test case. 1 table, 2 rows, 1 cell each, second cell has a
text control.
click in the text control to see the problem.  then, resize the height of the
window to see it flicker as the table resizes.

Comment 5

[troy]

This is not likely to get fixed any time soon. There are two avenues to reducing
the flicker:

1. add an API to the compositor to tell it that we're beginning to move views
and again when we're done. It wouldn't position widgets until we were all done
moving the views. We would use the API in the case of a table with a fixed
height

2. the table code gets much smarter about how it lays out when the table has a
fixed height. Today it treats that case as a post-process step (i.e., the
reflow of the row group has no clue that all that extra spacing will be added
to each row), and it goes back and resizes all of the rows. That's very
inefficient and it causes the widget to bounce around

A more stable algorithm would help

Doing approach #1 would help, but

Comment 6

[troy]

Adding dependency on bug #23742 which I just created. We need an API on the view
manager to inform it that we're about begin moving views and again when we're
done. It needs to defer moving of widgets until we're finished.

This is the only way we're going to be able to have the resize of the window be
flicker free...

Comment 7

[troy]

So Buster, what I want to know is why you're looking at a "Lane Bryant" page in 
the first place?

Comment 8

[buster]

'cause your birthday's coming up.

Comment 9

[troy]

I changed the table frame code to make sure it re-positions any child views if 
it has to resize the rows because there's an explicit height specified.

This fixes the problem of the eidt field being positioned incorrectly

Comment 10

[troy]

Fixed by a recent change by Eric Vaughan so we defer positioning of widgets 
until after layout is finished.

Comment 11

[Chris Petersen]

Fixed in the July 14th build.