Another example: http://www.massless.org/mozedit/
Assignee: general → mozeditor
Component: DOM: Level 0 → Editor: Core
QA Contact: ian → sairuh
Does this help, Boris?
I see this using testcase on LInux 2004020207
Created attachment 151619 [details] [diff] [review] Patch to fix the problem w/o a workaround This patch has the textarea scroll the cursor into view whenever the selection changes. This seems to be the appropriate behavior. With it the above workaround is no longer required.
Comment on attachment 151619 [details] [diff] [review] Patch to fix the problem w/o a workaround The workaround worked, but this is nicer.
Attachment #151619 - Flags: review?(pinkerton)
Comment on attachment 151619 [details] [diff] [review] Patch to fix the problem w/o a workaround r=pink, though i know nothing about this code ;)
Attachment #151619 - Flags: review?(pinkerton) → review+
Comment on attachment 151619 [details] [diff] [review] Patch to fix the problem w/o a workaround >+ rv = selection->AddRange(range); >+ // scroll the new selection into view >+ // ignore any scrolling errors. >+ mTextSelImpl->ScrollSelectionIntoView(nsISelectionController::SELECTION_NORMAL, >+ nsISelectionController::SELECTION_FOCUS_REGION, PR_TRUE); >+ return rv; You should probably test rv before the call to ScrollSelectionIntoView, return it if NS_FAILED(rv) and return NS_OK after the call.
Sorry for being untutored about these things, but how does one install the attachment so that it will fix the bug? This bug has been driving me crazy for months & I'd dearly love to fix it. Are you perhaps in a testing stage & will reveal this fix & installation protocols later?
d/l & extract http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-source.tar.bz2 apply patch using http://www.mozilla.org/build/unix-cheatsheet.html#applyPatch make .mozconfig using http://webtools.mozilla.org/build/config.cgi `make -f client.mk build` if you need any other help contact irc://moznet/#mozillazine
(In reply to comment #12) > d/l & extract > http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-source.tar.bz2 > apply patch using http://www.mozilla.org/build/unix-cheatsheet.html#applyPatch > make .mozconfig using http://webtools.mozilla.org/build/config.cgi > `make -f client.mk build` > if you need any other help contact irc://moznet/#mozillazine when I try to save the .tar file to my desktop & open it w. winzip I get an error saying it cannot open the file since it doesn't appear to be a legitimate archive file. I don't understand how one's supposed to use the Unix Configurator. Also, don't understand how to follow the patch cheatsheet instructions. I'm still totally confused about what one needs to do to fix the problem or whether it's even possible to do so.
Created attachment 151854 [details] [diff] [review] Patch v2 Now checking the return value per comments. Not using NS_ENSURE_SUCCESS as this really isn't the sort of place we'd want to assert.
Sorry Richard, I thought you where the reporter who is using Linux. You can patch/compile Mozilla using the instructions located at http://www.mozilla.org/build/win32.html. This option is the most difficult of the two and it will take hours to finish. Your second option is to wait untill this patch is checked in to the tree. When this happens, the next nightly will have this patch. The nightlys are located at http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/.
Comment on attachment 151854 [details] [diff] [review] Patch v2 again, r=pink but i'm not the best person to review this.
Attachment #151854 - Flags: review?(pinkerton) → review+
Tom Hennen: Do you plan land it in 1.8 timeframe? What's next step on this way, if Mike Pinkerton review your last patch?
Not sure if this is relevant to the code, but since only selectionStart is considered when scrolling the selection into view, perhaps only the code for scrolling selection into view should be called only if selectionStart has changed. That would happen when setting selectionStart to a different value or setting selectionEnd to a value less than selectionStart. A little optimization.
A case where the JS workaround is still needed even if patch is checked in: 1) Enter enough text to make the scroll bar appear. 2) Select some text or a position in the text, so that the selection's y-position is greater than clientHeight. 3) Scroll down a bit, so that the selected text is still in view. Denote current scrollTop as A. 4) Set value. scrollTop=selectionStart=selectionEnd=0. 5) Set selectionStart/selectionEnd. The textarea scrolls until the selected text is in view. The selection should be displayed at the bottom of the textarea. However the new scroll position is not A - at position A, the selection should not appear at the bottom of the textarea. Is this intended?
Requesting attention / blocking for 2.0 via IRC request.
Not going to block 1.8.1 for this, but we'd happily consider a patch once it has baked on the trunk.
Flags: blocking1.8.1? → blocking1.8.1-
Created attachment 289312 [details] [diff] [review] mozilla-input-selection-scroll-on-focus.patch Updated patch, works for me ;)
Created attachment 432855 [details] [diff] [review] Patch (v1) Patch + test.
Comment on attachment 432855 [details] [diff] [review] Patch (v1) bz's out, switching the review request to roc.
Attachment #432855 - Flags: review?(bzbarsky) → review?(roc)
Attachment #432855 - Flags: review?(roc) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
You need to log in before you can comment on or make changes to this bug.