Skip to content

fix: reset package name in intent on open link error - #1320

Open
NatsuCamellia wants to merge 2 commits into
ReadYouApp:mainfrom
NatsuCamellia:missing-browser
Open

NatsuCamellia wants to merge 2 commits into
ReadYouApp:mainfrom
NatsuCamellia:missing-browser

Conversation

@NatsuCamellia

Copy link
Copy Markdown
Contributor

Problem

If a user selects a specific browser for opening links and later uninstalls it, the app crashes every time they open a link. This is because the catch block reuses the same Intent, which still carries the uninstalled browser's package name.

Reproduction

  1. Set a specific browser for opening links.
  2. Uninstall that browser.
  3. Open any article linkr in the app.

Fix

Reset the package on the ACTION_VIEW intent before retrying to fallback to other browsers.

Note

The stale browser preference is not cleared, so every subsequent link still shows the "something went wrong" toast. Maybe we can also reset the preference.

Related

@ibrahim-iqbal ibrahim-iqbal left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good, focused fix. Clearing the package binding with intent.setPackage(null) on the retry drops the reference to the uninstalled browser and hands the choice back to the system, which is exactly what the fallback wants to do.

One tiny follow-up (non-blocking, edge case): the retry startActivity inside the outer catch isn't wrapped in another try/catch, so on a device with no browser installed at all it would throw ActivityNotFoundException and crash. That's the same behaviour that existed before this PR — the fix here still shrinks the crash surface for the common "uninstalled preferred browser" case, which is the reported bug — but if you want to fully harden it you could catch the retry too, or use resolveActivity before calling startActivity. Happy to leave that for a follow-up.

Both call sites (AppUriHandler and Context.openURL) get the same one-line fix, which keeps the two paths in sync.

@NatsuCamellia

Copy link
Copy Markdown
Contributor Author

Thanks for the review. I can fix the issue as well, but it needs some time as I'm pretty busy recently.

conradlyn added a commit to conradlyn/ReadYou that referenced this pull request Sep 24, 2026
Cherry-picked from upstream open PRs. All of them touch files this fork has
never modified, so they apply cleanly and will keep merging cleanly if upstream
lands them later.

  ReadYouApp#1322 browser-like User-Agent to bypass WAF bot blocking; BestIconFinder is
        now failure-tolerant, tries https for bare domains, and caps icon
        candidates at 4; searchFeed reports HTTP status in its errors
  ReadYouApp#1323 proper charset detection when parsing full content
        (HTTP header -> BOM -> <meta> -> UTF-8), replacing the old peek+Jsoup
  ReadYouApp#1324 truncate over-long image filenames to avoid ENAMETOOLONG
  ReadYouApp#1320 reset the intent package when opening a link fails
  ReadYouApp#1317 keep the trailing slash when saving a greader/FreshRSS server URL

Deviation on purpose: ReadYouApp#1322 also shipped two tests that perform real network
requests to phoronix.com. Those are dropped -- a unit test that depends on a
third party's availability and anti-bot policy would make CI flaky. The other
tests from both PRs (4 charset cases, 3 UA cases, 1 local RSS parse) are kept.
@NatsuCamellia

Copy link
Copy Markdown
Contributor Author

It's been a long time since my last reply, and I'm finally back.

The app now checks the availability of apps that can open a link before trying opening a link directly. If no app is found, a toast will pop up to notify the user as the screenshot shows.

Screenshot_20261016_212045

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants