Closed Bug 751012 Opened 9 years ago Closed 9 years ago
Reframing ancestor of out-of-flow textarea's placeholder loses the scroll position of the textarea
344 bytes, text/html
549 bytes, text/html
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.
9.10 KB, patch
|Details | Diff | Splinter Review|
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.
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.
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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
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.
Assignee: nobody → bzbarsky
OS: Windows XP → All
Priority: P1 → P2
Hardware: x86 → All
Whiteboard: [need review]
Attachment #622283 - Flags: review?(roc) → review+
Whiteboard: [need review]
Target Milestone: --- → mozilla15
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.