751012 - Reframing ancestor of out-of-flow textarea's placeholder loses the scroll position of the textarea

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P2)

Description

[Cougar]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

document.<textAreaName>.scrollTop = document.<textAreaName>.scrollHeight;

I use this command because I'm dynamically adding text to a textarea (herein called "Output Textarea"), and I want the Output Textarea to always scroll to the bottom of the textbox automatically. I can provide the full code if desired. 


Actual results:

In Chrome, Safari, Opera, and IE, the Output Textarea automatically scrolls to the bottom. The user is always able to read the last text that they typed elsewhere on the page. In Firefox, the text is transferred to the Output Textarea, but the thumb remains at the top of the scrollbar, and only the top of the text in the Output Textarea is visible. The user can drag the thumb down or can use the scroll wheel on their mouse, but since every addition of text resets the focus to the top of the text block, this becomes an annoying problem for the users.


Expected results:

Firefox should have the same functionality as ALL the other browsers. Setting scrollTop to scrollHeight should cause the Output Textarea to scroll to the bottom when text is dynamically added to it.

You can verify that Firefox acts differently than all the other browsers at the following URL. You will need to click through the exercise and paste dummy text into each of the text boxes and areas throughout the UI. There are eight steps in the UI.

http://grokwisdom.org/gendlinexercise.php

Thank you for your prompt attention.

Comment 1

[Cougar]

According to http://stackoverflow.com/questions/642353/dynamically-scrolling-a-textarea, this problem did not exist in Firefox 3.0.7.

This page in stackoverflow seems to describe the same problem in Firefox from a different point of view that could be helpful:
http://stackoverflow.com/questions/5908049/textarea-replace-value-scrollheight-in-firefox

Thank you for helping me here, because the attached page is a prototype for 300 more pages with dynamic content, and I'd like to have my pages work with all browsers, including Firefox, which is the only inoperative browser at the moment.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Simple testcase that shows that this works in general

Cougar, does this testcase behave correctly for you?

How is what you're doing different from this testcase?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, I see what you're doing differently. You have a <span class="steps"> (an inline) containing various <div class="step0*"> for * going from 1 to 9, all either "hidden" (display:none) or "visible" (display: inline).

But those divs contain other content that's block-level (e.g. step05 contains two <p> tags in it).  So when they switch from display:none to display:inline that means inserting a block inside an inline (the <span class="steps">), which requires splitting the inline.  Right now we do that by recreating CSS boxes for the parent of that <span>, which is the <div class="left">.  Since the output form is a child of that <div> that includes recreating the CSS box for the textarea.

That said, bug 629878 should have made that work correctly, and I can't get things to break so far in a smaller testcase...

In any case, not putting blocks inside inlines would definitely help in your case.  Almost certainly so would running the addtext off a timeout.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Ah, I see what's going on.  The container for that textarea is position:fixed.  Ehsan, does the fix for bug 633789 break in that situation?

Cougar, the right thing to do here is definitely to avoid the block-inside-inline thing.  Most simply, just make <span class="steps"> a block.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 6

[Cougar]

Thank you, Boris. 
I have now changed the span to a div. Now the page behaves in Firefox the same as in all the other browsers.

I was very afraid that I would break my code by changing the span to a div--this is my "Hello World" application in JavaScript and jQuery, as is the PHP project that is linked by the "What's Next" button on the bottom left. I took up programming because I couldn't find a programming collaborator or a funding source. Thus, to create the project I carry in my soul, I had to learn programming and do it myself.

Thank you for taking the time to tell me how to repair this and make it work. I've tried to learn the rules of the DOM, but there's a limit to how much I can absorb in a short time.

Thank you again, Boris.
PS. I'm sorry if I've taken out a testcase for fixing another bug. If you'd like, I can put up my original code with a slightly different URL so that you still have a test case. Let me know.

Comment 7

[Boris Zbarsky [:bzbarsky]]

You're very welcome.

No need to leave the testcase up on your end; the testcase I attached in comment 5 shows the problem just fine.  But thank you for the offer!

Comment 8

[(no longer active)]

(In reply to Boris Zbarsky (:bz) from comment #4)
> Ah, I see what's going on.  The container for that textarea is
> position:fixed.  Ehsan, does the fix for bug 633789 break in that situation?

No, off the top of my head, it should not break in that situation.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Actually, in my minimal testcase the scroll position restoration breaks even if the textarea is position:absolute.

Comment 10

[Boris Zbarsky [:bzbarsky]]

In fact, the fix for bug 597331 has nothing to do with this working in the in-flow case.  The only reason it works there is framestate restoration during reframes.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: When saving frame state, make sure to walk through placeholders so we save the state of out-of-flow descendants properly. Also make sure to walk the continuations and special siblings of the root frame that we're saving state for.

Comment 12

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/633e2a5c64d1

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/633e2a5c64d1