Closed Bug 29800 Opened 25 years ago Closed 24 years ago

scroll bar warps when focus is lost and regained

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tdanner, Assigned: saari)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [nsbeta2-] [nsbeta3+] fixinhand) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.15pre7 i686; en-US) Mozilla/m14
BuildID:    2000022808

When a link of the form <a href="#name">...</a> is used to jump down the page,
if the X input focus is removed and reapplied, the view will warp back up to
where the link is, when it was previously at the target of the link.

Reproducible: Always
Steps to Reproduce:
1. Go to the given url
2. Click on one of the links at the top (in the bank of section headings). This
will send you down the page
3. Move the X input focus to another window
4. Move the input focus back to mozilla


Actual Results:  The viewport warps up to where the link was clicked

Expected Results:  The viewport should not move just because you shifted the
focus around

Similar behavior occurs if you click an off-page link (<A href="http://...">),
then click stop, then manually scroll down the page to read more of it, then
remove and reapply X input focus as described above. I'm reporting this on the
<a href="#..."> type links because it requires fewer steps to reproduce that way.
moving to layout, could be a dup or related to 23311
Assignee: cbegle → troy
Component: Browser-General → Layout
QA Contact: asadotzler → petersen
Works okay on NT so it looks to be Linux specific
Assignee: troy → kmcclusk
I can get it to fail on both WINNT and Linux. Moving from Linux specific to All 
platforms.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Target Milestone: M15
i get a similar thing on a mac. it happens when you right-click on a link.



1. right-click on link (choose something that doesn't change the page, or choose

nothing)

2. scroll up or down so that link is no longer visible on the page.

3. switch to another page (in any app)

4. switch back to original page



the page will scroll so the link that you right-clicked on is now visible.

the desired behaviour is that the page shouldn't scroll at all.



using build 2000-03-08-13


*** Bug 33685 has been marked as a duplicate of this bug. ***
Bulk moving to M16
Target Milestone: M15 → M16
Viewer does not warp, but mozilla does.

The warping is done by in the nsEventStateManager::PreHandleEvent in the 
NS_ACTIVATE: case

nsView::SetPosition(nsView * const 0x034000b0, int 0, int -1830) line 830
nsScrollPortView::ScrollTo(nsScrollPortView * const 0x03400908, int 0, int 1830, 
unsigned int 2) line 312
PresShell::ScrollFrameIntoView(const PresShell * const 0x033ded80, nsIFrame * 
0x025ac3f0, int -1, int -1) line 2620
nsHTMLAnchorElement::SetFocus(nsHTMLAnchorElement * const 0x0340d0dc, 
nsIPresContext * 0x03810300) line 256
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0334a2f0, 
nsIPresContext * 0x0289b540, nsGUIEvent * 0x0012f3d4, nsIFrame * 0x00eb19c0, 
nsEventStatus * 0x0012f33c, nsIView * 0x0289cc80) line 422

It looks like the event state manager's focus is set to the element with <a 
href="#name"> after the link is clicked on. When the window is activated the 
event state manager restores the focus which causes the <a href="#name"> frame 
to be scrolled into view.

I think we need to clear the focus or set the focus to the element that is 
scrolled to, instead of leaving the focus set on the <a href="#name">.

Changing component to Event Handling.

Reassigning to joki.
Assignee: kmcclusk → joki
Status: ASSIGNED → NEW
Component: Layout → Event Handling
Per our conversation, reassigning to saari.
Assignee: joki → saari
Focus memory needs to call an as yet unwritten API that doesn't scroll the 
focused content into view.
Status: NEW → ASSIGNED
This also can happen when you drag and drop a link from one window to another on
my linux box with build 2000042709.  When going from any x window back to the
browser the linked was dragged from, that window will warp sometimes to show the
dragged link.  TD&D links were just intoduced, here's the contact info from the
Mozilla status page:
XPToolkit
Apr 24

  Mike Pinkerton  (pinkerton):

Can drag links from w/in content area (thanks to Kevin Puetz, puetzk@iastate.edu)

can't repro right now due to anchors not working at all, but nominating for 
nsbeta2
Keywords: nsbeta2
Joki, we're calling SetFocus on the content node... should I add an API to 
nsIContent along the lines of SetFocusDontScroll ?
Fixed. 

However, if you put focus in a text field, scroll it off screen, deactivate, 
activate and type, we will not bring the field back on screen. That is a bug that 
ender (mjudge) is going to handle. We'll probably have to handle that case for 
each widget that can accept focus.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Fixed in the July 6th build.
Status: RESOLVED → VERIFIED
This appears to have regressed on the linux build.. Following the orginal
reporters steps works.

*** Bug 46383 has been marked as a duplicate of this bug. ***
Verified with build 2000072608

This regressed.  Confirmed on Linux build 2000072521, M17.  To reproduce, you
must lose the focus in a certain way.  For example, with my WM settings, I must
either alt-tab to another window, or move the mouse out through the SIDE of the
mozilla window.  Moving the mouse out through the BOTTOM of the mozilla window
does not display the bug.
Status: VERIFIED → REOPENED
Keywords: regression
Resolution: FIXED → ---
This is worse on today's nightlies: 2000072709 (M18) and 2000072608 (M17).  The
browser is now jumping back to a link that you open in another window.  example:

1) http://www.tbtf.com/
2) Open one of the links near the top of the page in a new window
3) Scroll first window down
4) Focus new window
5) Focus old window

Result: old window jumps up to the link that you opened in the new window.
This appears to be fixed, tested on MacOS and Win 2K. Marking worksforme
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
OS: All → Linux
Hardware: All → PC
Resolution: WORKSFORME → ---
Reopening because this is definitely broken.  Please don't mark WFM without
testing all three major platforms.  I moved this from all/all to pc/linux.
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
(Sorry for updating twice.) I should add that I am getting the same results from
8/4 CVS even in cases where <a href="#name">...</a> (as mentioned in the
original report) is not used. This behavior is very annoying.
*** Bug 47969 has been marked as a duplicate of this bug. ***
*** Bug 48567 has been marked as a duplicate of this bug. ***
CCing bryner

Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.288
diff -r1.288 nsWindow.cpp
117a118
> PRBool gJustGotDeactivate = PR_FALSE;
1065c1066
<   if (gJustGotActivate) {
---
>   if (gJustGotActivate && gJustGotDeactivate) {
1067a1069
>     gJustGotDeactivate = PR_FALSE;
1161a1164,1165
>
>   gJustGotDeactivate = PR_TRUE;
Nominating nsbeta3, fix in hand!
Keywords: nsbeta3
Whiteboard: [nsbeta2-] → [nsbeta2-] fixinhand
I added this patch to my local build, pulled at 2000-08-13-17, and the problem
still exists.
Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.288
diff -r1.288 nsWindow.cpp
12c12
<  *
---
>  *'
117a118
> PRBool gJustGotDeactivate = PR_TRUE;
1065c1066
<   if (gJustGotActivate) {
---
>   if (/*gJustGotActivate &&*/ gJustGotDeactivate) {
1124d1124
< #ifdef DEBUG_FOCUS
1126c1126,1130
< #endif /* DEBUG_FOCUS */
---
>
>   if(!gJustGotDeactivate)
>     return;
>
>   gJustGotDeactivate = PR_FALSE;
1145d1148
< #ifdef DEBUG_FOCUS
1147c1150,1151
< #endif /* DEBUG_FOCUS */
---
>
>   gJustGotDeactivate = PR_TRUE;

Okay, try the above patch, should work better. The gtk widget code just needs
some tough love.
Yep, I can't reproduce this with your latest patch.

Fixed on Linux 2000-08-15-05
I meant to say still NOT fixed on Linux 2000-08-15-05.  Ignore me.
I didn't check in the fix yet...
nsbeta3+ to take fix, P4 for M18
Priority: P3 → P4
Whiteboard: [nsbeta2-] fixinhand → [nsbeta2-] [nsbeta3+] fixinhand
Target Milestone: M16 → M18
bryner, could you pleas review the patch? r=bryner?
Sure.  I've been running with it in my tree for awhile and haven't seen any bad 
effects.  r=bryner.

Fixed
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Looks fixed with both of my testcases on Linux debug build pulled ~2000-08-16-21.
Verifying, thanks
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.