Closed Bug 242056 Opened 20 years ago Closed 20 years ago

Selection doesn't scroll to find position when the match is inside a very long <a> tag

Categories

(Core :: DOM: Selection, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.7final

People

(Reporter: aha, Assigned: rbs)

References

()

Details

(Keywords: fixed1.7, testcase)

Attachments

(2 files)

2004042109/1.7RC1/W2K

Repro:
1. open page http://www.cen.uiuc.edu/bstats/days/97-09/970909.html
2. search for example "PlanetWeb"
3. after first match skip to the begin of page, click with mouse somewhere to 
   text
4. hit F3 to search again

Actual:
Browser after step 4 skips to line with:
"Hosts       Specific Browser Version"
not to line with "PlanetWeb", which isn't shown on display.

Expected:
Browser should skip to line/screen with PlanetWeb string.

Maybe small hint about "why" is in HTML source snippet, see unclosed "<a name=...":

=====================
<p>
<a name=BrowserDNS>
<h2>Browser DNS Domains</h2>
<pre>
 Browser DNS Domains            Hosts     %
 ------------------------------------------
  1. edu                         2941  23.6
  2. unregistered                2573  20.6
=====================

In DOM-view this "A NAME" is repeated:
=====================
<h2><a name="BrowserDNS">Browser Versions - All</a></h2>
<pre><a name="BrowserDNS"> Hosts       Specific Browser Version
 ---------------------------------------------------------------------
 1           AIR_Mosaic(16bit)/v1.00.198.07
 1           AIR_Mosaic(16bit)/v3.10.06.07
 7           Active Worlds Browser
 1           AltaVista Top1000 CustomCrawl
 1           Amiga-AWeb/3.0DEMO
=====================

Maybe it's Parser bug...
Confirming with a Linux build from yesterday and Firefox 0.8.

Find does not work if the search result is inside a very long <a> tag. Other
tags like <pre> or <span> don't show this problem.

Browser/Search is the wrong component for this. Lets try Browser/XP Apps:GUI
Features, but this may be wrong either.
Assignee: search → guifeatures
Status: UNCONFIRMED → NEW
Component: Search → XP Apps: GUI Features
Ever confirmed: true
OS: Windows 2000 → All
Summary: browser doesn't skip to search result location → Browser doesn't skip to search result location when it is inside a very long <a> tag
Attached file Testcase
Instructions how to use this testcase:
  1. Load the testcase into the browser
  2. Select "Edit|Find in this page..." and enter the search term "bug"
  3. Press the Find button so "bug" becomes the active search term
  4. Close the find dialog
  5. Click with the mouse at the beginning of the document
  6. Select "Edit|Find Again"

Result:
In Step 6 Mozilla doesn't jump to the first occurance of the string "bug".
Keywords: testcase
Assignee: guifeatures → mozeditor
Component: XP Apps: GUI Features → Editor: Core
QA Contact: bugzilla
Summary: Browser doesn't skip to search result location when it is inside a very long <a> tag → Selection doesn't scroll to find position when the match is inside a very long <a> tag
See also bug 78833.
One thing I notice with that testcase: when I do "find again" (I'm using the
accel-G keybinding) it actually does skip to the right place, and I very briefly
see "bug" selected at the bottom of the page; then it skips back to the
beginning of the document.  So the question is, what's making it scroll back home?

I'm not seeing any editor involvement here at all (I tested in a browser window
and saw the problem).  Seems like whatever is making it scroll the second time
is either in the find code or (more likely) in the selection controller's
ScrollSelectionIntoView.  Changing component to Selection.
Assignee: mozeditor → selection
Component: Editor: Core → Selection
QA Contact: bugzilla
re: comment 4

> I very briefly see "bug" selected at the bottom of the page; then it skips
> back to the beginning of the document.  So the question is, what's making it
> scroll back home?

I found the problem. See the stack trace below. MoveFocusToCaret() gives the
focus to <a>, which causes another ScrollFrameIntoView(). However, this one is
targeted at the primary frame -- not at the continuation frame that is selected.
Hence the scroll destroy the more careful scrolling that the find's selection
die earlier.

The fix is simply to change the order. Will attach a patch.

PresShell::ScrollFrameIntoView(const PresShell * const 0x0347b3d0, nsIFrame *
0x0362bcd4, int -1, int -1) line 4241 + 35 bytes
nsHTMLAnchorElement::SetFocus(nsIPresContext * 0x03008148) line 286
nsEventStateManager::FocusElementButNotDocument(nsIContent * 0x034ae418) line 4742
nsEventStateManager::MoveFocusToCaret(nsEventStateManager * const 0x035d3630,
int 1, int * 0x0012b218) line 4840
nsWebBrowserFind::SetSelectionAndScroll(nsIDOMWindow * 0x03462b7c, nsIDOMRange *
0x034a85a0) line 470
nsWebBrowserFind::SearchInFrame(nsIDOMWindow * 0x03462b7c, int 0, int *
0x0012b600) line 807
nsWebBrowserFind::FindNext(nsWebBrowserFind * const 0x03579fb0, int *
0x0012b600) line 157 + 23 bytes
XPTC_InvokeByIndex(nsISupports * 0x03579fb0, unsigned int 3, unsigned int 1,
nsXPTCVariant * 0x0012b600) line 102
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2027 + 43 bytes
XPC_WN_CallMethod(JSContext * 0x02d565f8, JSObject * 0x00ec9ac8, unsigned int 0,
long * 0x03614868, long * 0x0012b8d0) line 1287 + 14 bytes
js_Invoke(JSContext * 0x02d565f8, unsigned int 0, unsigned int 0) line 1281 + 23
bytes
js_Interpret(JSContext * 0x02d565f8, long * 0x0012c304) line 3366 + 15 bytes
js_Invoke(JSContext * 0x02d565f8, unsigned int 1, unsigned int 2) line 1301 + 13
bytes
js_InternalInvoke(JSContext * 0x02d565f8, JSObject * 0x02d93d00, long 47791384,
unsigned int 0, unsigned int 1, long * 0x0012c568, long * 0x0012c564) line 1378
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x02d565f8, JSObject * 0x02d93d00, long
47791384, unsigned int 1, long * 0x0012c568, long * 0x0012c564) line 3618 + 31 bytes
nsJSContext::CallEventHandler(JSObject * 0x02d93d00, JSObject * 0x02d93d18,
unsigned int 1, long * 0x0012c568, long * 0x0012c564) line 1292 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x0366ce08, nsIDOMEvent
* 0x0307b868) line 174 + 51 bytes
nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver * 0x035c3cf8,
nsIDOMEvent * 0x0307b868) line 460
nsXBLWindowHandler::WalkHandlersInternal(nsIDOMEvent * 0x0307b868, nsIAtom *
0x0026e700 {???}, nsXBLPrototypeHandler * 0x036fe720) line 324 + 24 bytes
nsXBLWindowKeyHandler::WalkHandlers(nsXBLWindowKeyHandler * const 0x02ee3d90,
nsIDOMEvent * 0x0307b868, nsIAtom * 0x0026e700 {???}) line 161
nsXBLWindowKeyHandler::KeyPress(nsXBLWindowKeyHandler * const 0x02ee3d90,
nsIDOMEvent * 0x0307b868) line 177
DispatchToInterface(nsIDOMEvent * 0x0307b868, nsIDOMEventListener * 0x02ee3d90,
unsigned int (nsIDOMEvent *)* 0x014862d0 `vcall'(nsIDOMEvent *), const nsID &
{...}, int * 0x0012ce64) line 127 + 11 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x02ee32f0,
nsIPresContext * 0x03008148, nsEvent * 0x0012f71c, nsIDOMEvent * * 0x0012f390,
nsIDOMEventTarget * 0x02ea69e8, unsigned int 514, nsEventStatus * 0x0012f540)
line 1520 + 35 bytes
nsXULDocument::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line 1239
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2813 + 51 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line
2807 + 57 bytes
nsXULElement::HandleChromeEvent(nsXULElement * const 0x033c62cc, nsIPresContext
* 0x03008148, nsEvent * 0x0012f71c, nsIDOMEvent * * 0x0012f390, unsigned int
514, nsEventStatus * 0x0012f540) line 3874 + 35 bytes
GlobalWindowImpl::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent *
0x0012f71c, nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus *
0x0012f540) line 913
nsDocument::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent * 0x0012f71c,
nsIDOMEvent * * 0x0012f390, unsigned int 514, nsEventStatus * 0x0012f540) line 3675
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x03008148, nsEvent *
0x0012f71c, nsIDOMEvent * * 0x0012f390, unsigned int 519, nsEventStatus *
0x0012f540) line 1995 + 52 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f71c, nsIView * 0x036984e0,
unsigned int 1, nsEventStatus * 0x0012f540) line 6053 + 47 bytes
PresShell::HandleEvent(PresShell * const 0x0347b444, nsIView * 0x036984e0,
nsGUIEvent * 0x0012f71c, nsEventStatus * 0x0012f540, int 1, int & 1) line 5921 +
25 bytes
nsViewManager::HandleEvent(nsView * 0x036984e0, nsGUIEvent * 0x0012f71c, int 0)
line 2187
nsViewManager::DispatchEvent(nsViewManager * const 0x0370e890, nsGUIEvent *
0x0012f71c, nsEventStatus * 0x0012f66c) line 1973 + 20 bytes
HandleEvent(nsGUIEvent * 0x0012f71c) line 79
nsWindow::DispatchEvent(nsWindow * const 0x0349cf04, nsGUIEvent * 0x0012f71c,
nsEventStatus & nsEventStatus_eIgnore) line 1067 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f71c) line 1088
nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 0, unsigned int 114,
long 3997697) line 2978 + 15 bytes
nsWindow::OnKeyDown(unsigned int 114, unsigned int 61, long 3997697) line 3057
nsWindow::ProcessMessage(unsigned int 256, unsigned int 114, long 3997697, long
* 0x0012fc28) line 3899 + 38 bytes
nsWindow::WindowProc(HWND__ * 0x003707d0, unsigned int 256, unsigned int 114,
long 3997697) line 1349 + 27 bytes
USER32! 77e11ef0()
USER32! 77e1204c()
USER32! 77e121af()
nsAppShellService::Run(nsAppShellService * const 0x00f72c58) line 524
main1(int 2, char * * 0x00263fa8, nsISupports * 0x00ebeb28) line 1302 + 32 bytes
main(int 2, char * * 0x00263fa8) line 1779 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 7c58
Attached patch fixSplinter Review
Assignee: selection → rbs
Status: NEW → ASSIGNED
Comment on attachment 147417 [details] [diff] [review]
fix

Simple fix to re-order a call of greater importance.
Attachment #147417 - Flags: superreview?(jst)
Attachment #147417 - Flags: review?(akkzilla)
Comment on attachment 147417 [details] [diff] [review]
fix

sr=jst
Attachment #147417 - Flags: superreview?(jst) → superreview+
Attachment #147417 - Flags: review?(akkzilla) → review+
Comment on attachment 147417 [details] [diff] [review]
fix

Fix checked in the trunk.

Asking a= for 1.7f. Simple nice-to-have, polish, no risk. One of these extras
that make the next release better than previous ones "in many ways".
Attachment #147417 - Flags: approval1.7?
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 147417 [details] [diff] [review]
fix

a=chofmann for 1.7
Attachment #147417 - Flags: approval1.7? → approval1.7+
Fixed on the 1.7 branch.
Keywords: fixed1.7
Target Milestone: --- → mozilla1.7final
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: