Link Element Broken? What *IS* this weird extra Link Destination Pop-up...?

[keith]

[EDIT: Solved. I was just “dooing it rong”. See solution. Leaving my post here though as a warning to others not to be such a smarty-pants and assume Bubble won’t usually just “do the right thing.” Derp.]

I’m seeing weird behavior in the Link element. I’ve never seen this before. Looks to me like I have this dialog configured entirely correctly, but the Issue Checker is throwing an error. When I click the error, this separate “Link Destination” pop-up appears…

But as you can see from the snip below, “Link destination” is filled out in the Link element dialog. This is super weird to me. Anybody see this?

The error in the issue checker says “remember to fill out Page to send this to”. Huh???

[keith]

OK… this is completely weird behavior to me. There was a lil’ typo in my previous screen cap, but here it is correct. I’m just dynamically constructing the destination URL (the thing I’m linking to is a file saved in Bubble’s s3, so I need to add the “https:” part as the File’s URL when a file is saved this way starts with the path part like “//s3.amazonaws.com/appforest_uf/f1536868826146x375287662260234400/result.pdf”.

But I get this stupid destination dialog. WTF?:

This has gotta be a bug, yeah? Because you can do this, of course: Put a input down and then I can dynamically fetch its text and put that as a dynamic link’s destination…

In run mode that would look like:

And the link element for that thing does not throw an error and the link works.

But the “my link” does not. (It tries to go to “https://https/”)

I swear I’ve done exactly this before… Why does this now not work? Totally weird…

[keith]

For anyone else who might be struggling with this, here’s a [stupid, but it works] workaround:

Get the AWS “URL” (which is just a path) and do a find & replace to add the https: part back in, shove that into a custom state:

Then Open External Website using that reconstructed URL:

But that is SO stupid.

[keith]

OH GEEZ… Nevermind. Turns out the following is true:

If you just print (convert to text) a file’s URL, Bubble leaves off the “https:” part.

HOWEVER, in cases where you would be using it as a link (like in a link element), that part is magically back.

So, this isn’t broken… I just always thought that the fields in Link Element (or in the Rich Text Editor, BTW) were plain text. They are not, apparently.

So the solution is just the following (which I guess most people would just naturally do!):

** I swear this is new-ish behavior. ** I seem to remember having struggled with the opposite problem before (that https: was missing when used this way). I think this might be a case of a bug having been fixed or something. Or maybe I’m just nuts.

Shout out to @neerja for steering me in the right direction!

[mishav]

Check the page source of the runtime, you’ll see you were right the first time, it starts with //, and because it is inside an anchor’s href, the browser expands it with https: to match your website.

[keith]

Thanks, @mishav – I see what you’re saying. Hmm.

It’s vexing to be sure. I do need to file a bug report about this inconsistency.

I get the impression that the behavior (that the s3 URLs are presented in this way) is intended for some reason, but to my mind it does seem wrong. I’m not sure if this would ever get fixed as wouldn’t returning s3 URLs as fully-qualified URLs now be a “breaking change”?