337871 - Screen jumps (scrolls) around while entering text into page with multiple textboxes

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

[Roger Libiez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060513 BonEcho/2.0a2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060513 BonEcho/2.0a2

While editing templates for a forum package I maintain, it became apparent that the page is jumping around when clicking into different textboxes on the form that is generated for this purpose. I have captured the page source for the form data and have determined that it is not the result of CSS styling for the page. I will attach a chunk of code which illustrates the problem.

Reproducible: Always

Steps to Reproduce:
1. Load test code.
2. Click into text boxes in random spots.
3. Observe how the screen jumps around.

Actual Results:  
The screen jumps around, often scrolling the spot where the cursor ended up to the edge of the screen.

Expected Results:  
The screen should not shift positions while clicking into various spots in the textboxes.

So far this has only been noticed using the Quicksilver Forums package, but may impact other packages which use muiltple text boxed for inputting data in this manner. Test case html does not require administrative login to access.

Comment 1

[Roger Libiez]

Attachment: Testcase html code for this bug

Comment 2

[Frank Yan (:fryn)]

WFM.

same build as you.

Comment 3

[Robert Strong (they/them - no direct email)]

I was able to reproduce using the steps as described in comment #0. I saw this previously when using spellbound's inline spellchecking (e.g. when disabling spellbound I was no longer able to reproduce). I never debugged it but I highly suspect inline spellchecking and possibly the editor for these elements causing this bug.

Comment 4

[Robert Strong (they/them - no direct email)]

After changing layout.spellcheckDefault from 1 to 0 I was no loger able to reproduce this... so, it appears this has to do with inline spellchecking.

Comment 5

[Robert Strong (they/them - no direct email)]

s/loger/longer/

Comment 6

[Roger Libiez]

confirmed no longer able to reproduce with layout.spellcheckDefault set to 0.

Comment 7

[Robert Strong (they/them - no direct email)]

Brett, this appears to be due to inline spellchecking

Comment 8

[Robert Strong (they/them - no direct email)]

Not sure which of the inline spellcheck bugs that would be appropriate for this to block so I'm leaving that up to Brett.

Comment 9

[Brett Wilson]

Can somebody post a testcase?

Comment 10

[Roger Libiez]

Testcase for this is already attached.

Comment 11

[Brett Wilson]

(In reply to comment #10)
> Testcase for this is already attached.

Oops, thanks.

Comment 12

[Brett Wilson]

Attachment: Simplified testcase

Load this file and make the window so that half of the bottom textbox is covered. It seems to try to scroll so that this line in the second box:
  <ttl>{$this->sets['rss_feed_time']}</ttl>
is visible. If this line is visible, it doesn't scroll for me.

The bottom textbox must be spellchecked for the problem to occur. It doesn't matter if the top textbox is spellchecked or not.

It also seems to happen if you focus using the keyboard, so the problem is not in the mouse handling code.

After a while it will sometimes stop having the problem and you have to reload the page.

I speculate that it is has to do with the spellcheck selection and that it is trying to scroll it into view. The problem still occurs when PresShell::ScrollFrameIntoView is a NOOP.

Comment 13

[Brett Wilson]

Robert: Any ideas on this bug? I poked around a bit, but I don't even know where the relevant code would be.

Comment 14

[Brett Wilson]

Oh yeah: the bug seems identical on trunk and branch.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

drop a breakpoint on nsScrollPortView::ScrollTo and see who's calling it?

Comment 16

[Brett Wilson]

(In reply to comment #15)
> drop a breakpoint on nsScrollPortView::ScrollTo and see who's calling it?

Ah, that's the secret function!

Here's the stack:

nsScrollPortView::ScrollTo 
nsTypedSelection::ScrollRectIntoView
nsTypedSelection::ScrollIntoView
nsTypedSelection::RemoveRange
mozInlineSpellChecker::RemoveRange
mozInlineSpellChecker::SpellCheckRange
mozInlineSpellChecker::HandleNavigationEvent

The problem is that RemoveRange:
  http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#5155
is calling ScrollIntoView. We can check mType to see what this selection is, and not scroll when we're changing the spellchecking range. Doing this makes the problem go away.

In looking at the range types:
http://lxr.mozilla.org/seamonkey/source/content/base/public/nsISelectionController.idl#54
I'm not sure whether it is better to check for mType != SELECTION_SPELLCHECK to scroll, or to only scroll when == SELECTION_NORMAL.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I would guess NORMAL only, but you might want to check with an IME person like jshin.

Comment 18

[Brett Wilson]

Attachment: Patch

Comment 19

[Jerry Baker]

*** Bug 308900 has been marked as a duplicate of this bug. ***

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Brett, don't forget to check this in :-)

Comment 21

[Brett Wilson]

Checked in on trunk, leaving open for branch.

Comment 22

[Adrian Yee]

*** Bug 339930 has been marked as a duplicate of this bug. ***

Comment 23

[Brett Wilson]

Comment on attachment 223041 [details] [diff] [review]
Patch

I haven't heard any complaining. Can we get this for the branch?

Comment 24

[Brett Wilson]

*** Bug 339372 has been marked as a duplicate of this bug. ***

Comment 25

[Brett Wilson]

Fixed on 1.8 branch