OZtree
OZtree copied to clipboard
OneZoom
Search results can include nodes that aren't in the OZ tree
Expected
Search results on the explorer on onezoom.org should all be clickable and take you to a place on the tree
Actual
Some results don't have a place on the tree and show an error when clicked. Particular examples are when searching for 'Foxes' or 'Flying foxes'
https://github.com/user-attachments/assets/3b2b610b-3867-4fb9-82ea-40b41b8cbc6e
Hmm, this is very well observed with "foxes". We currently have 3 OTTs with the exact vernacular "foxes": 770319, 821970, and 372706. These all exist in ordered_nodes.
The problem seems to be that the first hit in the search term is Clade1634_, and thereafter, all the links (even the ones labelled "Vulpes", are to https://www.onezoom.org/life/@Clade1634, e.g. <a href="https://www.onezoom.org/life/@Clade1634">Vulpes</a>. I wonder if we are doing something weird with the trailing underscore somehow?
Hmm, and now I can't seem to get this to replicate. It looks like once the names are cached, it all works. This is very strange.
Ah, it looks like when you first go to a search hit, the resulting URL is then populated to all the items in the search. Here's some source code that was served up to me (note all the links are going to the wrong place). Do you have any idea what's going on here @lentinj ?
Found it! It's not a caching issue, it's the fact that the current page URL is https://www.onezoom.org/life/@Clade3272. Navigate to that, you get an error, then start searching.
When populating the search results, there's an attempt to mangle the URL to make sure we have the right life:
https://github.com/OneZoom/OZtree/blob/118bfba9b122d812386e438fb6d6b29cb51aed7e/OZprivate/rawJS/OZTreeModule/src/ui/search.js#L12-L18
Have a URL without a = in, and that regex fails, resulting in all the search links going to the current URL.
However this mangling, as well as being broken, is probably pointless. As discussed in #870 recently, closeAndLeap() strips any /life/ before navigating:
https://github.com/OneZoom/OZtree/blob/889026e68377ae306e8f3ffc60e16223803420cc/views/treeviewer/layout.html#L226-L227
So ditching lines 12--15 seems reasonable. Maybe we should try harder to generate the right links so you can open search results in a new tab, but this isn't the way to go about it anyway.
Well found @lentinj. I'm happy to go with whatever you suggest. I wonder if there's any way to set up tests for this sort of thing, though?
You could use JSDOM to wrap enough of a dummy document to give searchPopulate a searchbox, then compare the searchbox.innerHTML once it's done. There's similar setup for the tour tests:
https://github.com/OneZoom/OZtree/blob/118bfba9b122d812386e438fb6d6b29cb51aed7e/OZprivate/rawJS/OZTreeModule/tests/util_tourwrapper.js#L28-L44
Longer-term I'd like to wrap up the search box as a web component, creating more of a defined API for adding them to the page (and to test), but we're not there yet.
Just jotting down another case of this: the top result for 'Tortoises'
Interesting related notes:
- the display string when searching is "Tortoises (Clade591_)"
- manually navigating to the Tortoise node doesn't find an OTT for it
- Searching for Testudinidae doesn't find anything
Would need to dig into the tree to see what's happening.
Another case of this: the top result for 'Big Cats'
Text in the search dropdown is 'Big Cats (Clade7728_)' Link on the tag is https://www.onezoom.org/life/@Clade7728?otthome=%40_ozid%3D1
Another case of this: the top result for 'Big Cats'
Text in the search dropdown is 'Big Cats (Clade7728_)' Link on the tag is https://www.onezoom.org/life/@Clade7728?otthome=%40_ozid%3D1
I think this happens when to (pseudo) taxon name has an underscore, when there is no OTT. In this case, the name is Clade7728_, and that throws something off. Probably some kind of escape issue, though I have not digged into it.
It's the lack of equals. See https://github.com/OneZoom/OZtree/issues/879#issuecomment-2348465417
By the time you're displaying search results it's become https://www.onezoom.org/life/@Panthera=563154, whereas https://www.onezoom.org/life/@Clade7728 is still https://www.onezoom.org/life/@Clade7728
Ok, but then let's look at another one that has a name but no OTT: https://www.onezoom.org/life/@Podiata. This one doesn't fail. In the end, it does end up on a different node: https://www.onezoom.org/life/@Eukaryota=304358.
What explains the different behavior between Podiata and Clade7728_? I think it is the underscore. In fact, if I rename Podiata to Podiata_ in my DB, it becomes broken like Clade7728_.
I use trailing underscores to indicate that the name is not a valid scientific name, but simply a OneZoom convenience. As such, names with a trailing underscore should not appear in searches.
As such, names with a trailing underscore should not appear in searches.
Yes, we could remove those from search. Although in the case of Clade7728_, it's associated with Vernacular name 'Big cats', which presumably was meant to be searched.
Side notes:
- That node includes clouded leopards, which are not usually viewed as 'Big Cats'
- We have another node named 'Roaring cats', which is paraphyletic in the updated tree, since Snow Leopards don't roar but are Panthera.
Ah, sorry, I mean the name itself shouldn't be displayed, but any vernaculars could be.
The URL re-writing problem is maybe worth fixing but is a separate problem imo, unless I'm misunderstanding. That was only going on because we got to an invalid pinpoint in the first place.
I've opened a little PR to avoid making bad pinpoints (e.g. "@Clade7728") for these fake-named nodes (e.g. "Clade7728_") which fixes the cases mentioned here like 'Foxes', 'Big Cats', and 'Tortoises'. See what you think: https://github.com/OneZoom/OZtree/pull/927