170837 - Using typeaheadfind, Ctrl-G highlights next search but then jumps to top of section

Status: RESOLVED WORKSFORME

(SeaMonkey :: Find In Page, defect, P5)

Description

[Leo Zelevinsky]

To reproduce, go to the reference URL, then in text search mode, type in
"words", then hit ctrl-G. There are 6 occurrences of "words" on the page, and
regular ctrl-F find finds them easily. But, when every time I hit ctrl-G, I
momentarily see the next match highlighted, then the web page rewinds to show
the section title. This holds true for every time when the "words" is the first
occurrence in the section. 

This happens to me with all builds I've tried, including 2002092508.

Comment 1

[Aaron Leventhal]

With regular Ctrl+F, but checking "Wrap around", do you experience the same problem?

Comment 2

[Leo Zelevinsky]

No, regular find with wrap around works fine. I hit Ctrl-F, enter words, then
keep clicking find and it goes through the 6 entries. At the bottom of the page,
it says "The text you entered was not found", but then I click OK, and find
again and it keeps going nicely.

Ah, but you see what you mean - when I cancel out of the ctrl-F box, and hit
ctrl-G, I observe the same behavior - except when I get to the bottom of the
page it doesn't wrap around and just gives the alert box.

Comment 3

[Aaron Leventhal]

Why does all the text get underlined on mouseover in Mozilla but not IE?
I have a feeling that has to do with some weird html, perhaps some <a> tags that
aren't closed or something.

Comment 4

[Aaron Leventhal]

Marking it P5/minor/Future until it's clear that this problem exists on more
than 1 website.

Comment 5

[Leo Zelevinsky]

I have no idea why the text gets underlined the way it does.

I didn't think that was related to the problem since if you go to the
"printer-friendly" link on top to get to:
http://216.127.88.11/tracing/on/index.php?printer=1
it doesn't do the weird underlining thing, but the find fails the exact same way.

Comment 6

[Adam Katz]

hover problem is the <a name="header"><a name="header> on line 273.
http://validator.w3.org/check?uri=http%3A%2F%2F216.127.88.11%2Ftracing%2Fon%2F&doctype=HTML+4.01+Transitional

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021010
(i think this is the 1.2b release)
verify, moz1.2b winxp.

ctrl+f with wrap-around works in all manners ...except it does not wrap around.
by "titles" he means each anchor in the page (like <a name="black"></a> for example)
typeaheadfind does not wrap either.

note: the referenced page is currently channelled to a mirror,
http://216.127.88.11/tracing/on/
and bugzilla is best served by an attachment specifically designed to exhibit
the bug
(in this case that would entail a html doc with >2 pages of text and several
anchors.  there would be 'word' spread throughout the body.)

Comment 7

[Adam Katz]

Attachment: referenced url, with more conformity to html standards

i could not recreate this bug in a test document.
i downloaded and fixed a few html/css errors (but not all), here it is.
(i can edit this later, right? need to run through validator...)

i was thinking the problem is due to html/css errors, trying to eliminate that

Comment 8

[Adam Katz]

Attachment: referenced url, with more conformity to html standards

this should fix the problems with <a name="blah"> w/out end tags and/or in
illicit places.

Comment 9

[Adam Katz]

(sorry about all the emails)
i crashed mozilla twice testing this...
talkback id's are TB12913796M and TB12911743Y

and it looks like i failed to fix the 'Error: element "A" not allowed here'
validation problem (needs to be in a proper text wrapper like <p>...</p>)
i still think that's the culprit.

Comment 10

[Michael Lefevre]

still happens in today's nightly, so confirming.

not sure this is a bug that needs fixing - Aaron's guess in comment 3 is
correct. the page has <a name=> tags which aren't closed, which results in
multiply nested <a> tags. it seems that type ahead find is jumping to what it
thinks is the beginning of the <a> tag which contains the searched term. if you
close all the <a> tags (HTMLTidy does it...), then it works as usual.

Comment 11

[Aaron Leventhal]

I don't see a reproducable test case here anymore.

Is this bug still happening?

Comment 12

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Comment 13

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME