Closed
Bug 337871
Opened 19 years ago
Closed 18 years ago
Screen jumps (scrolls) around while entering text into page with multiple textboxes
Categories
(Firefox :: General, defect, P1)
Firefox
General
Tracking
()
RESOLVED
FIXED
Firefox 2 beta1
People
(Reporter: rlibiez, Assigned: brettw)
References
Details
(Keywords: fixed1.8.1, regression)
Attachments
(2 files, 1 obsolete file)
1.25 KB,
text/html
|
Details | |
1.27 KB,
patch
|
roc
:
review+
roc
:
superreview+
roc
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
WFM.
same build as you.
Comment 3•19 years ago
|
||
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
Comment 4•19 years ago
|
||
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•19 years ago
|
||
s/loger/longer/
Reporter | ||
Comment 6•19 years ago
|
||
confirmed no longer able to reproduce with layout.spellcheckDefault set to 0.
Comment 7•19 years ago
|
||
Brett, this appears to be due to inline spellchecking
Comment 8•19 years ago
|
||
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 | ||
Updated•19 years ago
|
Assignee: nobody → brettw
Assignee | ||
Updated•19 years ago
|
Priority: -- → P1
Assignee | ||
Comment 9•19 years ago
|
||
Can somebody post a testcase?
Reporter | ||
Comment 10•19 years ago
|
||
Testcase for this is already attached.
Assignee | ||
Comment 11•19 years ago
|
||
(In reply to comment #10)
> Testcase for this is already attached.
Oops, thanks.
Assignee | ||
Updated•19 years ago
|
Flags: blocking-firefox2?
Assignee | ||
Comment 12•19 years ago
|
||
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
Assignee | ||
Comment 13•19 years ago
|
||
Robert: Any ideas on this bug? I poked around a bit, but I don't even know where the relevant code would be.
Assignee | ||
Comment 14•19 years ago
|
||
Oh yeah: the bug seems identical on trunk and branch.
Updated•19 years ago
|
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?
Assignee | ||
Comment 16•19 years ago
|
||
(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.
Assignee | ||
Comment 18•19 years ago
|
||
Attachment #223041 -
Flags: review?(roc)
Assignee | ||
Updated•19 years ago
|
Whiteboard: has patch
Assignee | ||
Updated•19 years ago
|
Blocks: SpellCheckTracking
Assignee | ||
Updated•19 years ago
|
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Firefox 2 beta1
Attachment #223041 -
Flags: superreview+
Attachment #223041 -
Flags: review?(roc)
Attachment #223041 -
Flags: review+
Assignee | ||
Updated•19 years ago
|
Whiteboard: has patch → check in on trunk
Comment 19•19 years ago
|
||
*** Bug 308900 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking-firefox2? → blocking-firefox2+
Brett, don't forget to check this in :-)
Assignee | ||
Comment 21•19 years ago
|
||
Checked in on trunk, leaving open for branch.
Whiteboard: check in on trunk → baking on trunk
Comment 22•19 years ago
|
||
*** Bug 339930 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•19 years ago
|
||
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+
Assignee | ||
Updated•18 years ago
|
Whiteboard: baking on trunk → brett:checkin
Assignee | ||
Comment 24•18 years ago
|
||
*** Bug 339372 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Summary: Screen jumps around while entering text into page with multiple textboxes → Screen jumps (scrolls) around while entering text into page with multiple textboxes
Assignee | ||
Comment 25•18 years ago
|
||
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.
Description
•