Closed Bug 337871 Opened 18 years ago Closed 18 years ago

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

Categories

(Firefox :: General, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Firefox 2 beta1

People

(Reporter: rlibiez, Assigned: brettw)

References

Details

(Keywords: fixed1.8.1, regression)

Attachments

(2 files, 1 obsolete file)

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.
Attached file Testcase html code for this bug (obsolete) —
WFM.

same build as you.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
confirmed no longer able to reproduce with layout.spellcheckDefault set to 0.
Brett, this appears to be due to inline spellchecking
Not sure which of the inline spellcheck bugs that would be appropriate for this to block so I'm leaving that up to Brett.
Keywords: regression
Assignee: nobody → brettw
Priority: -- → P1
Can somebody post a testcase?
Testcase for this is already attached.
(In reply to comment #10)
> Testcase for this is already attached.

Oops, thanks.
Flags: blocking-firefox2?
Attached file 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.
Attachment #221930 - Attachment is obsolete: true
Robert: Any ideas on this bug? I poked around a bit, but I don't even know where the relevant code would be.
Oh yeah: the bug seems identical on trunk and branch.
Attachment #222927 - Attachment is patch: false
Attachment #222927 - Attachment mime type: text/plain → text/html
drop a breakpoint on nsScrollPortView::ScrollTo and see who's calling it?
(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.
I would guess NORMAL only, but you might want to check with an IME person like jshin.
Attached patch PatchSplinter Review
Attachment #223041 - Flags: review?(roc)
Whiteboard: has patch
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Firefox 2 beta1
Whiteboard: has patch → check in on trunk
*** Bug 308900 has been marked as a duplicate of this bug. ***
Flags: blocking-firefox2? → blocking-firefox2+
Brett, don't forget to check this in :-)
Checked in on trunk, leaving open for branch.
Whiteboard: check in on trunk → baking on trunk
*** Bug 339930 has been marked as a duplicate of this bug. ***
Comment on attachment 223041 [details] [diff] [review]
Patch

I haven't heard any complaining. Can we get this for the branch?
Attachment #223041 - Flags: approval-branch-1.8.1?(roc)
Attachment #223041 - Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Whiteboard: baking on trunk → brett:checkin
*** Bug 339372 has been marked as a duplicate of this bug. ***
Summary: Screen jumps around while entering text into page with multiple textboxes → Screen jumps (scrolls) around while entering text into page with multiple textboxes
Fixed on 1.8 branch
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: brett:checkin
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: