Jumping to search results is broken when URL includes life.html instead of just life

[davidebbo]

To repro:

• Go https://www.onezoom.org/life.html
• In the search box, type okapi
• Click on the top result

Nothing happens, due to the following exception:

OZentry.6162883321d1a8e6a2f0.js:1 Uncaught TypeError: Failed to construct 'URL': Invalid URL
    at Bo (OZentry.6162883321d1a8e6a2f0.js:1:247653)
    at t.set_treestate (OZentry.6162883321d1a8e6a2f0.js:1:294506)
    at closeAndLeap (VM30 life.html:24:28)
    at HTMLDivElement.<anonymous> (VM30 life.html:498:19)
    at HTMLDivElement.dispatch (jquery.min.js:3:9922)
    at q.handle (jquery.min.js:3:7949)

This is caused by a bug in the "Strip /life/ from any URL" logic (

OZtree/views/treeviewer/layout.html

Line 227 in 2f51d56

onezoom.controller.set_treestate(href.replace(/^\/[A-Z_\-/]+/i, ''));

), which doesn't expect the .html extension, and leaves the URL starting with a bogus ".html/@etc...".

[davidebbo]

The fix is to simply include periods in the regex character class (square brackets).

[lentinj]

Maybe we should bin the regex replacement, and feed a "ignore URL base" option to set_treestate(), so we don't try and go from /life_expert -> /life (for example).

That said, I don't think set_treestate() would actually change pages if passed a full URL anyway, and maybe it would never make sense to do so?

[davidebbo]

so we don't try and go from /life_expert -> /life (for example)

That would not happen, since we have underscore in the character class, no?

I was just trying to target the specific 'period' issue tactically with a minimal change, but if you think that a different change is best, we can do that instead.

[lentinj]

That would not happen, since we have underscore in the character class, no?

Yup, I'm not arguing against your fix, which is a good catch and worth applying.

My point is more that the whole regex-replacement will probably bite us again in the future, and could probably be binned & replaced with a special case in set_treestate() more robustly. But it's certainly not a high-priority thing.