Skip to content
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

Open
6 tasks done
SebiderSushi opened this issue Nov 15, 2022 · 13 comments
Open
6 tasks done
Labels
bug Issue is related to a bug

Comments

@SebiderSushi
Copy link

SebiderSushi commented Nov 15, 2022

Checklist

  • I am able to reproduce the bug with the latest version.
  • I made sure that there are no existing issues - open or closed - which I could contribute my information to.
  • I have read the FAQ and my problem isn't listed.
  • I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
  • This issue contains only one bug.
  • I have read and understood the contribution guidelines.

Affected version

0.24.1

Steps to reproduce the bug

  1. Install NewPipe
  2. Install another app that can open youtube links
    For example the official YouTube app or ViMusic
  3. Navigate to an arbitrary youtube video in NewPipe and tap "Open in browser"
  4. Go to System Settings > Apps and notifications > Default apps > Opening links
  5. Set all apps to "Don't open supported links"
  6. Set only the official YouTube app OR ViMusic to "Open youtu.be and other URLs" or "Ask every time"
  7. Navigate to an arbitrary youtube video in NewPipe and tap "Open in browser"
  8. Disable the preinstalled "Browser" app
  9. Navigate to an arbitrary youtube video in NewPipe and tap "Open in browser"

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.

@SebiderSushi SebiderSushi added bug Issue is related to a bug needs triage Issue is not yet ready for PR authors to take up labels Nov 15, 2022
@killerrook
Copy link

Duplicate of #9362

Also a workaround is shared in the same thread

@SameenAhnaf SameenAhnaf added template ignored The user didn't follow the template/instructions (or removed them) duplicate Issue or discussion is a duplicate of an existing issue or discussion and removed bug Issue is related to a bug needs triage Issue is not yet ready for PR authors to take up labels Nov 16, 2022
@SebiderSushi
Copy link
Author

SebiderSushi commented Nov 16, 2022

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.
Mind you, that whatever intent BinaryEye is launching when you open a link causes android to do the right thing under the exact same circumstances (again, see screenshots). This approach could consequently solve both this issue and #9362

One difference i could quickly find was that the TextLinkifier passes false for httpDefaultBrowserTest while "Open in Browser" doesn't pass the parameter which defaults to true.

@opusforlife2
Copy link
Collaborator

Duplicate of #9362

The two issues are not even on the same topic, let alone being duplicates.

@opusforlife2 opusforlife2 reopened this Nov 16, 2022
@opusforlife2 opusforlife2 added bug Issue is related to a bug and removed template ignored The user didn't follow the template/instructions (or removed them) duplicate Issue or discussion is a duplicate of an existing issue or discussion labels Nov 16, 2022
@SebiderSushi
Copy link
Author

SebiderSushi commented Nov 17, 2022

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.
Would it make sense if NewPipe would just generally let android handle the selection and only enforce the default browser if NewPipe itself is set as the default handler?
The httpDefaultBrowserTest flag could be replaced with something called preferDefaultBrowserOverSelf. When called from "Open in browser" this could be set to true while links in comments and descriptions could choose false for this.

Alternatively, you could say that - in accordance with the documentation of openUrlInBrowser() - "Open in browser" intentionally does not support alternative URL handlers and not change anything. However, the current behavior creates issues with use-cases like trying to open a URL in any app where Intent.ACTION_VIEW is the only ingress point for that sort of thing (besides copying and pasting the URL if applicable). Examples are the official YouTube app or ViMusic. If pasting a URL into the target application is not possible, workarounds are a browser that offers an "Open with" or "Open in app" action for URLs (for example Fennec but not Chromium or Bromite) or by sharing the url to a link management app (LinkHub for example) and re-opening it from there. Techinally, UntrackMe can also be used on some android versions to get around the issue but that is neither an intentional nor an obvious feature.

I guess this does open room for discussion on whether this issue is properly filed as a bug or a feature request?

@opusforlife2
Copy link
Collaborator

Would it make sense if NewPipe would just generally let android handle the selection and only enforce the default browser if NewPipe itself is set as the default handler?

That sounds ideal, if it can be done.

@SebiderSushi
Copy link
Author

SebiderSushi commented Nov 17, 2022

If NewPipe is the default handler for the URL at hand, defaultPackageName should be equal to context.getPackageName(). This already works in the context of e.g. the TextLinkifier i.e. when clicking links in descriptions.

This code placed in openUrlInBrowser() should do the trick if the default browser is preffered over NewPipe but other URL handlers should not be overridden:

        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 openAppChooser() is used instead of just sending the intent without forcing a package name and letting android handle the rest of it. If a default is set then NewPipe doesn't bring up the picker anyway, if no default is set android should already do the right thing. Am i missing something? Is the app chooser preferred over the default android picker because of functionality? I believe that the aosp activity picker does have its issues and annoyances and i do see benefits to the app chooser that comes up now (depending on the use-case). However, it is still a non-standard way of doing things and thus an odd-one-out from the users perspective and not what they will interact with most of the time. Was this method required on older android versions? I pulled out an older phone out of my drawer and at least on android 5.1.1 the activity picker is functionally equivalent to what i get on LineageOS 15.1 and 18.1 which indicates that this covers all versions currently supported by NewPipe. I can't see any reason this behavior should substantially differ between android versions, even much older ones and i'm currently not aware of any exception to this. Also, the code comments themselves note that the app chooser "does't work on some devices" so why go with this non-standard way of doing things to begin with?

@killerrook
Copy link

I believe the share button instead of open in browser also solves the problem. Have you tried that?

@SebiderSushi
Copy link
Author

SebiderSushi commented Nov 18, 2022

Regarding leaving things as they are:
PR #3501 which introduced this behavior cites the following issue:

Open in browser button not opening in browser, but either showing a chooser, or worse: opening in NewPipe if NewPipe is set as default for youtube links. I just wanna open in browser

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:
Use-case A) "I want 'Open in browser' to open the URL in the browser. If i click on the URL elsewhere i want to open it in a different app which isn't NewPipe. I don't want to go through the activity picker each time to achieve this."
Use-case B) "I want to use 'Open in browser' to open a URL in any app that isn't my default browser. I'm okay with going through the activity picker each time to achieve this."

A lot of apps these days allow the Intent.ACTION_SEND as an additional ingress point for things that would technically only qualify for Intent.ACTION_VIEW. For example it is possible to share a link to NewPipe, Bromite or Fennec and open it with these apps. The best solution to this conflict would be that all apps would do this. Users could set "Open with" to their preferred default and use sharing for all one-offs. Use-case B) is most relevant when using apps that do not provide this quality-of-life feature for whatever reason. Examples i already gave are the official YouTube app or ViMusic, both of which do support pasting URLs however.

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.
When prioritising use-case B), users have to go through the activity picker each time they click "Open in browser" unless they set NewPipe to open that URL by default. When a different app is set to handle the URL by default, "Open in browser" will open it in that app instead of the browser. That app might not give an option to open the URL in the browser. However, choosing a different app as the default handler is a deliberate act, it just might be confusing after clicking "Open in browser" if the user isn't aware they set a different default or don't know how to change it. To open the URL in the browser, every sane browser allows pasting a URL as a reliable workaround. There are apps to share text to the clipboard and android 10 or 11 and newer support this natively. The browsers Bromite and Fennec also allow sharing a URL to them directly, Chromium and thus presumably also Chrome do not.

Possible implementation:
Don't use the openAppChooser(). Just start the ACTION_VIEW intent for the URL without forcing any package name by default. When clicking "Open in browser" and NewPipe is set as the default handler for the URL enforce the default browser.

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, openAppChooser() would be required as the button should still work even if NewPipe itself or any other default is already set.

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.

@SebiderSushi
Copy link
Author

SebiderSushi commented Nov 18, 2022

I believe the share button instead of open in browser also solves the problem. Have you tried that?

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.
In any case, copy-pasting also works and so far i didn't encounter an app that does not support it but it's less of a guarantee than being able to copy paste into a browser.

@Stypox
Copy link
Member

Stypox commented Feb 8, 2023

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!

@SebiderSushi
Copy link
Author

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.

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.

@AudricV
Copy link
Member

AudricV commented Feb 18, 2023

We should indeed follow standard intent behaviors, by using ACTION_VIEW and ACTION_CHOOSER intents where applicable.

Letting the Android system choosing the app to use for actions like Report on GitHub in the error activity or Open website in third-party licenses dialogs makes sense, but not really in the Open in browser app commands, especially if the current instance of NewPipe is set as default: a system chooser with the list of apps should be shown here (even if it will be only one app on Android 12 and higher, due to how web links are now handled).

I made changes in this way in #9833, what do you think about the new behavior?

@Stypox
Copy link
Member

Stypox commented Feb 26, 2023

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 MATCH_DEFAULT_ONLY filter (which means that the app is not defaultable), but only to the MATCH_ALL one, and there is no way to start an Android chooser with MATCH_ALL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is related to a bug
Projects
None yet
Development

No branches or pull requests

6 participants