Why not use reset_fields() as I did before? If we click a new spot we need to reset all fields anyway?

I have to agree with @phl0 here. Do not clear field by field. Use the reset_fields() function to clear everything when hitting a new spot. We don't want to carry wrong data to the next QSO. No exception here. Better safe then sorry

We are clearing the form, see:

                if (shouldPrefill) {
                    DX_WATERFALL_UTILS.qsoForm.clearForm();
                }

But the problem is deeper, we are loosing POTA grid and - as it was noticed - if there was already referenced POTA/SOTA it's stays.
Let me some time to debug it and propose final fix.

I'm not sure if I get this right. Are you talking about a manually typed in SOTA/POTA Ref. or a Ref which was part of the Spot?

Reference received with the DX Cluster API, so part of the spot (but behavior shall be the same if user would have added it manually).

Expected behavior is: if there is a POTA/SOTA/... reference we would like to use it's grid-square/location, if not - get the grid square from internal callsign lookup (then the logic database vs call book kicks in). Now the logic is broken.

Talking about different things, i think.

e.g.:

• i click DF2ET who operates from a POTA Park. Reference is filled by the spot-data.
• DF2ET doesn't want to talk with me / huge pileup / QSBaker / whatever - no chance for a QSO.
• But there's LA8AJA a few kHz above with a spot. so i click him.

And now the problem: POTA/SOTA/WWFF-References are still those from DF2ET and NOT those from LA8AJA.

@phl0 's PR healed that. What is this thing doing on Top / better?

Yes, I fully understand you gentlemen, what I'm saying is that clearing the ref is only part of the problem.

2nd, bigger part is the race condition: look exactly what happens when you click on POTA referenced spot:

• ref gets into the field ✔️
• the ajax call to get pota grid and location triggers and populate fields (with ex. POTA reference location) ✔️
• just after callsign lookup comes overwriting the POTA location with the callsign QTH information pulled from DB/QRZ. ✖️

So, fixing that is not about clearing the form, but also ensuring we are not loosing POTA location in the process.

Please test, shall be fine now; expected behavior:

• form is completely cleared when navigation to new spot happens
• if our spot information contains SOTA/POTA/IOTA/WWFF reference - this reference is filled in after lookup is completed
• the reference location fetch is triggered
• result: callsign information with reference and with the locaiton/grid from the reference
• afterwards jumping to other spot, shall clear the form completely again

Either we're talking about different points, or i still don't get it.
let's take my example:

1. i click DF2ET who operates from a POTA Park. Reference is filled by the spot-data.
2. DF2ET doesn't want to talk with me / huge pileup / QSBaker / whatever - no chance for a QSO.
3. But there's LA8AJA a few kHz above with a spot. so i click him.

once i click at "1" - everything gets filled (references, DXCC, etc. etc.)
when i click at "3" - it's a complete different QTH etc.

it's not only the Refs, it's much more: County when working U.S.-Stations, Zones and so on.

you're talking about race-conds. wasn't able to repro here. but honestly - i know we've some.
very important to clear EVERYTHING before filling in data from/for a new QSO.

The EVERYTHING depends (and that's the reason for having RESET and CLEAR) on what to kill.
e.g. RESET preserves SAT-Mode/SAT-Name and a few other things, while CLEAR resets everything. but that's another story.

so - if i am not total wrong a QSY to another spot should do:

• Reset form (remove EVERY ref incl. QTH, DXCC, POTA/WWFF, etc. pp)
• Fill in things for the Spot.

if there's really a race-cond, we should refactor/adjust it, that it is fired in correct order.
only removing the refs doesn't help here.

Fully agree Sir, please check my comment which won the race to be published by a few sec. 😄 🍺

If anybody still wonders see line 1199 od dxwaterfall.js there is nothing else, but triggering the QSO Form reset button. This shall make us bulletproof for having old QSO data left in the form.

I believe lines 1170-1195 are redundant with qso.js 1001-1020, but I would recommend to leave it for a while.

In regards the race - this shall now be resolved with $(document).trigger('callsignLookupComplete'); firing after lookup, the overall form filling will take longer as now two AJAX calls are triggered in series, but at least we know what/when will happen. 😄

still trying to get my head around this. no progress - perhaps because its friday ;)

why reinvent the wheel with a lot of JS? DF2ET simply called reset_field which is doing the job.
The difference i can spot is: you're checking each selectize and field if it's populated and reset them one by once. While the already existing function simply resets everything.

even if you did it for a reason (possible race-conds, whatever), it'd be redundant code to the working/existing reset-function.

perhaps i really don't got it, but if there's a racecond we should try to serialize things instead of this one.

let me try to explain:
we need to maintain WL as Core-Team, if there are bugreports. we all appreciate your speed/PRs, etc. never seen a new contributer who works such accurate, clean and so on like you. but for WL it's very important to keep the codebase simple / maintainable.

It’s Friday! 😄

I think you might be overlooking one great functionality that, according to GitHub blame, was added/modified by @phl0 and @HB9HIL around 2 or 1 year ago — see:
https://github.com/wavelog/wavelog/blame/56882e21d4b682a65f952f9448112de92a2d8e47/application/views/interface_assets/footer.php#L1310-L1329

Once you set the POTA reference in the field, an AJAX call is triggered to fetch the QTH and locator fields.
When the POTA reference is known, we should use the POTA gridsquare instead of the callsign gridsquare from the Callbook — this is an awesome functionality. ❤️

Originally, @phl0 implemented this fix nicely. However, when switching to a POTA spot, the form was cleared, and with it, the information about being at a POTA spot was lost. Sure, the user could read the message and re-enter the POTA reference, but we already have that information!

So, my tweaks were focused on preserving the POTA reference from the spot and restoring it into the cleared form once the callsign lookup is completed.

For example:
If I’m spotted on DXCluster under my club’s callsign with a POTA reference, the correct behavior during the QSO form lookup should be to retrieve the POTA reference’s QTH.
If no POTA reference is present, then the city name from my club’s QRZ profile should be used instead.

And this will make the answer longer, but here comes the race 🤣:

The initial implementation had a bug — here’s what happened:
When the user clicked on a POTA spot, the POTA reference was added to the form, and an AJAX request was launched to fetch the POTA QTH. Then the form was cleared (preserving only the POTA reference, not the QTH/locator), and finally, the actual callsign lookup overwrote the POTA QTH/locator with data from the Callbook. Everything got completely mixed up!

Now the sequence is clean and predictable:

• User clicks on the spot.
• Frequency is set and tuning happens.
• Callsign is looked up.
• Once that data is filled in, the POTA reference is programmatically entered, and its QTH/locator is fetched.

Step by step — no more race conditions.