Closed
Bug 267236
Opened 20 years ago
Closed 19 years ago
Find Toolbar does not find links enclose in more tags than <a>
Categories
(Toolkit :: Find Toolbar, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: brunoabdon+moziilabugzilla, Assigned: bugzilla)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 If a link contais some markup inside the <a href="..."> tags, fast find won't find it. Reproducible: Always Steps to Reproduce: 1. Go to http://www.w3.org/TR/html401/ 2. Type 'title Actual Results: The Find Toolbar says there no link with the text "title" Expected Results: FindToolbar should be able to find the link "The TITLE element" (section 7.2). The proble is that the html code for the link is (like): <a href="...">The <samp>TITLE</samp> element</a> and as the "title" text is inside the <samp> tag, the Find ToolBar is failing to find it. This used to work with normal FastFind, before the introduction of the FindToolbar in 1.0PR
Comment 1•20 years ago
|
||
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041030 Firefox/1.0RC2
Reporter | ||
Comment 3•20 years ago
|
||
setting version to 1.0; (should have done it while reporting)
Version: unspecified → 1.0 Branch
Reporter | ||
Comment 4•20 years ago
|
||
I am sorry, Gary, but this does not works for me on (Note this is RC2): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2 Could you please confirm this really really works for you? By the way the 'rv' part means? Why my FFRC2 is rv:1.7.5 and yours is rv:1.7.3? Is it Gecko's version? Thanks
Comment 5•20 years ago
|
||
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2
Comment 6•20 years ago
|
||
Doesn't work for me. Steps to reproduce are as in comment 0 exactly. Nearly clean profile. typeaheadfind=true TAF.linksonly=true other TAF prefs set to default. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041106 Firefox/1.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 7•20 years ago
|
||
One more test case. 1. Go to about:config 2. Type accessibility.typeaheadfind on the filter 3. Set accessibility.typeaheadfind property (the first one) to TRUE 4. Reset all other accessibility.typeaheadfind.* options to the default values 5. Go to http://www.w3.org/TR/html401/ 6. Type "title" WITHOUT the quotes. 6.1. At this point, typeahead find will find the 'title' link on section 7.4.2, in the text "The title Element". This is ok and expected 7. Reload the page 8. Type "'title" WITHOUT the double quotes (WITH the single quote at the beginning). 8.1 At this point, you will notice typeaheadfind WON'T find the link 9. Press "Esc" key (to dismiss the find bar) 10. Type "'html" WITHOUT the double quotes (WITH the single quote at the beginning). 10.1. At this point, you will notice typeahead find WAS ABLE to find some link with the HTML text. The point is, as the "title" text in the link "The title Element" is inside an <samp> tag, nested within the <a> tag, typeaheadfind fails to find it. Hope this helps. Thanks for the attention, sorry for not being so specific while reporting.
Comment 8•20 years ago
|
||
Still WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Typing in "'title" will find "'title" and not "title". The single quote is taken as a part of what you are looking for. Not that if the find ahead toolbar is closed, pressing ' will bring the toolbar up. If the toolbar is allready open, pressing ' will include the ' as a part of the search. This behaviour may be what was confusing you. I has nothing todo with the fact that the text is in a <samp> in a <a>
Comment 9•20 years ago
|
||
the point is: you don't type in the find toolbar. You use find-as-you-type (typeahead find) in links-only mode. *Then* it doesn't work
Comment 10•20 years ago
|
||
It is not reproducible either in a clean profile or in my current profile now, though it was reproducible earlier. Looks like it is only visible under certain circumstances. I'm sure it is not an extension related problem, though. bruno, please create a smaller testcase and figure out steps to reproduce starting from Firefox 1.0 + clean profile.
Comment 11•20 years ago
|
||
I can confirm that I did have this exact problem since PR 1.0. But the problem was more of a generic problem that "Find As You Type Link" couldn't find any text in the link if you didn't type the text from the start of the link. 1. So if you press ' (while at http://www.w3.org/TR/html401/) 2. And type "The title Element" It will find the link. However if you just type "title" it won't find anything. The same also work for, if you type "element" it won't find the element inside the link "The title Element" However I found that it was just a profile problem, I renamed my Firefox directory in C:\Documents and Settings\Joel Pearson\Application Data\Mozilla to Firefox.old and I found the problem went away. Then when used my old profile again it came back. I haven't created a new profile since 0.9 I think. So basically the problem is something in the profile is screwing things up if you didn't create a new profile in PR 1.0 I think. Hope that helps
Comment 12•20 years ago
|
||
I did a bit more research and I found that the accessibility.typeaheadfind.startlinksonly was set to true on my broken profile. For some reason that setting makes 'find as you type link' only search from the beginning of the link.
Comment 13•19 years ago
|
||
Hi. I am also seeing this problem. Indeed this problem nags me all the time, not only in rare cases. It does not really have anything to do with there being nested tags inside the <a>; for me it just plainly doesn't work in about 50% of the cases. (I have accessibility.typeaheadfind.startlinksonly set to FALSE.) Often I would type the text of a link and it would refuse to find it, but then I press F3 and suddenly it finds it. Sometimes, however, even that doesn't work. Just now I decided to search for "Show list" on this very page (https://bugzilla.mozilla.org/show_bug.cgi?id=267236) and again it didn't find the link, but when I pressed F3 it did. This seems to be consistently reproducible for me. This is Firefox 1.0, Windows XP SP2, and I have the following Firefox extensions installed: stumbleupon, Tabbrowser Preferenes, FLST, SessionSaver .2, Configuration Mania, undoclosetab.
Comment 14•19 years ago
|
||
I forgot to mention: I am seeing this problem not only with links. When I press "/" and search for text on the page, I get the same behaviour. Again, on this very page, I can consistently reproduce it: I press "/", type "windows nt" and it doesn't find it, but when I press F3 it changes its mind and jumps to the beginning of comment #0.
Reporter | ||
Comment 15•19 years ago
|
||
This seems to have disapeared with FF 1.01 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1). I'm using the same profile as before. The test case in #0 now gives me the expected results. accessibility.typeaheadfind=true accessibility.typeaheadfind.flashBar=0 accessibility.typeaheadfind.linksonly=true accessibility.typeaheadfind.autostarttrue accessibility.typeaheadfind.startlinksonly=false Should I mark it as WFM?
Comment 16•19 years ago
|
||
This is a strange bug. I reproduced it using 1.0.4 when initially viewing the page, but failed to do so after that. The Find code does take into account nested <a> elements, per: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp&rev=1.105#1577 I haven't tested a recent trunk build, and I would highly doubt it's been fixed there anyways.
Comment 17•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050621 Firefox/1.0+ ID:2005062110 WFM with <html> <head> <title></title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <a href="#"><div><p><span>testlink</span></p></div></a> </body> </html>
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•