-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open in browser can't use any app other than the current default browser #9403
Comments
Duplicate of #9362 Also a workaround is shared in the same thread |
This is not a duplicate to the mentioned issue. On LineageOS 18.1, clicking a youtube link in the video description creates a different result than clicking "Open in browser". Even if the root cause might be related, this is a different problem with a different outcome. Also, i cannot reproduce the mentioned issue on LineageOS 18.1. Workaround 1 (don't set any default handler for affected URLs) does not work (as covered by my reproduction steps). Workaround 2 is just cumbersome. One difference i could quickly find was that the TextLinkifier passes |
The two issues are not even on the same topic, let alone being duplicates. |
If i get things right, the current implementation is trying to make sure that "Open in browser" doesn't just loop back to NewPipe if it is set as the default handler for the URL. Alternatively, you could say that - in accordance with the documentation of I guess this does open room for discussion on whether this issue is properly filed as a bug or a feature request? |
That sounds ideal, if it can be done. |
If NewPipe is the default handler for the URL at hand, defaultPackageName should be equal to This code placed in defaultPackageName = getDefaultAppPackageName(context, intent);
if (preferDefaultBrowserOverSelf && context.getPackageName().equals(defaultPackageName)) {
defaultPackageName = getDefaultAppPackageName(context, new Intent(Intent.ACTION_VIEW,
Uri.parse("http://")).setFlags(Intent.FLAG_ACTIVITY_NEW_TASK));
} Did a quick test run with this change on a LineageOS 18.1 device and that worked. I'm not sure about opening a PR because i believe there's a lot more to consider with the accompanying code changes that would come with it, possibly requiring some little change in places that use this method? I'm not familiar with the project so i wouldn't dare to make these decisions and i probably wouldn't be around to maintain this code, let alone being able to properly test this on a wider range of devices and ROMs. Also, i'm courious why |
I believe the share button instead of open in browser also solves the problem. Have you tried that? |
Regarding leaving things as they are:
This indicates that the current behavior is working as intended. In this case i improperly filed this as a bug while it is just me disagreeing with how the feature works. Sorry. To summarize, this issue boils down to the following conflict: A lot of apps these days allow the When prioritising use-case A) - as is currently done - there is no way to use "Open in browser" with other apps except by going through additional apps as a workaround or by copy-pasting URLs if the target app supports it. Possible implementation: This should do the right things by default. This allows for a "one-click use" when setting NewPipe as the default URL handler. Clicking links inside NewPipe would open them in NewPipe and clicking "Open in browser" would open them in the default browser without showing any activity pickers. Any non-standard setup might be cumbersome to achieve but it would be possible without any additional applications or copy-pasting links. As a compromise, this implementation could be exposed as a new button labeled "Open in app" unless that sounds like an unnecessary additional thing to maintain considering the use-case it covers. In this case, I'll leave it to NewPipe devs to decide which use-case weighs more i.e. whether you believe that use case A) is relevant enough to warrant the workarounds required for use-case B). You know your user base better than i do. |
Sadly, not every app that can open URLs exposes that functionality in the share menu. Sometimes with good reason sometimes less so, at least from a users perspective. I gave the official YouTube app and ViMusic as an example for this. But yes, that would be the ideal overall solution to the underlying issue. |
I just came across this now. Thank you @SebiderSushi for the thorough explanation. Even though setting NewPipe as default in case B would result in case A (i.e. the current behavior), I think it would be pretty counterintuitive for users that do not know that they can do such a thing. Maybe we could allow the "Open in browser" buttons in the various places of the app to be long-pressed to open in app, instead of opening in browser. If you want to open a small PR feel free to do so, otherwise just ask me to do it. Thanks! |
Ah i see what you mean, i did not consider users who are choosing the default URL handler immediately after clicking "Open in Browser" in NewPipe - choosing NewPipe here to open the URL in the browser would indeed be counterintuitive. Instead, i had only considered users who already opened a youtube URL elsewhere and set NewPipe as the default URL handler while doing so. In this case, the "Open in Browser" button would work as expected without any additional interaction or counterintuitive reasoning. Your proposal to implement "Open in app" as a long-press action sounds sensible but i have no idea how to communicate this feature to new users. The existing "Hold to append tip" feature wouldn't really work for this since a user would have to notice it during the split second it takes the device to switch to the browser. Maybe a Toast could work? A "don't show this again" style dialog would probably be too disruptive and i'd expect most people to dismiss it without even registering it. Unless you want to go with "users who care about this will find out one way or another...", which i guess "works for me" but isn't really a good solution either? :/ As to who should submit a pull request for this i believe i'll stick to what i've mentioned previously; i don't feel confident in being able to consider all details that might be impacted by this change and especially since there appears to be no elegant solution to this problem i don't feel confident in coming up with a good UX that is consistent with the rest of the app. |
We should indeed follow standard intent behaviors, by using Letting the Android system choosing the app to use for actions like I made changes in this way in #9833, what do you think about the new behavior? |
An update: we decided not to merge #9833, because it had problems (for example, when NewPipe was set as default, it would open NewPipe itself). But we actually found a solution which would probably suit both users who just want to open in browser, and users who may want to open in any other app. The solution is: showing a chooser each time the "Open in (browser)" button is clicked, with all of the apps that are able to handle the url (including browsers and e.g. the official YT app). The only downside would be not being possible to select a default app. This is because apps like the browser do not respond to the |
Checklist
Affected version
0.24.1
Steps to reproduce the bug
For example the official YouTube app or ViMusic
Expected behavior
After clicking "Open in browser" the default android activity picker shows up (see screenshots) with all apps set up to handle the URL or android launches the default activity if previously selected.
If only one app is set to "Open youtu.be and other URLs" or "Ask every time" it should open the URL.
Actual behavior
NewPipe currently enforces the default package or refuses to operate if there is none set.
If only one app is set to "Open youtu.be and other URLs" or "Ask every time" the URL is still opened in the default browser.
Under the same circumstances, trying to open a URL with BinaryEye for example produces the expected behavior.
Screenshots/Screen recordings
Screenshots: Activity pickers on LineageOS 15.1 (left: NewPipe, middle: BinaryEye) and 18.1 (right)
Logs
No response
Affected Android/Custom ROM version
Android 11 / LineageOS 18.1
Affected device model
OnePlus X
Additional information
From a quick glance this PR contains some reasoning for this behavior
and how it might have been necessary on older android versions to get the desired behavior? However, on more recent android versions the Activity picker for opening URLs allows setting a default on-the-fly (see attached screenshot) and does the right thing after doing so (at least the way BinaryEye does it).I have no information about wich android versions actually required NewPipe's current implementation but at least on newer android versions it appears to be obsolete and on even newer ones it makes it downright impossible to use "Open in browser" with anything other than the default browser.
Even going back to a device with android 8.1.0 things still work; If there is no definitive default activity set for the URL android will bring up an activity picker - albeit without the option to set a default on-the-fly (see screenshots).Whatever BinaryEye does causes android to bring up an activity selector equivalent to android 11 (see screenshots).
In any case it is possible to manually choose a default activity by going into the default app settings and making sure that every app that is set up to handle affected URLs is set to "Don't open supported links" except the one that should be the default.Under these circumstances, clicking "Open in browser" in NewPipe works as expected.
Edit: There is no different behavior on android 8.1.0. I came to this conclusion due to a mistake on my part because i did the android 8.1.0 test on my daily driver and wasn't as thorough as to disable literally every app under "Opening links" in the System Settings like i did when testing on LineageOS 18.1. I forgot to disable UntrackMe and whatever it does to hook into ACTION_VIEW intents created this behavior.
The text was updated successfully, but these errors were encountered: