Closed Bug 485213 Opened 17 years ago Closed 16 years ago

Link selected by typeahead is not the link that is followed

Categories

(SeaMonkey :: Find In Page, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey2.0

People

(Reporter: incoming, Assigned: neil)

References

()

Details

(Keywords: fixed-seamonkey2.0, regression)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090323 SeaMonkey/2.0b1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090323 SeaMonkey/2.0b1pre Typeahead find searches for and highlights the desired link. However, hitting the Enter key jumps to the wrong link. Reproducible: Always Steps to Reproduce: 1. Preferences | Advanced | Keyboard Navigation | FAYT -> select Find Automatically... . Option "Any Text" or "Links Only" does not seem to make a difference. 2. go to the URL mentioned 3. type "othe" to select the "others" link. It's highlighted, as expected. 4. hit the enter key Actual Results: Jumps to the "community" link from the page banner. Expected Results: Should jump to the file listing that "others" links to. This is what happens if you mouse-click on "others." This works correctly (using typeahead find) in Seamonkey 1.1.14. The problem is related to the link being found in the frame that contains the file listing. If you do this: 1) go to www.dd-wrt.com 2) type "downlo" to find and select the downloads link 3) press Enter then the correct page gets loaded, apparently because the link found was embedded in the page. Once on the downloads page, you will have the problem as described above when trying to jump to a link in the file listing, which appears to be in a frame.
Flags: blocking-seamonkey2?
Version: unspecified → Trunk
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090404 SeaMonkey/2.0b1pre I see the same kind of problem at http://java.sun.com/javase/6/docs/api/ with the difference, that there no page is opened at all.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We have a bit too little information on this to be completely clear on this, but with not more reports coming in after shipping betas, I don't think it's something we should block a release on. If you find out the problem and provide a patch, we'd be happy to take it, though.
Flags: blocking-seamonkey2.0? → blocking-seamonkey2.0-
(2 months) regression timeframe: (from the builds I have locally) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081016 SeaMonkey/2.0a2pre] (nightly) (W2Ksp4) Work fine. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081207 SeaMonkey/2.0a3pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20090130 SeaMonkey/2.0a3pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2] (release) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090912 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4) Reproducible.
Flags: wanted-seamonkey2.0?
Flags: wanted-seamonkey2.0? → wanted-seamonkey2.0+
I think this is a bug in the way the Toolkit typeaheadfind component focuses the found link when the link is in a frame. We can work around this in 1.9.1 but maybe Enn can comment on why it doesn't work using trunk mozilla-central.
Attached patch WorkaroundSplinter Review
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #401663 - Flags: review?(iann_bugzilla)
Attachment #401663 - Flags: review?(iann_bugzilla) → review+
Attachment #401663 - Flags: approval-seamonkey2.0?
Comment on attachment 401663 [details] [diff] [review] Workaround This bug is wanted‑seamonkey2.0+ so actually wouldn't need explicit approval at this stage.
Attachment #401663 - Flags: approval-seamonkey2.0? → approval-seamonkey2.0+
Pushed changeset e1203cdca9e5 to comm-central.
The issue lies in the nsIFocusManager::FLAG_NOSWITCHFRAME flag passed to MoveFocus. If it's removed, it works ok. However, Firefox needs this or the find field keeps blurring and reseting. The difference is that Firefox has a findbar with a search field, and Seamonkey doesn't display a field when using type ahead find.
Ah, so in fact this patch is the correct fix, in that it switches the frame.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090921 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4) V.Fixed.
Status: RESOLVED → VERIFIED
Target Milestone: --- → seamonkey2.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: