The VR UI has accumulated multiple instances of tricky manual resizing within a layout.

For example, "make the omnibox text field wider if there is no mic button visible".

This binding-based approach is brittle and very easy to break.  LinearLayout has already been augmented with the notion of resizing a sacrifical element to ensure a fixed total width.  A bit more work is required to allow it to resize elements in an arbitrary way (ie. text requires a SetFieldWidth() call), but after that, we should employ the new approach.

This would apply, at least, to:
- URL bar origin layout
- URL bar hint text layout
- Omnibox (text field and mic button) layout


 

The VR UI has accumulated multiple instances of tricky manual resizing within a layout.

For example, "make the omnibox text field wider if there is no mic button visible".

This binding-based approach is brittle and very easy to break.  LinearLayout has already been augmented with the notion of resizing a sacrifical element to ensure a fixed total width.  A bit more work is required to allow it to resize elements in an arbitrary way (ie. text requires a SetFieldWidth() call), but after that, we should employ the new approach.

This would apply, at least, to:
- URL bar origin layout
- URL bar hint text layout
- Omnibox (text field and mic button) layout

Test edit description.
 

The VR UI has accumulated multiple instances of tricky manual resizing within a layout.

For example, "make the omnibox text field wider if there is no mic button visible".

This binding-based approach is brittle and very easy to break.  LinearLayout has already been augmented with the notion of resizing a sacrifical element to ensure a fixed total width.  A bit more work is required to allow it to resize elements in an arbitrary way (ie. text requires a SetFieldWidth() call), but after that, we should employ the new approach.

This would apply, at least, to:
- URL bar origin layout
- URL bar hint text layout
- Omnibox (text field and mic button) layout