Closed Bug 1874522 Opened 2 years ago Closed 2 years ago

Crash when entering more that. 3 characters in URL bar

Categories

(Firefox for Android :: General, defect)

Firefox 121
All
Android
defect

Tracking

()

VERIFIED FIXED
124 Branch
Tracking Status
firefox122 --- wontfix
firefox123 --- verified
firefox124 --- verified

People

(Reporter: ska1, Assigned: jackyzy823)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Android 13; Mobile; rv:121.0) Gecko/121.0 Firefox/121.0

Steps to reproduce:

Thread is on reddit, but creating bug as nobody has done so

https://www.reddit.com/r/firefox/comments/1874lux/firefox_on_android_repeatedly_crashing_on_my/

Type more than 3 characters on the address bar.
This started to happen only after very recent updates.

Devices reproduced:

Galaxy Tab S7
Pixel 6a
LG V60
Pixel 7 Pro
OnePlus 11
Galaxy S10+
Galaxy S20

Possible circumstances:
All devices had > 500 tabs. But they worked perfectly on 120.0.

Attempted workarounds:
logout from sync
delete cache. (both in Android and Firefox settings)
disable add-ons
delete browsing histories (but not tabs)
rebooting device
Disabling search suggestions
Disabling search history/tabs/bookmarks
Changing search engine

These crashes are not recorded in about:crashes. They seem to be hard crashes that take down the launcher as well as any VPN that is running. Sometimes I have to hard reboot the phone with Power+VolDown

not only because it crashes right after putting it on address bar, but the newest crash entries are from July(on S7) and January(6a).

Not reproducible on Pixel 7(120.0.1/~100 tabs) and Pixel 3(120.0/~100 tabs). Right now this means we do not know if it is due to number of tabs, device model, or Firefox version.

Well, I know 500 or 600 tabs are enourmous amount, however they were working quite flawlessly until very recently. I wish I can somehow solve this problem.

Version info:
121.1.0 (Build #2015996455), 62d5117f79+
GV: 121.0.1-20240108143603
AS: 121.0

Actual results:

Browser crashes
Launcher crashes
VPN is taken down with it

Expected results:

Browser should not have crashed and should have displayed the website entered.

Has anyone produced a crash report with a stack of the crash?

See Also: → 1864557

(In reply to Timothy Nikkel (:tnikkel) from comment #1)

Has anyone produced a crash report with a stack of the crash?

No because about:crashes doesn't mention it

I have similar issue on my Samsung Galax S23 Ultra running Android 13 (both may '23 and october '23 security patches), the only difference is that for me the last working (non-crashing) FF version is 119.1.0 . Since 120.0 FF keeps crashing frequently as described above without any crash report. FF 120.0.0, 120.1.0, 121.0.0 and 121.1.0 are all affected. Reverting to 119.1.0 makes FF usable again.

perhaps one of you could use mozregression then to narrow down the crash range. You could also try disabling all of your extensions to see if any of those are causing the crashes.

(In reply to Robert Longson [:longsonr] from comment #4)

perhaps one of you could use mozregression then to narrow down the crash range. You could also try disabling all of your extensions to see if any of those are causing the crashes.

Yeah it's obviously the extensions fault, if it the extensions fault, why it doesn't happen on 119.0.0

(In reply to Robert Longson [:longsonr] from comment #4)

perhaps one of you could use mozregression then to narrow down the crash range. You could also try disabling all of your extensions to see if any of those are causing the crashes.

I don't know why don't you download Fenixand check for yourself too, you will see the exact same problem without extensions

(In reply to Robert Longson [:longsonr] from comment #4)

perhaps one of you could use mozregression then to narrow down the crash range. You could also try disabling all of your extensions to see if any of those are causing the crashes.

No idea how to use mozregression on my Android phone...

I am also getting crashes on Pixel 6 Pro. It's been increasing in frequency over past few weeks. Now 3 times in last 30 minutes. About:crashes doesn't show anything since 2022.

However the crash still occurs without any trace. I have found that I can reduce the frequency of crashes by turning off "show search suggestions" (regardless of which search engine is chosen). It seems to be a race condition - if you type quickly you can make the search happen and then it will crash (so that when you restart the browser the search will actually happen). This shows it is not a rendering problem, but an actual problem with the URL bar code. The other indicator of this is that a workaround for the problem is to send yourself a WhatsApp message with your search term and then share the message with Firefox - it will not crash in this case, and actually operate quite a bit faster.

Also affecting me on Pixel 3a.

I'm not 100% sure, but in case it helps: it seems like this bug isn't only related to the URL bar. I've had it crash when typing something into the URL bar before, but I've also had it just be slow on the URL bar, and then I'm able to go to a page and it crashes 30 seconds later. Both types of crashes started happening for me a couple weeks ago, so the timing makes me think it's the same issue.

Also, when it crashes and I reopen it, Firefox doesn't remember the last page I went to.

Sometimes, it works okay for a while, but usually when it crashes once, if I reopen Firefox it'll keep crashing again soon after I open it, so the browser has been pretty unusable.

My devices are Galaxy S21 FE (“Mobile”) and Galaxy Tab S7+ (“Tablet”). These unexplained crashes are happening on both my devices, and as for everyone, they started on both of them at once a few weeks ago. Both have significant amount of tabs. They are significantly more pronounced on my tablet, than on the mobile phone. To give you an idea, I had to stop using this browser on the tablet, as anything I put into the URL bar would crash it. On mobile phone it isn't that bad — estimation is that it crashes about 20% of the time, or less. Surprisingly, crashes are also happening on a friend's mobile phone, and that one does not even have a lot of tabs open — only 8.

I tried pretty hard to reproduce this issue in an artificial environment, on a newly installed instance of the browser, even on the same devices, same versions, but I couldn't get it to trigger at all. I attempted to open a significant amount of tabs (roughly ~3k meaningless google searches), logged in those browsers to sync history & tabs, tried opening a few meaningful sites, and nothing. Furthermore, I tried getting any meaningful crash report, but there is nothing in crashes, and neither could I glance anything in logs got via connecting to ADB.

So bereft of any advanced options, but with near 100% reproducibility on my tablet, I turned to humanity's old friend: the scientific method. After wasting a whole evening trying out stuff with my tablet, and a bit with the friend's mobile, I found out a few things:

  • The crashed are delayed by a lot - around 10 seconds or more, on fairly fast devices. You can easily type your entire search, load page, press result, load that page, and it will only crash then, despite the cause of crash being the search you make by typing your first letter. This obscures the cause a lot in, as can be seen in feedback from others.
  • Within the frame of one device, crashes seem to happen reasonably deterministically. If you type for example string crashing and it crashes / doesn't crash, then if you later type it again, it will do the same thing
  • Crashes are definitely related to the search results. Getting a “crashing string” to URL bar via a method that doesn't trigger a search (for example, the “paste URL” that appears near URL bar) will not trigger a crash. Crash also won't get triggered if you are not using the offending search method, but the method itself may vary. On my tablet it was Tab search, on friend's phone it was History search. This also means it crashes with default search engine, but only if it's default — changing the default from X to Y makes search engine X not crash, but Y to do so
  • Any substring of a crashing string seems to be also a crashing string, given that crashing crashes, then also crash, hing, or even a will crash
  • Whole string matter: a and b are crashing, but ab isn't
  • Now the punchline: Given these rules holding, I went and tried to find the longest crashing strings I could on my tablet. Right now, I'm at the strings a (prefixed with space), -. re and ... https://github.com/. It's not crashing on my mobile phone, nor any reasonable substring of it. On friend's phone htt or github crashes, but not the whole string (surprisingly neither does http). This is also probably not the only crashing “superstring”, as a or (just space) are crashing too.
  • I closed any tab with github in url on tablet (via copying all urls & grep-ing them), yet this still crashes.

I guess that's enough for now. So far, the hypothesis is that there is some “bad actor” (or more), that when it shows up in a URL search, it will trigger the crash in a few seconds, or start some resource leak. This bad actor is either device specific, depends on some configuration or I changed something while testing on the tablet, as I'm currently unable to trigger crash on phone on purpose. This would be consistent with the fact that it mostly shows up on "tab-hoarders" people phones, as (open & synced) Tab search is most likely where such an actor can be hit - since all other searches are limited to just a few results.

I'll report back if I'll find something more.

Yeah the crash doesn't happen only with the url, it happens literally anywhere

I have also been experiencing this for the last... I don't know, maybe a week.

Got it to stop, so far, by closing all the tabs, of which there were a lot.

The only extension I got installed is uBlock Origin, the one with the "Recommended" tag and loads of other users.

(In reply to qbanin+mozilla from comment #3)

I have similar issue on my Samsung Galax S23 Ultra running Android 13 (both may '23 and october '23 security patches), the only difference is that for me the last working (non-crashing) FF version is 119.1.0 . Since 120.0 FF keeps crashing frequently as described above without any crash report. FF 120.0.0, 120.1.0, 121.0.0 and 121.1.0 are all affected. Reverting to 119.1.0 makes FF usable again.

I'm getting this terrible bug on my Samsung Galaxy S10 5G.

Is there any way to downgrade to 119.1.0 while keeping all my (numerous) tabs? I tried downloading the apk from here, but my phone just says, "app not installed", I presume because it's an older version than the broken one I have installed currently.

(In reply to dr.elephant+bugzilla from comment #16)

(In reply to qbanin+mozilla from comment #3)

I have similar issue on my Samsung Galax S23 Ultra running Android 13 (both may '23 and october '23 security patches), the only difference is that for me the last working (non-crashing) FF version is 119.1.0 . Since 120.0 FF keeps crashing frequently as described above without any crash report. FF 120.0.0, 120.1.0, 121.0.0 and 121.1.0 are all affected. Reverting to 119.1.0 makes FF usable again.

I'm getting this terrible bug on my Samsung Galaxy S10 5G.

Is there any way to downgrade to 119.1.0 while keeping all my (numerous) tabs? I tried downloading the apk from here, but my phone just says, "app not installed", I presume because it's an older version than the broken one I have installed currently.

https://www.makeuseof.com/downgrade-android-app-with-adb/

Just thought I'd also mention that when this crash happens on my S10 5G, it crashes and restarts the whole launcher and also music player if it's going in the background, eg Youtube Music. Like everyone says it's definitely the url/search bar in Firefox that causes it, and nothing comes up in about:crashes. I have probably 200 tabs but never had a problem until maybe 2 weeks ago.

It's nice, but the workaround won't won't be around forever, the developers must put themselves down on the chair and fix it

100% agree, I've been using Firefox Android for probably a decade now, but it has to get fixed or Firefox is unusable for me.

For the moment I need to downgrade in order to use Firefox at all.

Typing github (or any substring) into url bar reproduces the issue for me.

I've tested beta builds from CI. I've replaced FF on my affected device using following command adb install -r -d target.arm64-v8a.apk.

  • Good version: 8d0b96a23f54b1b57b7d245c5cfa050daba4a7e2 from 2023-11-10
  • Bad version: eb3efa61baaaa1fa8e61cc600bc0c53e55693f64 from 2023-11-20

(note that commits above are not on main branch)

I've installed nightly build and after logging in and syncing all tabs, I could reproduce the issue. (Link to nightly apks)

  • Good version: 107c02556cd334942fc322d31eb9d492cb82d009 (latest nightly build on 2023-10-18)
  • Bad version: d037bba616ef1cd3206069a33a823f832fd7ac70 (first nightly build on 2023-10-19)

List of the commits between these two:

  • d037bba616 Bug 1859839 - Update 'manage search shortcuts' string in Search settings
  • fcd5f4eefc Bug 1858297 - Store FxSuggest db in cache directory
  • f7157e9aac Bug 1859338 - Fixes ability to use talkback on LinkText
  • 29ad034aca Import translations from android-l10n
  • ee738b1904 Update GeckoView (Nightly) to 120.0.20231018160439.
  • ff20fabaf4 Bug 1858879 - Changed link text in FeltPrivacyInfoCard to default text color
  • f530f17d9d Bug 1858872 - Switch "windows" with "tabs" in private mode description
  • a7d772b71f Bug 1859488 - Updates mask in private_browsing_button.xml
  • 081a221951 Bug 1858997 - Ensures we remove the Popup when destroying the fragment
  • 4851d6f7db Bug 1849073 - Part 5: Remove the Add Search Engine fragment
  • bd2b3fc746 Bug 1853077 - Update Adjust to version 4.35.1
  • 117c86253f Bug 1857092 - Add metrics for clicks on Firefox Suggestions in Fenix
  • 1536ab0d82 Bug 1838841 - Ship 120.0.0 of feature-webcompat
  • 107c02556c Update GeckoView (Nightly) to 120.0.20231018094117.

No idea how to narrow that further. Is there a way to obtain nightly apk build for particular commit? Hopefully this is enough for some dev to figure out what's the issue.

Is there a way to obtain nightly apk build for particular commit?

For each commit , you could visit https://github.com/mozilla-mobile/firefox-android/commits/main/ and click the commit's check mark , it will show a dialog, then find the line "signing-apk-fenix-debug" and click "details" , then click "View task in Taskcluster" in the new opened page, then you could download Artifacts (like public/build/target.arm64-v8a.apk).

Uhh is it going to be fixed, or we need to uninstall Firefox completely?

Uhh now the crash evolved, it froze the whole phone

Oki, not sure what went wrong with Peter's bisect, but I managed to reproduce my issue on my Galaxy Tab S7+ in nightly, very consistently, and therefore I could make my own bisect via mozregression.

The result is a bit elsewhere: a good nightly fenix build is 2023-11-07 and bad one is next day 2023-11-08.

Given these facts:

  • discussion in Bug 1864557, which mentions the Coil library having some memory problems, and since the issue looks exactly the same as this bug
  • the fact that this is happening on Github on at least two completely unrelated accounts/devices
  • Github has a SVG favicon in tippy list every since this commit

I am strongly suspecting this commit adding SVG decoding is the root cause of the issue.

I investigated more with these facts & the commit's code, and I can now also reproduce this bug without the need for syncing real user's profile. The steps I used for this are:

  1. open N github homepage tabs (number will vary based on your RAM and your tab opening speed)
  2. given enough open tabs type g into url bar, and crash will soon occur

Now, this might seem insane to just go opening tabs, given the tab counts people gave here, but on my device, with a fair amount of RAM and opening tabs slowly (giving FF time to reclaim any unneeded memory), I only needed ~20 tabs to cause the crash. At this number when I searched for g, my keyboard crashed quickly, but before FF crashed, I could quickly glance the result list actually updating to make github results appear (it did not manage to do this at larger sizes, or real data)

Hypothesis:

  • At typing g to URL query bar, FF fires of loadIcon request for every result.
  • They all miss cache at once, since none of the requests were processed yet. (Supported by ConcurrentModificationException firing somewhen later, likely when storing the load results)
  • For every result that has SVG favicon (github), FF tries to convert it bitmap via the commit above
  • Notably here SvgIconDecoder.decode ignores desiredSize, likely causing the SVGs to render at very high resolutions, resulting in large bitmaps taking a sizeable chunk of memory (I wasn't able to trace at what, but likely related to browser size?)
  • Given a small amount of these parallel generations, you can run out of memory very quickly before they even end, and cause the OOM crash

Any post-119 Firefox is just unusable for me on my Pixel 8 Pro due to this issue crashing my entire system and forcing all apps to shutdown, including my always-on VPN. Is this going to get assigned S2 severity?

Hello , Roukanken.

Thanks for your details! It really helps a lot.

Since you could reproduce the issue constantly , It would be helpful if you could help testing my build.

  1. I build test debug apk with reverting the commit 9d916549240b3361bea5e395d054880f824b7abd
    Link : https://send.ephemeral.land/download/fbea4836b6989cb5/#cfF6W_dvZmvQ51b-odHWuw
  2. I build with following modification : set size to ImageReust.Builder and catch OOM error.
--- a/android-components/components/browser/icons/src/main/java/mozilla/components/browser/icons/decoder/SvgIconDecoder.kt
+++ b/android-components/components/browser/icons/src/main/java/mozilla/components/browser/icons/decoder/SvgIconDecoder.kt
@@ -21,13 +21,17 @@ import mozilla.components.support.images.decoder.ImageDecoder
  */
 class SvgIconDecoder(val context: Context) : ImageDecoder {

-    override fun decode(data: ByteArray, desiredSize: DesiredSize): Bitmap? {
-        val request = ImageRequest.Builder(context)
-            .data(data)
-            .build()
-
-        return SvgImageLoader.getInstance(context).executeBlocking(request).drawable?.toBitmap()
-    }
+    override fun decode(data: ByteArray, desiredSize: DesiredSize): Bitmap? =
+        try {
+            val request = ImageRequest.Builder(context)
+                .size(desiredSize.targetSize)
+                .data(data)
+                .build()
+
+            SvgImageLoader.getInstance(context).executeBlocking(request).drawable?.toBitmap()
+        } catch (e: OutOfMemoryError) {
+            null
+        }

     private object SvgImageLoader {
         @Volatile

Link: https://send.ephemeral.land/download/657310447d134ebf/#cO7Jy_sdgOyQZtVD41_nMg


I also modified the url in debug drawer to help quickly opening multiple Github URL

diff --git a/fenix/app/src/main/java/org/mozilla/fenix/debugsettings/tabs/TabTools.kt b/fenix/app/src/main/java/org/mozilla/fenix/debugsettings/tabs/TabTools.kt
index c6daa5d80e..1faecef0c7 100644
--- a/fenix/app/src/main/java/org/mozilla/fenix/debugsettings/tabs/TabTools.kt
+++ b/fenix/app/src/main/java/org/mozilla/fenix/debugsettings/tabs/TabTools.kt
@@ -97,7 +97,7 @@ private fun generateTabList(
     isPrivate: Boolean = false,
 ) = List(quantity) {
     createTab(
-        url = "www.example.com",
+        url = "https://github.com",
         private = isPrivate,
         createdAt = if (isInactive) 0L else System.currentTimeMillis(),
     )

How to enable "Debug Drawer"

  1. Follow steps to enable Debug Menu: https://github.com/mozilla-mobile/firefox-android/blob/main/fenix/docs/Secret-settings-debug-menu-instructions.md
  2. "Secret Settings" -> Toggle on Enable Debug Drawer
  3. Click the new shown "bug" fab (floating action button) , click Tab Tools , set numer of tabs to open and click "Add to ..."
Flags: needinfo?(kuko0411)

I tested both builds in three test cases:

  1. Reasonable (50 open github tabs)
    • Both builds are swift here
    • Results show immediately (which isn't the case even with ~10 open github tabs on nightly)
    • No crash
    • No signs of OOM
  2. Unreasonable (3000 open github tabs)
    • Takes a fair while to show search results (5-10 sec), with the revert build being a bit swifter, scrolling through result list is laggy (pretty much expected)
    • No crash
    • And still no signs of OOM, not even keyboard crash (which was always one of the first thing to go down, even before FF)
  3. Real (syncing tabs from my other devices)
    • Results are mostly swift, about half a second to show some results if I enter an unreasonable query (http). Search for github works fine on both.
    • No crash and no signs of OOM

Of course, the obvious difference between them is that modified build shows icon properly & reverted doesn't.

So yeah, both builds behave exactly as expected according to my hypothesis.

Flags: needinfo?(kuko0411)

Thank you so much for the detailed info provided everyone, hugely appreciated!

A couple of things:

  1. If possible, I think any fix for this particular bug (e.g prevents the crash) should be scoped around the existing SvgIconDecoder, potentially by adding the try-catch and explicitly setting the size (as Jackyzy823 demonstrated here).
  2. If required, then a follow-on bug should be created to investigate replacing the use of Coil with AndroidSVG or an alternative.
  3. We should potentially be limiting the number of suggested results and some behaviour around displaying duplicate URLs/Switch to tabs
  4. I'm unable to reproduce an OOM exception, however I can recreate the crashing behaviour with the following error message:
2024-01-31 14:00:31.674  9458-10439 EditToolbar             org.mozilla.fenix.debug              E  Error while processing autocomplete input
                                                                                                    java.util.ConcurrentModificationException
                                                                                                    	at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1212)
                                                                                                    	at java.util.TreeMap$KeyIterator.next(TreeMap.java:1266)
                                                                                                    	at mozilla.components.feature.toolbar.ToolbarAutocompleteFeature$2.invokeSuspend(ToolbarAutocompleteFeature.kt:38)
                                                                                                    	at mozilla.components.feature.toolbar.ToolbarAutocompleteFeature$2.invoke(Unknown Source:13)
                                                                                                    	at mozilla.components.feature.toolbar.ToolbarAutocompleteFeature$2.invoke(Unknown Source:6)
                                                                                                    	at mozilla.components.browser.toolbar.AsyncFilterListener$invoke$1.invokeSuspend(BrowserToolbar.kt:595)
                                                                                                    	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
                                                                                                    	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
                                                                                                    	at java.lang.Thread.run(Thread.java:920)

Jackyzy823 you've done some great work on this, can you confirm that this patch resolved the issue?

Flags: needinfo?(jackyzy823)

ConcurrentModificationException is probably not entirely related to crash - it happens even in non-crashing circumstances. For example, if I copy-paste github.com/a into URL bar on my real profile, resulting in ~10 results, I do not get a crash but CME pops out in logcat.

Best guess, without diving in deeper, is that it happens on one some cache of the icons, due to the concurrent generation tasks for the same icon.

can you confirm that this patch resolved the issue?

Sorry , I'm not sure :(
I couldn't reproduce this bug on my device.

Based on :Roukanken 's feedback, this patch might work. Hope that other affected users could help testing.


adding the try-catch and explicitly setting the siz

If possible , we should also disable coil-kt 's cache mechanism, since we have it too.


I can recreate the crashing behaviour with the following error message:

Looks like bug 1872735 , since it also crashed in automation tests , i don't think it might be related.

Flags: needinfo?(jackyzy823)
Duplicate of this bug: 1812691
Duplicate of this bug: 1807413
No longer duplicate of this bug: 1812691
No longer duplicate of this bug: 1807413

Could you point me to an apk version with this fix? Than I could confirm if the fix is working on my devices!

All three options solve the issue for me. Tested by opening 50 tabs of github.com and then typing github slowly in the url bar.

I tested all three builds, and they don't show the crash. I compared them with the CI build of your PR's parent commit as known bad build, which crashes immediately with only one tab.

The trycatch OOM build is slow though.

Flags: needinfo?(thor)

Authored by https://github.com/jackyzy823
https://github.com/mozilla-mobile/firefox-android/commit/5a584b45db40ba51eb5a247bbd94ea789a136b08
[main] Bug 1874522 - Catch OOM, set desired size and disable coil-kt cache in SVG decoder

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch
Assignee: nobody → jackyzy823
Flags: qe-verify+

The patch landed in nightly and beta is affected.
:jackyzy823, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox123 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(jackyzy823)

:twhite can you follow-up on a beta uplift request here?

Flags: needinfo?(towhite)
See Also: → 1879116
Flags: needinfo?(jackyzy823)
Attachment #9377346 - Attachment is obsolete: true

Comment on attachment 9379004 [details] [review]
[mozilla-mobile/firefox-android] Bug 1874522 - Catch OOM, set desired size and disable coil-kt cache in SVG decoder (backport #5443) (#5522)

Beta/Release Uplift Approval Request

  • User impact if declined: Potential Out of Memory exception causing application to crash
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comments in bug, this is dependent on a number of variables and not always easy to reproduce
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Adding the try-catch for the OOM & setting the explicit image size in the decoder is good practice regardless of this bug and consistent with the other 'decoders'.
  • String changes made/needed: No
  • Is Android affected?: No
Flags: needinfo?(towhite)
Attachment #9379004 - Flags: approval-mozilla-beta?
Duplicate of this bug: 1864557
Comment on attachment 9379004 [details] [review] [mozilla-mobile/firefox-android] Bug 1874522 - Catch OOM, set desired size and disable coil-kt cache in SVG decoder (backport #5443) (#5522) Approved for 123 beta 9, thanks.
Attachment #9379004 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

The patch will be uplifted to version 123 shortly, any feedback on whether this bug is resolved or not would be super helpful.

Authored by https://github.com/mergify[bot]
https://github.com/mozilla-mobile/firefox-android/commit/d598bb347361a30f22557428a8ec22b239a8764e
[releases_v123] Bug 1874522 - Catch OOM, set desired size and disable coil-kt cache in SVG decoder (backport #5443) (#5522)

I managed to reproduce the crash on the latest RC 122.1.0 build using a Samsung Galaxy S23 Ultra (Android 14).
Reproduced using 60-65 github tabs opened, then slowly typing "gith..." in the URL bar, the crash happened every time.
Verified as fixed on the latest Nightly (124.0a1 from 2024-02-12) and latest Beta 123.0b9 builds.
Marking the ticket as verified.

Status: RESOLVED → VERIFIED
Duplicate of this bug: 1876622
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: