Crash when entering more that. 3 characters in URL bar
Categories
(Firefox for Android :: General, defect)
Tracking
()
People
(Reporter: ska1, Assigned: jackyzy823)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
59 bytes,
text/x-github-pull-request
|
Details | Review | |
59 bytes,
text/x-github-pull-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
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.
Comment 1•2 years ago
|
||
Has anyone produced a crash report with a stack of the crash?
Comment 2•2 years ago
|
||
(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
Comment 3•2 years ago
|
||
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.
Comment 4•2 years ago
•
|
||
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.
Comment 5•2 years ago
|
||
(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
Comment 6•2 years ago
|
||
(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
Comment 7•2 years ago
|
||
(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...
Comment hidden (off-topic) |
Comment 9•2 years ago
|
||
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.
Comment hidden (off-topic) |
Reporter | ||
Comment 11•2 years ago
|
||
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.
Comment 12•2 years ago
|
||
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.
Comment 13•2 years ago
|
||
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 alsocrash
,hing
, or evena
will crash - Whole string matter:
a
andb
are crashing, butab
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 phonehtt
orgithub
crashes, but not the whole string (surprisingly neither doeshttp
). This is also probably not the only crashing “superstring”, asa
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.
Comment 14•2 years ago
|
||
Yeah the crash doesn't happen only with the url, it happens literally anywhere
Comment 15•2 years ago
|
||
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.
Comment 16•2 years ago
|
||
(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.
Comment 17•2 years ago
|
||
(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.
Comment 18•2 years ago
|
||
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.
Comment 19•2 years ago
|
||
Thanks a lot, worked perfectly!
Comment 20•2 years 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
Comment 21•2 years ago
|
||
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.
Comment 22•2 years ago
|
||
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.
Assignee | ||
Comment 23•2 years ago
|
||
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).
Comment 24•2 years ago
|
||
Uhh is it going to be fixed, or we need to uninstall Firefox completely?
Comment 25•2 years ago
|
||
Uhh now the crash evolved, it froze the whole phone
Comment 26•2 years ago
|
||
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:
- open N github homepage tabs (number will vary based on your RAM and your tab opening speed)
- 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 ofloadIcon
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
ignoresdesiredSize
, 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
Comment 27•2 years ago
|
||
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?
Assignee | ||
Comment 28•2 years ago
|
||
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.
- I build test debug apk with reverting the commit 9d916549240b3361bea5e395d054880f824b7abd
Link : https://send.ephemeral.land/download/fbea4836b6989cb5/#cfF6W_dvZmvQ51b-odHWuw - 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"
- Follow steps to enable Debug Menu: https://github.com/mozilla-mobile/firefox-android/blob/main/fenix/docs/Secret-settings-debug-menu-instructions.md
- "Secret Settings" -> Toggle on Enable Debug Drawer
- Click the new shown "bug" fab (floating action button) , click Tab Tools , set numer of tabs to open and click "Add to ..."
Comment 29•2 years ago
|
||
I tested both builds in three test cases:
- 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
- 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)
- 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
- Results are mostly swift, about half a second to show some results if I enter an unreasonable query (
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.
Comment 30•2 years ago
|
||
Comment 31•2 years ago
•
|
||
Thank you so much for the detailed info provided everyone, hugely appreciated!
A couple of things:
- 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). - If required, then a follow-on bug should be created to investigate replacing the use of Coil with AndroidSVG or an alternative.
- We should potentially be limiting the number of suggested results and some behaviour around displaying duplicate URLs/Switch to tabs
- 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)
Comment 32•2 years ago
|
||
Jackyzy823 you've done some great work on this, can you confirm that this patch resolved the issue?
Comment 33•2 years ago
|
||
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.
Assignee | ||
Comment 34•2 years ago
|
||
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.
Comment 37•2 years ago
|
||
Could you point me to an apk version with this fix? Than I could confirm if the fix is working on my devices!
Assignee | ||
Comment 38•2 years ago
|
||
-
revert commit
https://send.ephemeral.land/download/fbea4836b6989cb5/#cfF6W_dvZmvQ51b-odHWuw -
trycatch oom
https://send.ephemeral.land/download/657310447d134ebf/#cO7Jy_sdgOyQZtVD41_nMg -
From https://github.com/mozilla-mobile/firefox-android/pull/5378
https://firefox-ci-tc.services.mozilla.com/tasks/ZcMHfVCYRdSmi2bWHTgSMQ
Comment 39•2 years ago
|
||
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.
Comment 40•2 years ago
|
||
Comment 41•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 42•2 years ago
|
||
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
Updated•2 years ago
|
Updated•2 years ago
|
Comment 43•2 years ago
|
||
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
towontfix
.
For more information, please visit BugBot documentation.
Comment 44•2 years ago
|
||
:twhite can you follow-up on a beta uplift request here?
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 45•2 years ago
|
||
Comment 46•2 years ago
|
||
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
Comment 48•2 years ago
|
||
Comment 49•2 years ago
|
||
The patch will be uplifted to version 123 shortly, any feedback on whether this bug is resolved or not would be super helpful.
Comment 50•2 years ago
|
||
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)
Comment 51•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•