168135 - Support xlinks in typeaheadfind

Status: VERIFIED FIXED

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

Description

[Aaron Leventhal]

Xlinks are not currently supported by typeaheadfind.

Heikki, can you provide me with some sample pages using xlinks that work in Mozilla?

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Look at mozilla/content/xml/tests/xmlbase/xmlbase.xml. Per the spec
(http://www.w3.org/TR/xlink/) an element becomes a simple XLink if it has
xlink:type="simple" attribute (where xlink can be any prefix that is bound to
the XLink namespace http://www.w3.org/1999/xlink), but we sometimes (for perf
reasons) just check if there is a non-empty xlink:href attribute. It isn't
really important untill we also implement extended links. I'll attach a testcase
that has elements with either xlink:type or xlink:href or both so you can see
what we display as link.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: testcase

Comment 3

[Aaron Leventhal]

Attachment: Supports xlinks by typing for type="simple" and non-empty href attribute. Also moves atom creation out of the loop (duh)

Seeking r=

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

You can make it a little faster still. Since only XML elements can be simple
XLinks in our implementation, and since no XML element implements nsILink
interface, you can make it so you only check for XLink if QI to nsILink failed.
Dunno if it would make it any faster, but you could also check the type of the
content (IsContentOfType(eHTML)) and only check for XLink if it is not HTML.

Comment 5

[Aaron Leventhal]

Attachment: Checks content type, as Heikki suggests, for perf improvment to patch

Seeking r=

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 99103 [details] [diff] [review]
Checks content type, as Heikki suggests, for perf improvment to patch

r=heikki

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 99103 [details] [diff] [review]
Checks content type, as Heikki suggests, for perf improvment to patch

sr=jst

Comment 8

[Aaron Leventhal]

checked in

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

we should probably check for the xlink:href attribute even if
IsContentOfType(eHTML) returns true since that is the case for XHTML. Or?

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

You can set XLink attributes on XHTML elements, but it won't act like a link -
the implementation is in nsXMLElement, and all XHTML elements has their own,
different implementations. We don't want to add XLink processing to all the HTML
elements, at least for now. Therefore the current implementation is ok.

Comment 11

[sairuh (rarely reading bugmail)]

tested using 2002.09.24.08 mozilla trunk builds.

typeahead find found two instances of "simple" in the attached test case:

xlink:type="simple" xlink:href="http://www.mozilla.org"

and

xlink:type="simple" xlink:href=""

this works fine... but i noticed something else: while i can certainly
mouseclick the xlink (ie, the first one to mozilla.org) to load the link,
hitting the Enter key doesn't do anything (it should also load the link). is
this a known issue?

Comment 12

[Aaron Leventhal]

Sairuh, no that sounds like a big accessibility bug with xlinks -- Heikki did
you know about that?

Also modifier+Enter needs to work the same way as on links.

Comment 13

[sairuh (rarely reading bugmail)]

filed bug 170820 for what i saw in comment 11.

vrfy'ing this one since typeahead find itself works with xlinks.