New issue
Advanced search Search tips

Issue 699019 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

content position jumping out of window

Reported by m...@uxinnuendo.com, Mar 7 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. create parent html container full width of view
2. create a child html container full width and absolute position outside the parent container
3. add a 'textarea' element to the child container
4. create a js event (on parent container click) to transform the parent container (translateX) and move the inner container into the view, with an auto-focus on the textarea

What is the expected behavior?
container moves the inner container into view

What went wrong?
outer container moves out of window (browser) view - the textarea is focused so if you begin typing the content area jumps back into view. this behaviour has only been noticed in the google chromium browser.

Did this work before? No 

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 10.0
Flash Version: 

example - click a box:
http://www.uxinnuendo.com/tests/textareabug/

 
Components: -Blink Blink>Layout
Labels: OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Here's a further reduced case. It looks like some weird interaction between focus... and overflow? in layout:

http://jsbin.com/pidiwu/edit?html,output

This issue is also reproducible in Safari.

Comment 2 by e...@chromium.org, Mar 8 2017

Status: WontFix (was: Untriaged)
The elements are the wider than the container, calling focus causes the element to scroll into view which scrolls the container to the right.
This is intentional.

Is this the opinion of a developer or an experience manager?

The browser should not change positioning on any elements in the page without allowing the developer to over-ride / control such positioning.

To argue otherwise is backwards logic if we consider the movement towards app development within the web browser - where html elements are often placed out of view for a very good reason.

Sign in to add a comment