Closed Bug 29800 Opened 26 years ago Closed 25 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: 26 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: 26 years ago → 25 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: 25 years ago → 25 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.