Using a URL as the primary field

Welcome to the community, @jaz!

Wow, that looks like a major bug! I would report that to support@airtable.com ASAP and hopefully they can fix it soon.

Note that they are notoriously bad about fixing bugs in any sort of a reasonable timeframe, so who knows if/when we will see this fixed.

I wasn’t sure if it was intended behavior or not, but it sure feels clunky. :confused:

I wasn’t sure if it was intended behavior or not, but it sure feels clunky. :confused:

One must assume some odd things may happen when implementing any content solution that leans on a URL for any purpose whatsoever. Why? Because Airtable runs in a browser and browsers are notoriously biased toward the presence of easily recognizable URIs.

The Airtable UI has become so good that we often feel like we’re not in a browser. The reality is that anything you cause to be displayed (as data) that also looks like a URL to the browser, could have some underlying and unexpected results.

Even if this is ultimately deemed a bug, I wouldn’t be surprised if Airtable blames this errant behavior on your browser. As such, you might try your solution with different browsers to see if they all interpret this intended data as something else.

Also, perhaps there’s a better primary key you could construct by parsing the components of the URL and reassembling them in a way that allows you to dynamically reconstruct theURL as needed and also make it less apparent to the browser that it is in fact a URL.

The same bug happens in the Airtable app, so it’s not a browser issue. I have reported it to Airtable.

You do realize the Airtable app is likely a PWA, a hybrid desktop app built largely from browser components. I could be wrong about this, but it’s not an uncommon practice to sustain cross-platform compatibility.

One must assume some odd things may happen when implementing any content solution that leans on a URL for any purpose whatsoever. Why? Because Airtable runs in a browser and browsers are notoriously biased toward the presence of easily recognizable URIs.

The Airtable UI has become so good that we often feel like we’re not in a browser. The reality is that anything you cause to be displayed (as data) that also looks like a URL to the browser, could have some underlying and unexpected results.

Even if this is ultimately deemed a bug, I wouldn’t be surprised if Airtable blames this errant behavior on your browser. As such, you might try your solution with different browsers to see if they all interpret this intended data as something else.

Also, perhaps there’s a better primary key you could construct by parsing the components of the URL and reassembling them in a way that allows you to dynamically reconstruct theURL as needed and also make it less apparent to the browser that it is in fact a URL.

Also, perhaps there’s a better primary key you could construct by parsing the components of the URL and reassembling them in a way that allows you to dynamically reconstruct theURL as needed and also make it less apparent to the browser that it is in fact a URL.

For several reasons, this isn’t an option. :confused: Mostly due to constraints put on me by the end users.

Thanks for the insight on the browser. Both links turn blue when they are first clicked - as though the browser was recognizing it as a link. The behavior changes when I click on it a second time. That feels to me more like something under Airtable’s control…?

Whatever the cause it is replicated in different browsers.

Then your only hope is to convince Airtable to change.

I heard back from support.

Amazingly & shockingly, Airtable consciously made the decision for the URL field to act differently if it is the primary field. :man_facepalming: :man_shrugging: :confounded:

Add this to the long list of completely illogical & nonsensical decisions that Airtable has made over the years.

Well that sucks. :confused: Did they give you a reason at all? Thanks for updating the thread! :slightly_smiling_face: