fenix
fenix copied to clipboard
mozilla-mobile
[Bug]: Couldn't change wallpaper
Steps to reproduce
- Open firefox nightly
- A Toast message pops up with the message "Couldn't change wallpaper"
- Wait for what feels like an eternity for the toast to disappear and allow access to the address bar
Expected behaviour
Toast shouldn't appear
Actual behaviour
Toast appears
Device name
OnePlus Nord N10 5G
Android version
Android 11 (Oxygen OS 11.0.7.BE89BA)
Firefox release type
Firefox Nightly
Firefox version
106.0a1 (Build #2015904267)
Device logs
No response
Additional information
Quickly looking through the issue tracker, I can see references to a wallpaper onboarding process. I don't really remember doing that - so maybe it got skipped somehow? Or maybe I exited it in a hurry and completely forgot.
Also, going to start page customization > wallpapers (I'm translating localized names, not sure what the english ones are), I see that there are no wallpapers (the list is empty).
If there are any more debug logs I could provide, I'd be happy to do so (I'd rather not go the adb route, but I can if necessary - I'd fix it myself if I knew kotlin... that's just how much it bothers me. But I don't know Kotlin).
┆Issue is synchronized with this Jira Task
The cause - no wallpapers is being discussed here - https://github.com/mozilla-mobile/fenix/issues/26997 and will be fixed in the next coming days.
Fixing the root cause is great, but there's a second bug, being that when that toast is displayed, the address bar and button around are unreachable.
(I'm not always blocked by this though, sometimes the toast disappears quickely ¯\_(ツ)_/¯)
The workaround I found when that happen and the toast doesn't go away is to scroll the homepage down a bit, and it quickely disappear.
I just updated to the latest nightly (107.a1), went to customization > wallpapers and selected the default wallpaper. I no longer see the error message (It'd be nice if I didn't need to change any settings, but I don't really mind; this is nightly after all).
However, some feedback: What @bew said is correct in terms of ux. My first instinct when I saw that message was to try to swipe it / drag it down to make it disappear, and was a bit surprised when that didn't work and I had to wait.
So while it seems that the original issue is resolved, I'll leave this open until a decision on toast behavior is made. Feel free to close once that is done.
The cause - no wallpapers is being discussed here - #26997 and will be fixed in the next coming days.
That issue is verified fixed in Nightly but "Couldn't change wallpaper" is still around.
Regardless, the "fix" has already landed: After updating to the latest nightly (107.a1), you have to go to "new tab customization" (or whatever it's called in English) and then wallpapers. Tap on any one of them (even the if it's already selected). That makes the error disappear.
My suspicion is that this has to do with our migration code from v1 to v2. I would guess there is some error where we are trying to set the wallpaper used during v1 and failing to find it. This could even happen in the default case if we made a mistake with naming. I will investigate, but some more information to help reproduce would be useful.
- Before the issue started, was the default wallpaper used or was another wallpaper selected?
- When the issue started, was the same wallpaper being displayed or did it appear to change automatically?
@MatthewTighe At least for me, I had never changed wallpapers and did not know the feature existed. I had the default basic gray background, and it did not change when the issue started.
- I had never selected a wall paper -- I didn't know the feature existed.
- Before the issue started my background was plain white/light gray.
- After the issue started my background was plain white/light gray.
The "fix" instructions stopped the message from appearing but had a side-effect. Clicking Customize homepage/Wallpapers didn't show any selected, I selected blank and then exited settings. But them shortcuts appeared on my homepage so I needed to go back into Customize homepage to turn them off.
(It's possible I unintentionally tapped "shortcuts" on my way to wallpapers, but I don't think so. Shortcuts and Sponsored Shortcuts were both selected so that would have taken two taps to enable, unless sponsored had been turned back on by some previous update.)
Great, thanks for the feedback! Based on that, I'd actually guess this is because of a missing condition in how we're applying wallpapers. We were not handling the blank name case for when a wallpaper had not been set, which was causing us to try and load a wallpaper for the blank name and failing. https://github.com/mozilla-mobile/fenix/pull/27079 should resolve it.
I'm still unable to reproduce, unfortunately. I'm not completely sure why to be honest - I would expect this case to be hit by anyone that had not set a wallpaper before the current nightly. Upgrading does not seem to cause the issue for me.
If anyone experiencing the issue happens to know what nightly version they were on prior to the bug, that would help further investigation and QA efforts.
This issue is no longer reproducible with the latest Nightly 107.0a1 (2022-09-21) build. Device used: oppo Find X5 (Android 12). Closing the ticket as verified.
I'm still seeing this with the latest Nightly build on my device. @MatthewTighe
Alright, https://github.com/mozilla-mobile/fenix/pull/27112 should actually resolve this bug.
It turns out the old "default" wallpaper was actually named "NONE", so everyone experiencing this bug was trying to load a wallpaper with that name and failing.
To reproduce the bug, first install a nightly build from between Dec 21 2021 and Jan 22 2021. Upgrading to the nightly before https://github.com/mozilla-mobile/fenix/pull/27112 lands should display the bug. Upgrading to the nightly after https://github.com/mozilla-mobile/fenix/pull/27112 should resolve it.
Hi, this is currently still reproducible with Google Pixel 6 (Android 13) after updating to Nightly107.0a1 from 09/23 created at around 8 a.m., local time.
The issue reproduces as detailed in https://github.com/mozilla-mobile/fenix/issues/26424#issuecomment-1253672519 for Cerulean, Amethyst, Sunrise wallpapers. We will re-test this on Monday, since maybe https://github.com/mozilla-mobile/fenix/pull/27112 did not make it to this Nightly.
The issue reproduces as detailed in https://github.com/mozilla-mobile/fenix/issues/26424#issuecomment-1253672519 for Cerulean, Amethyst, Sunrise wallpapers. We will re-test this on Monday, since maybe https://github.com/mozilla-mobile/fenix/pull/27112 did not make it to this Nightly.
I believe https://github.com/mozilla-mobile/fenix/pull/27112 did make it into the latest nightly, but @rvandermeulen may be able to correct me if I'm wrong. If the behavior is specific to Cerulean, Amethyst, and Sunrise I would suspect it is actually related to https://github.com/mozilla-mobile/fenix/issues/26424 and may be resolved by https://github.com/mozilla-mobile/fenix/pull/27137
It did, yes. And I can at least confirm that it fixed the problem for me.
Managed to reproduce the issue using the steps from Matthew's comment. Verified as fixed on the latest Nightly 107.0a1 (2022-09-27T17:58:10.729379). Closing the ticket as fixed.
After further research, I found out that this issue could still be reproduced with specific wallpapers selected before the update is made. I therefore reopen the ticket for re-verification.
The latest nightly should address those issues, please let me know if you're still seeing them.
@MatthewTighe , @Alexandru2909 , I re-tested this on Nightly 107.0a1 from 09/29 with Google Pixel 6 (Android 13) and Xiaomi 12 Pro (Android 12). Note that although https://github.com/mozilla-mobile/fenix/issues/26424 is now fixed and all wallpapers are correctly displayed on homepage after updating from an old build to the latest Fenix version, the "Couldn't change wallpaper" snackbar is still displayed one time on homepage, right after dismissing the onboarding card for the Cerulean, Amethyst, Sunrise wallpapers.
https://user-images.githubusercontent.com/89388888/193014439-e7a52d85-57a4-4e06-9d84-1ce2ac0362f6.mp4
@delia-pop Is the snackbar only displayed one time, and only for users upgrading with those 3 wallpapers? Or is it displayed every time the app is launched?
If the first case, that might still warrant some investigation but is probably an acceptable but at this point in the release process.
If the second case, it would be good to continue to try and fully resolve the issue
It makes sense for the snackbar to be displayed only for Cerulean, Amethyst and Sunrise wallpapers, as they are the only ones which are downloaded and not migrated (because in the legacy code they are only available as drawables).
We could handle this special case by loading the wallpaper using the legacy code if the previously set wallpaper is any of these on the first run after the update.
Is the snackbar only displayed one time, and only for users upgrading with those 3 wallpapers?
Yes, the snackbar is only displayed once and only with those 3 wallpapers, after updating the app and dismissing the welcome cards. Next restarts or launches will not trigger the snackbar.
This issue is not reproducible on Beta 106.0b3 with Lenovo Yoga Tab 11 (Android 11). After update, the error snackbar is not displayed once the onboarding card is dismissed.
It makes sense for the snackbar to be displayed only for Cerulean, Amethyst and Sunrise wallpapers, as they are the only ones which are downloaded and not migrated (because in the legacy code they are only available as drawables).
We could handle this special case by loading the wallpaper using the legacy code if the previously set wallpaper is any of these on the first run after the update.
I think we could look into a patch for the behavior for 107, but this seems small enough to allow for 106 given where we are in the release cycle and the amount of churn we've had. I would guess that the subset of users it is likely to effect will correctly chalk it up to some small bug and forget about it when it does not happen again. I'm also hesitant to introduce any migration-specific code to anywhere except the WallpaperUseCases (like the HomeFragment), but would be interested in a patch that worked within those constraints.
Hello! Sorry for the delay, but Delia was in sick leave all week and we missed this issue. I think it is ok to fix what it is left in 107. Verified on Beta 106.0b5 with OnePlus 9 Pro (Android 12).
Although this issue is not encountered in Beta 106, it is still reproducible on the Nightly branch, when updating to the latest version from an older Fenix build, as stated above. I will leave this ticket re-opened and the "qa:needed" label until further notice, to be re-checked or closed in the next cycle as Matt said.
Since this bug will only be hit once for upgrading users and we weren't able to address it in time for 106, I think we are safe to close this issue. Users that have the bug should hit it during the 106 release, so there is not much reason to introduce code to handle the edge case for 107.