Improve url pattern UI/UX

[gbdomubpkm]

Hello.
First happy new year.

Take for example this link https://gitlab.com/ubports/community-ports/pinephone/-/issues?state=opened

It is easy to connect to gitlab using gitlab password and the webapp can stay open until we log out.

But what I have a problem with, is connecting to Gitlab using the Github password.
Without using patterns, as usual when using only morph-browser, I am sent to a web page where I enter a Github verification code, but here after entering this code, the connection to gitlab fails.

Is it possible to include patterns in the gitlab webapp so as to connect using github password ? Or it is something else that you can solve ?

You can test it for yourself, and providing a solution would be useful for everyone.

Thank you in advance

[timsueberkrueb]

Hey, indeed, without any modifications to the url patterns, it opens GitHub in Morph Browser and does not redirect back to the web app, which is why the authentication fails.
It should be possible to make Morph actually redirect back to the webapp by including url dispatcher information in the generated click packages.

In the meantime, it works when adding the following url patterns (more fine-grained patterns are certainly possible):

• https://github.com/*
• https://*.github.com/*

After adding these patterns, it redirects to GitHub inside the webapp and the authentication process succeeds.

[gbdomubpkm]

You are right, it works (provided that we add the patterns and do not delete those written by default.. 😉).

Moreover, it should perhaps be specified in webber (and by putting the included patterns in color?), that their deletion may cause a malfunction.

However, some sites refer at a certain time (for example just after the connection or the closing) automatically to pages which are not included in the webapp and which we do not know. Would it be possible to include a general model in webber taking this data into account so that we always stay in the webapp?

[timsueberkrueb]

Those are great suggestions, I think we could:

• Add an option to always open all links inside of the webapp
• Add an option to generate url dispatcher information (i.e. if one opens a link outside of the webapp that matches the webapp's url patterns, it gets opened inside of the webapp rather than in the system browser)
• Warn about removing the default patterns
• Consider which default causes least friction

Some possible defaults (first row is the current behavior):

Links to the site in the app	Links to the site in other apps	Links to other sites in the app
Open in the app	Open in system browser	Open in system browser
Open in the app	Open in the app	Open in system browser
Open in the app	Open in the app	Open in the app

No default will cover all use cases, unfortunately, so we will need to find out which compromise causes least friction. The second row has some advantages (e.g. it would've prevented the issues you reported here), though I'm a bit afraid it might cause confusion for users when they accidentally create url patterns that overlap between apps. Also you may sometimes want to open links to a certain site in the browser rather than in the webapp.

[gbdomubpkm]

Yes, there is not perfect solution. I stay on my idea but i hope you will find a good compromise because the construction of a webapp must remain quite readable.

Currently, i have another 'problem' : I tried everything but IMPOSSIBLE to built a usable webapp with the internet provider bouygues (client area) whearas no problem with my bank.

The problem is at start when authentication after putting mail + password. After Enter I get a webpage with a message something like this (i changed data becaue of security i don't know ):

{"error":"invalid_request","error_description":"Unexpected callback received (invalid id parameter value 'ur-70ca94e8b917-405d-6ahk-ea49ddb6345664client_id=a340.bouyguestelecom.fr'). Request is not part of an ongoing token i ...","error_id":"et-47934791-08ca-4cklmt17-168218ebe33","error_status":400}.

I tried to put a pattern with the webpage which give this message but it changed nothing: only the message 'error' was now inside the webapp ! 😉

Is there some specific patterms to put ???
Nothing want to work always this message as answer.
Thanks

[timsueberkrueb]

Does it work in Morph browser? Does it open any urls in Morph rather than in the webapp? If so, those would be candidates for patterns. Also maybe try to be more generic with your patterns, e.g. https://*.example.com/* instead of https://subdomain.example.com/* if you're not already doing so.

[gbdomubpkm]

No problem with morph.
Frankly, I don't know !
If it works in morph, there must be compulsory a solution that works in the webapp?
I have not yet found the right patterns (if it possible) that can solve the problem.

Hi @balcy
Do you have an idea what the problem could be ?
Thanks