URL filling with nulls

[jrosindell]

[davidebbo]

@jrosindell I'm not seeing this behavior on Chrome, using the same tour at the same step. My URL looks like https://beta.onezoom.org/life/@biota=93302?otthome=%40_ozid%3D1&tour=%2Ftour%2Fdata.html%2Ffrogs%404#x783,y1066,w1.4031

Maybe there are other factors at play?

[lentinj]

@jrosindell @hyanwong did you figure out what needs to be done to replicate this? When does an extra "null/" get added? Could you copy-paste what the full URL looks like?

I'd guess it's something to do with 56cbc37, but I've not many ideas how off the top of my head.

[lentinj]

I could also believe it only happens if you start the tour in a particular way. Going to a URL like https://beta.onezoom.org/life/?tour=%2Ftour%2Fdata.html%2Ffrogs%401 would start the tour on page-load, and since the original URL doesn't have a pinpoint in, it'd be null.

It's a very neat explanation, but unfortunately the URL above seems to work fine.

[davidebbo]

Right, I had tried a number of things, but could not reproduce this issue.

Not sure to what extent it's related, but I did notice that if you add random tokens to the URL path, they get preserved and the site otherwise works fine. e.g. https://beta.onezoom.org/life/random/other/tokens

[lentinj]

Yeah, that's how we're repeating the null/s. Everything before the final pathname part with the @ is treated as the base URL and preserved. Generally this is fine since we only modify the pinpoint at the end of the pathname.

A bodge would be to not record a URL if the pinpoint we're trying to record is null, but this would potentially break the share buttons.

[lentinj]

I still can't reproduce this (@hyanwong says that rapid fire "Next"ing can do it, but not here). However, the pull request should at least solve the repeated "null/"s.

I'm still not sure why there would be a state without a pinpoint mind, but the problem is somewhere around here:

OZtree/OZprivate/rawJS/OZTreeModule/src/navigation/record.js

Lines 34 to 48 in 2ee6900

	// No OTT found to anchor the URL on, don't record
	if (!current_state.pinpoint) return
	// Not allowed to record when being served via file:
	if (window.location.protocol === "file:") return;
	// Don't bother recording if it's basically the same state
	if (!force && current_view_near_previous_view(current_state)) return;
	if (current_state.tour_setting) {
	// Leave everything alone bar tour---parse existing state, splice tour state in.
	const tour = current_state.tour_setting;
	current_state = parse_state(window.location);
	current_state.tour_setting = tour;
	}

Note that (line 34) refuses to record a URL without a pinpoint, but when in a tour we ignore this state and craft our own based on the current page location. If this URL doesn't have a pinpoint, it'd get passed through regardless.

I don't think the solution is moving this check. We still want to record the current tourstop in the URL, so we can then refresh / share the current URL.