[Settings] Settings->Display does not display current wallpaper when app is first launched

RESOLVED FIXED in Firefox OS v2.1

Status

Firefox OS
Gaia::Settings
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: djf, Assigned: arthurcc)

Tracking

({regression})

unspecified
2.1 S1 (1aug)
x86
Mac OS X
regression

Firefox Tracking Flags

(b2g-v1.4 unaffected, b2g-v2.0 unaffected, b2g-v2.1 verified)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
STR:

1) Launch settings app
2) Tap "Display"
3) Note that there is a white rectangle where the current wallpaper should be displayed.

If I change the wallpaper from settings or from the homescreen while the settings app is running, then the new wallpaper is correctly displayed. So the app is correctly detecting changes to the wallpaper.  But it is not displaying the wallpaper that is in effect when it is first launched.

I assume this bug has something to do with the refactor that started using Observable here.
(Reporter)

Comment 1

4 years ago
George and John: both of you have modified apps/settings/js/panels/display/wallpaper.js recently. Do one of you want to take this bug?

Setting qawanted to see if this reproduces in 2.0
Flags: needinfo?(jlu)
Flags: needinfo?(gduan.moz)
Keywords: qawanted
Issue does NOT repro on 2.0 Flame and 2.1 Flame

Actual Results: The wallpaper is properly shown in the Settings>Display screen


Device: Flame 2.0
Build ID: 20140725000201
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame Master
Build ID: 20140725034810
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
Hi David,

We were unable to reproduce the issue, are there additional steps or other pre-requisites?  What build were you on when you saw the issue?

Thanks!
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(dflanagan)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(Reporter)

Comment 4

4 years ago
I'm using today's gaia master and a gecko from 7/18 (because auto_flash_from_pvt.sh still has not been updated for the new gecko 34 builds)  This is on a 512mb Flame.

This seems to be intermittent. New STR:

1) launch settings app
2) tap Display and check whether the wallpaper is shown or whether it is a white rectangle.
3) long press on home and swipe up to kill the settings app
4) Go to step 1

About 50% of the time I see a white rectangle instead of wallpaper, indicating a race condition in the settings app.

Peter: can you reproduce it with those steps?
Flags: needinfo?(dflanagan) → needinfo?(pbylenga)
(Reporter)

Comment 5

4 years ago
I updated my gecko with so I now have a completely up to date phone. After first boot, the wallpaper always displays correctly in the settings app (at least 4 times out of 4). But then if I change the wallpaper (by long pressing on the homescreen) then I can see the bug again. It is still intermittent. I think I'm seeing it about 25% of the time with this new build.
I can reproduce on 2.1 Master (512MB and 319MB) with the STRs in Comment 4 (a bit more than 50% repro rate).

I can only reproduce on 2.0 with 319MB

Environmental Variables:
Device: Flame Master
Build ID: 20140730040205
Gaia: 25e998814ba89f30fe44cd2fdfbb44d160a04641
Gecko: 55c4d770f88b
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140730000206
Gaia: 2e85678de2c8e13e585288d4cec7d6673cee17ee
Gecko: 6e37ecf873da
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga) → needinfo?(jmitchell)
(Reporter)

Comment 7

4 years ago
I'm actually quite surprised that this reproduced in 2.0 since there have been big changes to the wallpaper.js file in the settings app on master.  That file used to explicitly display the wallpaper when it started up. Now, it just sets a property on itself and uses an Observable pattern, relying on some other part of the app to observe the change.  There is presumably a timing issue where the change is sometimes not being observed and the wallpaper is not being displayed.

Setting needinfo for Arthur since he is an owner for the app and presumably knows about this recent refactor.  I worry that the same kind of intermittent bugs might be occurring elsewhere in the app.
Flags: needinfo?(arthur.chen)
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
We should initialize the wallpaper src when displaying the panel. I believe this is just an individual case.
Assignee: nobody → arthur.chen
Flags: needinfo?(arthur.chen)
Flags: needinfo?(jlu)
Created attachment 8465194 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/22333

Add the missing line to initialize the source. Unit tests are added.

EJ, could you help review this patch? Thanks.
Attachment #8465194 - Flags: review?(ejchen)
Flags: needinfo?(gduan.moz)
Comment on attachment 8465194 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/22333

r+ with one nit, thanks Arthur !
Attachment #8465194 - Flags: review?(ejchen) → review+
Thanks for reviewing, EJ.

master: ab8f1ebcc9d4636af7cbb39018a3cc98150ef928
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
[Blocking Requested - why for this release]: Users are not able to see the current wallpaper in settings app.
blocking-b2g: --- → 2.0?
QA Wanted to check if the updated STR reproduces on 1.4.
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Keywords: qawanted
QA Contact: rkuhlman
The wallpaper always displays properly in v1.4. I do see the blank white screen for about 0.5 seconds before the wallpaper is loaded and displayed. Unable to reproduce on v1.4

v1.4 Environmental Variables:
Device: Flame v1.4
BuildID: 20140805000237
Gaia: 9377274b17200a60cebcd2427d489a7756c4cc72
Gecko: 24bc2ae19c59
Version: 30.0
Firmware Version: v122
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qawanted

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+
Keywords: regression
Needs rebasing for v2.0 uplift.
status-b2g-v2.1: affected → fixed
Flags: needinfo?(arthur.chen)
Keywords: branch-patch-needed
When rebasing, I just realized that the refactor work of the display panel did not land to v2.0. Meanwhile, I am able to reproduce the white screen on v1.4 and v2.0 but not as the original description which said that the wallpaper is not loaded until it is changed. So I am going to clear the blocking flag for 2.0, sorry for the noise.

Device: Flame v1.4
Gaia      e9dce1f60f729e228810f751417681b5ff937b6b
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/89a8a24a8b1b
BuildID   20140806160243
Version   30.0

Device: Flame v2.0
Gaia      47fa0ba8197e71cc7034943ff037642e7f35cdfe
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/641b3758537b
BuildID   20140806160249
Version   32.0
blocking-b2g: 2.0+ → ---
status-b2g-v2.0: affected → unaffected
Flags: needinfo?(arthur.chen)
Keywords: branch-patch-needed
Target Milestone: --- → 2.1 S1 (1aug)

Updated

3 years ago
status-b2g-v2.1: fixed → verified

Comment 17

3 years ago
Created attachment 8529483 [details]
VIDEO0055.mp4

This issue has been successfully verified on Flame 2.1:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
You need to log in before you can comment on or make changes to this bug.