On XiaoMi phones at least, this is a system app (see: bloatware). That means you can't clear its app data nor uninstall it, effectively bricking Chrome permanently.
The only thing you can do is uninstall the updates, which force resets its persistence, losing all of your stored data/sessions.
If you've already done that... tough luck, I guess?
That's wrong. You can clear both cache and data of a system app on a typical Android device. You just can't uninstall it.
The base .apk is stored on a read-only system partition, so you can't completely get rid of it, but typically you should be able to remove all data of that app, clear its cache, uninstall any updates it downloaded (since those are stored on another partition), and also disable it.
I haven't used any OS by Xiaomi in a while, so I don't know if they changed anything about that.
Though I used to run their MIUI OS on my Samsung Galaxy (S2 or S5, I don't remember) for a while. That one was the opposite of locked down and even shipped pre-rooted, but it's been a long time.
Nope. Chrome's storage lists "0b" for its storage, which causes XiaoMi's OS to grey out the memory panel for the app. You cannot, for whatever reason, clear the app cache in Chrome's case.
However, sure enough, tab instances persist even across killing the app and then force stopping it.
I have a Redmi Note 7 and it blocked chrome for a minute, but after closing and reopening it the issue resolved itself. Weird, seems very system dependant.
The government of Lithuania actually did an investigation and found that Xiaomi phones spy on their users and contain a (disabled, probably intended for Chinese market) content filter system in their default browser.
> Chrome freezes and/or crashes. Note: this is even worse if the URL was opened from an intent. In that case, Chrome can end up completely bricked because upon restart it will immediately attempt to re-open the URL that crashed it. I could not recover from this without having to fully "Clear Storage".
You’re telling me Chrome does not have that feature where after a few failed attempts, the browser offers you to not open the websites from the previous session? Firefox has that.
There wasn't anything there to be honest. Nobody had replied to it and it was still status:unconfirmed. The instructions were pretty bare - just visit the afflicted link.
There wasn't any response or activity prior to it being marked as private.
Warning: if you do this on your Android phone at the moment, you may have to completely clean your Chrome application storage to be able to use the app afterwards.
> Note: this is even worse if the URL was opened from an intent. In that case, Chrome can end up completely bricked because upon restart it will immediately attempt to re-open the URL that crashed it. I could not recover from this without having to fully "Clear Storage".
Too late for me. Not even from intent. Chrome force stop later, it still tries to load it and immediately crashes.
Off Topic: I don't get it why, after 10 years of mobile browser development, there still is no "close all tabs at end" option. Every time I visit my parents, I have to clean up their 150+ open chrome android tabs because they don't understand how to properly clean up their browsing sessions. Why on earth would I want to open the same old tabs in the morning, that I already looked at the day before?
Because for a large number of people (including me) tabs are also bookmarks. Granted, most of them I’ll never get back to, but it’s a habit that’s difficult to break.
I think bookmarks on Desktop disappeared for a reason: They are not really useful. On Android, you can save "bookmarks" as symbol-links or install in case of PWAs. These symbols can be organized pretty good using the main Android interface. No need for a dedicated browser feature.
On Desktop, if I want to memorize a blog post etc., I use tools such as ArchiveBox, which also prevents later inaccessibility.
To memorize pages on Desktop, there're better features available that integrate more direcly on the OS level, e.g. similar to Android symbols.. There are also self hosted link organizers with tagging feature etc.
That's not sarcasm. Because this feature is missing on chrome android I only have the option to close all tabs or to manually open each tab and decide to bookmark it or not.
I disable url bar autocompletion for history, so it's only for bookmarks and open tabs, and use my bookmarks as a way to choose which sites are easy to get to.
There are such options on Firefox. Auto close and close on quit, although annoyingly the latter now requires choosing quit from the app menu instead of just closing the app like a few years ago. There is also "close all tabs" if you just hold the tab button, as well as in the ... menu on the tab screen
You are right. My point is that you have to take steps to close tabs, if it is just "explicitly closing Firefox". On Desktop, the browser will be terminated on shutdown. Shutdown does not apply to phones. If I want to close all tabs the second I lock my phone - no such thing. It would be enough having a "Stop all Apps&Tabs at 12am" feature.
This is really why I avoid browsing things on my phone at all, or use self-hosted progressive web apps that run in dedicated tasks.
Btw. - can someone explain why my initial comment is downvoted - Is it because my use case appears ignorant or unusually extravagant?
I just did and the whole phone was frozen. I couldn't force close Chrome, nor do a graceful power off. After 2 min, a notification came up that allowed me to finally close the browser.
Amazing how even after an army of contributors and a fairly old project still has bugs as trivial and yet significant as this one. It's a regression, but even so.
well most people work for $$ or for promotion so usually bug fixing is less important than landing some new privacy sandbox advertisement things. Also by reviewing code carefully doesn't make you stride the ladder. And if there are bugs they can just tell their manager we fixed this bug etc.And Google organization structure incentivize them. And now google has hegemony on Desktop browser and controls the engine they can get away easily. This is also probably reason why many products are simply killed by google.
Surprised this wasn't submitted or treated by Google as a security defect. I don't think Google pays out for DoS typically, but considering how easily this can be weaponized, this one probably should've paid out.
Especially if the mechanism of the crash also allows for an RCE that hasn't been discovered yet. Worth equipping fuzzers with the URL as a prefix.
Edit: They reclassified it as a security defect and restricted permissions on it after my comment directly on the bug.
Absolutely. I'm surprised this isn't marked as critical.
If this was included in malicious emails and texts, it would block the use of Chrome on Android completely and the only current fix is to clear all browser data i.e. bookmarks, passwords etc.
Did this to Chrome on Android & it crashed, but only for the first time. Subsequent requests simply took me to google search results instead of resolving the URL.
On older versions of Chrome just goes to google.com and searches for this string. That's why i disabled automatic updates on my phone. Give me a changelog and i update. Bug fixes and performance improvements it's not a changelog.
i used to not like updated, and just postponed them. then noticed that after a while android would just update everything silently (without my consent).
so i guess... whatever, it's a lost cause. I hate modern smartphones.
The bug report contains expected result "DNS resolution error, or some kind of non-fatal error in general." - so that's what I meant by works as expected. It just shows DNS failure page, it does not crash the browser.
But actual crashes are most likely due to memory unsafety; I’d be extremely surprised if the root cause was not found to be in a memory-unsafe language, though I doubt it’ll be in the URL parser.
Memory safe languages also have crashes, often uncaught exceptions, or explicit calls to abort() or similar functions (die, panic, etc...). Infinite recursion, and the resulting stack overflow is another common cause of crash that can happen in any language.
In fact, a crash (segmentation fault) is an exception. In theory, the program could catch it and try to recover from it, it is just that it is a terrible thing to do because you can't be sure of anything from now one.
In fact, letting the program crash is the basis of "offensive programming". This idea opposes the idea of defensive programming, where you try to be prepared for anything and try to do something sensible. In offensive programming, you crash when things are not as expected. For example, if you ask for the 5th element of a 4 element list, in the former, you return some kind of default value, in the latter, you crash with an "out of bounds" exception, or let a watchdog restart the system.
That's a weak statement: isn't Chrome is almost entirely written in C++? I suppose you mean it's a memory overrun or use are free. You're probably right, then.
But in Rust, something like this could happen too, if someone added a panic!, e.g. on parsing a domain name with an empty component, or failure to put the domain name in a certain (external) structure. If the URL is parsed again on start-up, the application would be bricked. Granted, it's much easier to find and solve.
I would guess that various parts of Chrome for Android, especially its UI, might be in a memory-safe language. But yeah, in hindsight my word choice was poor; I should have said a root cause of memory unsafety.
As for Rust, if we’re talking about outright crashes (which on reflection I’m not sure if we actually are because of laxness in the definition of “crash”—I retract my proffered extreme surprise), panicking isn’t that (unless compiled with abort-on-panic or if a destructor panics while unwinding)—panicking is controlled and can (except for the cases already mentioned) be caught.
To be sure, you can still brick the app in the described way with persisted data triggering exceptions or panicking, but there at least can still be a difference.
For one thing that are plenty of toy languages where you'd be lucky to do anything in particular, including shoot yourself in the foot, "easily".
But also there are languages which have much higher bars for safety than you seem to have imagined. Notice how WUFFS doesn't have a "Hello, world." example program because printing out Hello, World is way too dangerous to be allowed in WUFFS even on purpose.
It is well known that URLs are hard; nobody should ever trust their own implementation of a URL parser unless it is sufficiently tested (payload repositories exist for a reason).
And under circumstances testing the own url parser _alone_ is only half (?) of the story. The other URL parsers within the system or in the line need to be tested, too. Which mathematically might not be possible. So next to the URL parser it is likely practically to have an URL filter. And with it, a good test-suite, too.
The only thing you can do is uninstall the updates, which force resets its persistence, losing all of your stored data/sessions.
If you've already done that... tough luck, I guess?
What an awful bug.