Closed Bug 30111 Opened 25 years ago Closed 24 years ago

Scrolling a windows, and then leaving and reentering it will move the page back to the first line

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla-f, Assigned: saari)

References

(
URL
)

Details

Attachments

(1 file)

This testcase will reproduce the bug (view comments in it)
1.02 KB, text/html
Details 
From Bugzilla Helper:

User-Agent: Mozilla/5.0 (X11; N; Linux 2.3.48 i686; en-US; m14)

BuildID:    2000030113



On my box, if you scroll a window using either the (vertical) scrollbar or the

cursor/pgdn keys, the window will scroll nicely and hold its position. However,

if I than leave the window (with `sloppy focus' enabled, so the window

automatically loses focus) and then re-enter it (causing focus to be restored),

the window immediately scrolls back to the first line. This bug is hard to

reproduce since it does not occur every time. I'm using the sawmill Window

Manager on a Matrox G400 (XF86_SVGA 3.3.5) on Linux, FYI.



Reproducible: Sometimes

Steps to Reproduce:

1.open a url which is known to fill more than one pagefull

2.scroll down using mouse or keyboard

3.leave window (make sure browser loses focus)

4.re-enter window. Sometimes the window content will `snap' back to line 1





Actual Results:  It sometimes snaps back to line 1



Expected Results:  Remain at the original location



During this mozilla 'session (having 5 browser windows open) I just `lost' the

ability to reproduce this bug. It disappeared once I started filling out this

form. Some weird interaction with GTK adjustment objects getting clobbered?

*** This bug has been marked as a duplicate of 16806 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verified dupe.
Status: RESOLVED → VERIFIED
The duplicate bug referred to here is considered fixed, but this problem still
happens on 2000080104 (M17) on Linux.  I have noticed that this happens more
often with bugzilla pages than others.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
possibly related to bug 46877?
 I've been seeing this a fair amount lately, although non-reproducibly,
in various current CVS builds over that time. As a wild-assed theory,
might it have something to do with either a) table boundaries or b)
link anchors buried in the HTML? If I can make it happen, I'll see what
the page structure looks like.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This might be a GTK bug, not a Mozilla specific thing. I;ve seen it happen in
other (GTK-based) applications as well. Unfortunately, I can find no GTK app
which exhibits this behaviour on my system right now. Does the Windows version
of Mozilla suffer from this bug?
taking this bug while it is investigated
Assignee: cbegle → asa
this testcase does not cause a scroll to happen in 080808 win32 mozilla builds
Test case works (causes the bug) with 2000080808 under linux.

Test case from 08/08/2000 does not reproduce bug on Win2K build (20000808)
Test case causes bug in Linux 2000080808
over to event handling
Assignee: asa → joki
Component: Browser-General → Event Handling
QA Contact: asa → janc
The test case was created under linux (build 080720).
I tested it again and causes the bug every time.
the bug will happen (on linux) also if you drag a link
(no matter where you drop it), scroll the view to make
the link disappear, switch to another window and come
back (if you have focus follow mouse, it suffice to move
the mouse out and in the window).
Reporter:  Can you repro this behaviour on all platforms with the latest m18 
bits?  Thanks!
I'll test on Linux, since that's the only platform I have running in my current
setup. I'll leave the others to errrr... the others?

[runs off and types 'rebuild mozilla']
Just tried to compile latest bits... nsCSSFrameConstructor.o] Error 1

Oops... will try again when the fire is down...

OK, I tried it with a fresh (Linux) CVS build, and the bug occurs reliably,
every time. This is a trustworthy bug, one you can depend on, really solid
etcetera. But still a bug...

Chris, I see you have added some stuff to PresShell::ScrollFrameIntoView that 
prevents us scrolling in certain situations. These two bugs fall in the same 
category.
Assignee: joki → saari
*** Bug 49435 has been marked as a duplicate of this bug. ***
This bug seems fixed in linux build 082921.
cc pavlov
resolving as fixed.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Updating QA Contact.
QA Contact: janc → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
FYI, this bug is still around, even though it hardly ever raises its ugly head.
I see the effect very sporadically, but it still happens.
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-08-08-trunk
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: