Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla15



Layout: Form Controls
5 years ago
5 years ago


(Reporter: Cougar, Assigned: bz)


12 Branch
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)




(3 attachments)



5 years ago
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.

Thank you for your prompt attention.


5 years ago
Priority: -- → P1

Comment 1

5 years ago
According to, 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.

Comment 2

5 years ago
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?

Comment 3

5 years ago
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

5 years ago
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.
Component: DOM: Core & HTML → Layout: Form Controls
QA Contact: general → layout.form-controls
Summary: All other browsers respond to textArea.scrollTop = textArea.scrollHeight; → Reframing ancestor of position:fixed (fixed-pos) textarea loses the scroll position of the textarea.

Comment 5

5 years ago
Created attachment 620184 [details]


5 years ago
Ever confirmed: true

Comment 6

5 years ago
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

5 years ago
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.

Comment 9

5 years ago
Actually, in my minimal testcase the scroll position restoration breaks even if the textarea is position:absolute.
Summary: Reframing ancestor of position:fixed (fixed-pos) textarea loses the scroll position of the textarea. → Reframing ancestor of out-of-flow textarea's placeholder loses the scroll position of the textarea

Comment 10

5 years ago
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

5 years ago
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.
Attachment #622283 - Flags: review?(roc)


5 years ago
Assignee: nobody → bzbarsky
OS: Windows XP → All
Priority: P1 → P2
Hardware: x86 → All
Whiteboard: [need review]
Attachment #622283 - Flags: review?(roc) → review+

Comment 12

5 years ago
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla15
Last Resolved: 5 years ago
Resolution: --- → FIXED


5 years ago
Depends on: 772320
You need to log in before you can comment on or make changes to this bug.