633789 - Textarea cursor position and scroll offset lost when changing the "overflow" or "position" style properties on the textarea or on an ancestor element

Status: RESOLVED DUPLICATE of bug 597331

(Core :: Layout: Form Controls, defect)

Description

[Sergiu Dumitriu]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110118 Gentoo Firefox/3.6.13
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110118 Gentoo Firefox/3.6.13

In Firefox 3.6, opening the example document ( http://purl.org/net/sergiu/cursor.html ) will show a textarea element with a lot of text inside id. A letter near the end of the content is selected, and the textarea is scrolled 100px from the top.

When clicking either of the two text elements, the textarea flashes, and the cursor is repositioned at the end of the content, and the scroll is reset to the start of the element.

In Firefox 4 beta 11, the behavior is a bit different. The textarea is always scrolled so that the selected character (or just the cursor) is visible. Initially, the same character is selected, but the scrollTop offset is such that the selected character is visible at the bottom margin of the textarea element. When clicking either one of the two text elements, the selection / cursor position is not lost, but the scroll offset is reset so that the cursor comes again in view. This can be demonstrated by changing the scroll position so that the selected character is no longer visible, and then clicking one of the two text elements.

Other style properties might trigger this bug as well, although none of the other that I've tried did.

This was encountered for example when trying to implement a full screen button, as can be seen on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration?xpage=edit&editor=wiki

The Firefox 3.6 behavior is identical on Firefox 3.5. Doesn't happen in Chromium nor Opera.

A workaround is to remember the scrollTop, selectionStart and selectionEnd before changing the style, and re-setting them after (setting the scrollTop will be ignored in FF4, but this is actually better for my use case).

Reproducible: Always

Steps to Reproduce:
1. Write a lot of text in a textarea element so that a scrollbar is visible.
2. Put the cursor somewhere near the end of the content, so that the element is scrolled down, but not exactly at the end
3. Change the overflow or position style properties on the textarea or on one of its ancestors
Actual Results:  
FF3.6: The element is scrolled to the top, the cursor is moved to the end.

FF4b11: The cursor position is left unchanged, but the scroll is changed so that the cursor comes into view.

Expected Results:  
The cursor and the scroll offset remain unchanged.

Comment 1

[Sergiu Dumitriu]

Attachment: Test file, same as http://purl.org/net/sergiu/cursor

Comment 2

[Boris Zbarsky [:bzbarsky]]

This will happen on any style change that forces changes to the CSS boxes involved.

Ehsan, I'm sure we have existing bugs on this....

Comment 3

[(no longer active)]

The selection part has been fixed in bug 597331.
The scroll part has been fixed in bug 629878.

Is there any issues remaining that I'm missing?  If not, this can be marked as FIXED.

Comment 4

[(no longer active)]

(In reply to comment #2)
> This will happen on any style change that forces changes to the CSS boxes
> involved.

aka, reframes.

Comment 5

[Sergiu Dumitriu]

(In reply to comment #3)
> Is there any issues remaining that I'm missing?  If not, this can be marked as
> FIXED.

No, this should be it. I'll check the next beta release to see if it was fixed (current behavior was on b11, where bug 629878 wasn't committed yet).

Comment 6

[(no longer active)]

Duping against 597331 which is the biggest of the two issues perhaps.

Comment 7

[Sergiu Dumitriu]

Tested on FF4b12, works flawlessly!