Closed Bug 695660 Opened 8 years ago Closed 3 years ago

Cursor is lost when Page Up/Down is used within an iframe when browser scroll bar is present

Categories

(Core :: DOM: Editor, defect)

7 Branch
x86
Windows XP
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: monahant, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

When an iframe is included in a large HTML page (long enough for the browser scroll bar to appear), pressing 'Page Up' or 'Page Down' within the iframe causes the cursor to be lost - it is no longer available in the iframe. The cursor appears to be in the iframe (it blinks when we try to enter text) however it is now not possible to actually enter any content into the iframe.

We have reproduced this in FF3.6 and FF7 on winXP and Windows 7. Other browser or OS versions have not been tested.

Steps to Reproduce:
1. Save both of the attached html files to the same location and open 'FF cursor lost in iframe page up page down.html' in Firefox.
2. Click into the iframe and see that it is possible to type content.
3. Press 'Page Up' or 'Page Down'.


 


Actual results:

The cursor still appears to be in the iframe but it is not possible to enter any content.

Note that the iframe still does appear to have focus because pressing Tab moves to the inputfield after the iframe, while pressing Shift+Tab moves focus to the inputfield before the iframe.


Expected results:

When the user begins to type, this content should be entered into the iframe.
Blocks: jaws
Regression window,
Works (I can enter text after PageDown/PageUp):
http://hg.mozilla.org/mozilla-central/rev/8366e5cc9f57
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090802 Minefield/3.6a1pre ID:20090802042924
Failss (I cannot enter text after PageDown/PageUp):
http://hg.mozilla.org/mozilla-central/rev/51f332235f14
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090803 Minefield/3.6a1pre ID:20090803044626
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8366e5cc9f57&tochange=51f332235f14
Suspected:
d455294cc585	liucougar — Bug 438840. Page-up/page-down in editable content should scroll the innermost scrollable region containing the caret, not the root. r=roc
Blocks: 438840
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → editor
Please give it a priority as this bug affects all WYSIWYG editors based on iframe editable when loaded with short contents on startup.
Attachment #568018 - Attachment mime type: text/plain → text/html
Attached file Standalone testcase
Attachment #568018 - Attachment is obsolete: true
Attachment #568019 - Attachment is obsolete: true
Attachment #611985 - Attachment description: Stand-along testcase → Standalone testcase
roc, do you know somebody who could take this?
Sure!
Assignee: nobody → ehsan
Attached patch WIPSplinter Review
This is what I have so far.  The goal of this patch is to make PageUp/Down consistent with the way scrolling with the mouse button works (i.e, try to apply the command to the innermost iframe, and look at the parent iframe if there is nothing to be done for the current frame.

There is a bug in this patch which I have not figured out yet.  The loop in nsPresShell.cpp is attempting to look at the parent frames if nothing was done, and stop when we reach the topmost frame, but it seems like the return value of GetFrameToScrollAsScrollable is never null since it would end up returning GetRootScrollFrameAsScrollable() if it can't find a frame.  But I don't quite understand the semantics of GetRootScrollFrameAsScrollable, it seems to return different values based on the presshell it's called on, so I have not been able to come up with the correct condition to make sure that the loop is terminated when we reach the top-most scrollable frame.

Roc, do you know what that condition should look like?
Attachment #615778 - Flags: feedback?(roc)
GetRootScrollFrameAsScrollable returns the root scroll frame for the presshell's document. There almost always is one. Instead of calling that, you could call get the root frame for the current presshell, see if it has a parent (if it doesn't, you're done), and if it does resume the search from there.

Actually I'm not sure what the right fix is, because I don't understand the bug or what's wrong with the current code. GetFrameToScrollAsScrollable will already search ancestors of the IFRAME for something to scroll in the desired direction. What's going wrong?
nsFrameSelection::CommonPageMove returns early since mShell is pointing to a presshell of another document than the one domSel is referencing (IIRC that was the presshell of the parent document) so nsCaret::GetGeometry returns null (since we're looking at the wrong caret object.)
Attachment #615778 - Flags: feedback?(roc)
Assignee: ehsan → nobody
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue on Windows XP x86, Windows Vista x86 and Windows 10 x64 with the latest Firefox release (47.0.1), the latest Nightly (50.0a1-20160704030211) and I could not reproduce it. I can confirm that in the build(7.0.1) mentioned in the description, the issue is reproducible.
Using the latest versions, I've loaded the Standalone testcase into the browser and clicked in the iframe. After writing some text and pressing 'Page Up' or 'Page Down', I was able to continue writing in that iframe.

Considering this, I will mark this as Resolved-Worksforme.

If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.