URL is resolved and redirects are taken

[Atemu]

When opening a link to a website that requires a cookie to access and otherwise redirects you to a login page (such as links to private GitLab repos), opening the link via OpenLinkWith results in landing on the login page, despite the browser session being authorised.

I've also noticed that OpenLinkWith regularly has a noticable delay before showing the list of available browsers; showing a spinner. Could it be that it's connecting to the website to be opened in another app in any way?
Manifesting my suspicion further is the fact that OpenLinkWith reproducibly has a consistent rather lengthy loading time (with spinner) when you are offline; suggesting it's waiting for a timeout.

As a user, I want OpenLinkWith to pass through the link unaltered without making any network connections so that I can open links that only work in my browser session.
As a user, I want to be given the choice of app as fast as possible without noticeable delay.
As a user, I want the URL to be touched only when URL cleaning is enabled.

Redirect resolution can be a desirable feature in some situations. Enabling it unconditionally results in bad UX as described here. It still is a useful feature however IMO. I believe that a button in the pop-up that cleans up and resolves the redirect would be a better approach.

[Pindagus]

I often receive links from systems that sets cookies on the linked page and then redirects to another page. A good example of this are payment request links from Rabobank. These links will break as described by @Atemu.

It looks like the app internally loads the page that is linked and forwards the resulting page (after cookies and redirects) to the desired browser, while I expect the original link to be forwarded to the chosen browser.

@tasomaniac what is the reason it works this way and is there a way to prevent these kind of links from breaking? In my opinion this app shouldn't even load the page it is going to forward to another app.

Currently I work around this by copying the link and pasting it in the browser, what essentially defeats the purpose of this app.

[tasomaniac]

Hey, this behavior comes from short url resolution. OLW originally was very focused on native app opening. If it find a native app to open the URL with, it should open it immediately without any wait. It waits when it cannot find it. What it does is to follow urls like bit.ly tinyurl.com to figure out what is the real website.

Of course your case about cookies can be messed up with this. If the url with a cookie had already a native app attached it would work fine. But if not, I will have to think about how to deal with this better. Any ideas?

[Atemu]

What it does is to follow urls like bit.ly tinyurl.com to figure out what is the real website.

It seems to follow any url IME. As mentioned in the original comment, my university's GitLab instance was resolved and you certainly wouldn't have that in any sort of URL-shortener list.

I will have to think about how to deal with this better. Any ideas?

What I'd personally love to see would be to have the URL displayed in a text field of sorts and a "resolve" button next to it. The displayed URL would be updated to reflect the real URL behind it upon pressing the button and waiting for a spinner.
Selecting any app from the list would open the currently displayed URL whether it's resolved or not.

This process is transparent to the user; it tells the user what is going on, what will happen and makes any (possibly expensive) network traffic a manual action of the user (resolve button or app selection after which the selected app would likely fetch the url).

Of course you could add an option to always resolve the URL to restore the current behaviour and perhaps an option to only auto-resolve known shorteners/redirectors which I think would be a useful feature.
Another possibility is to use the same pattern as the app selection: "resolve once" and "always resolve". That might require too much space though.

What do you think?

---

To clarify my use-case here, I use OLW to fully replace Android 12's built-in link opening chooser because Google completely fscked it up. I don't want anything opening automatically without prior consent and I certainly do not want to be limited to apps officially blessed by a corporate-run service.

At the minimum, I want a link opening chooser that behaves like Android 11's link opener did.
The url display I suggested would be a (in my opinion) useful addition to that.
I don't need or want any links to be auto-resolved in my app chooser but I'd welcome to option to selectively do so in certain situations. Again, it'd be a useful addition but not necessary.

[tasomaniac]

I think your suggestion makes sense.

[Atemu]

I've proposed #102 which fixes the issue by making it not follow redirects when link cleaning is disabled. It does not implement my proposed usability upgrades that would allow selective filtering.