Why is typing in a textarea in Firefox causing the screen to scroll?

Question

I am experiencing an incredibly bizarre issue with the isotope plugin in Firefox only. I have a textarea in each of my isotope elements and when I scroll down to the bottom and type in one of the textareas, the screen jumps to the top. I have reproduced this in jsfiddle:

http://jsfiddle.net/galtschul/WfTZ5/

I have been looking at this for hours and cannot figure out what is causing this scroll even to fire. Would love some help!

Halfassed

Not happening to me (firefox 13.0.1) – Lemons

I can confirm, (Firefox 14.0.1) – Consumable

I can confirm also, (Firefox 14.0.1). – Cluff

Seriously?? How is this possible? I can reproduce it every time in 13.0.1 and 14.0.1. Am I going crazy? I guess I should mention that I'm on OSX 10.8. – Halfassed

I see the problem in Firefox 14.0.1 – Enwomb

Yes, FF 13.0.1 here, too. The problem could be that your textareas are resizable (bottom right corner) and jQuery Isotope does not provide that functionality per se. See metafizzy.co/blog/mythical-drag-drop-multi-column-grid-plugin and the many other fails on manually resizeable UI elements in Isotope. There were some here on SO trying similar things, but all failed (or never posted working solution). – Nub

Tried turning off resize, but it didn't help. Thanks for the tip... can now cross that one off the list! – Halfassed

By the way, I also posted this issue on isotope's github: github.com/desandro/isotope/issues/251. Desandro recommends not using transforms, but that really does take away the fluidity of isotope. – Halfassed

Answer 1

So, the problem is not with isotope. The problem is that there's a bug in how firefox renders textareas after a scale3d and/or transform3d occurs. It winds up "thinking" that the textarea is at the top left, which is why it jumps to the top. Here's are two bugs that were filed on Mozilla's bugzilla:

November 2011: https://bugzilla.mozilla.org/show_bug.cgi?id=703241 July 2012: https://bugzilla.mozilla.org/show_bug.cgi?id=778761

Chrome also suffers from rendering issues after the same transforms are applied. Namely, rendering of the caret. I filed a new but on Webkit's bugzilla that was quickly confirmed by a Webkit developer.

Here's an example of the bug: http://jsfiddle.net/galtschul/StbKg/

Click in any of the editable boxes before clicking the button ans see that the caret renders correctly. Then click the button, which will scale the textarea and observe that the cursor doesn't blink... type a few characters and then arrow left to observe the caret not moving... then type again to observe characters being inserted where expected.

Here's the bug report: https://bugs.webkit.org/show_bug.cgi?id=94985

Eagerly awaiting fixes!!

Halfassed

Why do I have to wait 8 hours to mark this as the correct answer!? – Halfassed

Miles, meta.stackexchange.com/questions/85521/… – Picot

There is no better answer than the one I just gave! I'll be back in 7.5 hours ;) – Halfassed

Answer 2

As I observed, its due to .isotope-item { position :absolute} property. Tried lot, but really couldn't make out the solution.

Cottrell

Don't think that's it... I added "position: relative !important" and I still observed the same behavior. – Halfassed

If you try the following code, you wont find the page scrolling top left corner... as this was my observation. .isotope .isotope-item { -moz-transform: none !important; position:relative!important; float:left; ] You are also right that the bug is into firefox browser rendering... which we wish needs to be solved.. – Cottrell

That does do it as it turns off transforms in Mozilla. The isotope plugin also has an option called "transformsEnabled" which can be set to false. This is recommended as it turns this feature off in all browsers, which is probably best for now until the browsers get their acts together. – Halfassed