New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Jumping when using "position: fixed", "-webkit-backface-visibility: hidden", and textarea

Reported by m...@janpaulposma.nl, Jul 11 2012 Back to list

Issue description

Chrome Version       : 22.0.1201.0
OS Version: OS X 10.7.4
URLs (if applicable) : http://jsfiddle.net/VvZNX/3/
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
  Safari 5.1.6: OK
  Firefox 13.0.1: OK

What steps will reproduce the problem?
1. Create a page with a fixed positioned div ("the top div")
2. Create an absolutely positioned div inside the top div, and give it the -webkit-backface-visibility: hidden; css property.
3. Create an absolutely positioned textarea inside the top div
(see the jsfiddle link at the top for step 1-3)
4. Add enough text into the textarea such that a scrollbar appears
5. Place the cursor at the end of the text
6. Hold backspace

What is the expected result?
The absolutely positioned div should stay in place.

What happens instead?
The absolutely positioned div jumps. In fact, it takes same offset compared to the top div, that the top div has compared to the page body.

Browser information:
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1201.0 Safari/537.1

 

Comment 1 by tkent@chromium.org, Jul 12 2012

Labels: -Area-Undefined Area-WebKit WebKit-Rendering

Comment 2 by jveh...@gmail.com, Oct 31 2012

This can be reproduced even easier: http://jsfiddle.net/VvZNX/13/

Setting -webkit-transform: translate(0) or -webkit-backface-visibility: visible on an element that is somewhere in the dom before (can be deep down the dom-tree) a position: fixed element triggers this behavior

A workaround is setting -webkit-transform: translate(0) on all fixed elements with textboxes in them.

Comment 3 by Deleted ...@, Dec 15 2012

any update? we have the same issue...

Comment 4 by Deleted ...@, Jan 16 2013

Can confirm that this is still happening in 24.0.1312.52 m. Thanks JVeh...@gmail.com - setting -webkit-transform: translate(0) on the container div worked.

In my case, I had a textarea in a position:absolute div in a position:absolute 'lightbox' type div (covering entire screen). On removing text such that the textarea did not require the scrollbar, the entire lightbox div moved to the top corner of the position of the textarea. However, on resizing (or sometimes just by moving the cursor) the positioning corrected itself.
very annoying bug...:(
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -WebKit-Rendering Cr-Content-Rendering Cr-Content
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 8 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Rendering Cr-Blink-Rendering

Comment 9 by laforge@google.com, Jan 9 2015

Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout
Cc: jchaffraix@chromium.org
Status: WontFix (was: NULL)
I tried to reproduce the bug on M46.0.2490.80 using both JSFiddle (comment #0 and #2) but couldn't.

The bug was filed several years ago and we improved our support for backface-visibility so it's likely that it was fixed. Tentatively closing based on that, feel free to reopen / close if I missed something.

Thanks for the report and sorry it took so long for someone to look at this bug!

Sign in to add a comment