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.
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.
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.
Thank you for your prompt attention.
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:
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.
Created attachment 620177 [details]
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?
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.
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.
Created attachment 620184 [details]
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.
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.
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!
(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.
Actually, in my minimal testcase the scroll position restoration breaks even if the textarea is position:absolute.
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.
Created attachment 622283 [details] [diff] [review]
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.