If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

deleting selected top of document (from below) no longer scrolls what remains into view

VERIFIED FIXED in mozilla1.9.1b3

Status

()

Core
Editor
--
major
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: dbaron, Assigned: mstange)

Tracking

({regression, verified1.9.1})

Trunk
mozilla1.9.1b3
regression, verified1.9.1
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

When selecting multiple pages at the top of the document, such that it's the bottom end of the selection that's visible, and then deleting that part, we no longer scroll the remaining (short) part of the document into view.

(There are probably some other similar steps to reproduce, but I'm keeping the description specific for now.  It does seem to be a requirement that the amount of stuff left in the textarea is not enough to require scrollbars, though.)

Steps to reproduce:
 * load https://bugzilla.mozilla.org/attachment.cgi?id=351052&action=edit
 * click "Edit attachment as Comment"
 * place the mouse cursor at the very beginning of the textfield
 * hold down the Shift key and press PgDn three times, and then the down arrow to get down to the "case NS_THEME_CHECKBOX" line
 * press backspace to delete the selection

Expected results: remaining part of the field is entirely visible

Actual results: field appears blank, but things become visible again if you hit the down arrow key

This regressed between Linux nightlies 2008-12-04-02-mozilla-central and 2008-12-05-02-mozilla-central.
Flags: blocking1.9.2?
My first guess was http://hg.mozilla.org/mozilla-central/rev/f7e30552f3a7 but that does not seem to be the cause.
This was caused by http://hg.mozilla.org/mozilla-central/rev/cfc553938038 .
Blocks: 463042
(Assignee)

Updated

9 years ago
Assignee: nobody → mstange
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Created attachment 351630 [details]
a mochitest for this bug

(Needs to be dropped into objdir/_tests/testing/mochitest/tests/ somewhere to be run... or eventually put into a patch.)
Created attachment 351638 [details]
a mochitest for this bug

Oops, don't cross keyCode and charCode, which prevents a weird character from showing up.  (I'm surprised it worked at all.)
Attachment #351630 - Attachment is obsolete: true
(Assignee)

Comment 5

9 years ago
This is the change that caused this bug:

--- a/layout/generic/nsGfxScrollFrame.cpp	Thu Dec 04 14:17:48 2008 +0100
+++ b/layout/generic/nsGfxScrollFrame.cpp	Tue Dec 02 14:18:08 2008 +0100
@@ -1910,7 +1910,8 @@ void nsGfxScrollFrameInner::CurPosAttrib
       InternalScrollPositionDidChange(curPosX, curPosY);
       mFrameInitiatedScroll = PR_FALSE;
     }
-    ScrollbarChanged(mOuter->PresContext(), x, y, isSmooth ? NS_VMREFRESH_SMOOTHSCROLL : 0);
+    ScrollbarChanged(mOuter->PresContext(), x, y,
+                     isSmooth ? NS_VMREFRESH_SMOOTHSCROLL : NS_VMREFRESH_DEFERRED);
   }
 }

It wasn't necessary in the first place, so I just backed it out:
http://hg.mozilla.org/mozilla-central/rev/e8c07223b324

Then I added your test (after double-checking that it works):
http://hg.mozilla.org/mozilla-central/rev/28c7880df205

Thanks for the test!
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: blocking1.9.2?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Comment 6

9 years ago
I didn't track down the real cause of this bug; I suspect that some part of the codepath made the assumption that ScrollTo is synchronous when smooth scrolling isn't used (which was no longer true after bug 463042). The fact that nsGfxScrollFrameInner::CurPosAttributeChanged does extra work when using smooth scrolling supports this theory.
(Assignee)

Updated

9 years ago
Flags: in-testsuite+
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/18ddfb10612a
Keywords: fixed1.9.1
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
Seeing that there haven't been any duplicate sightings for this issue for 4
months, I'm going to go ahead and verify this unless someone has an issue with
that.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.