When the phone first booted, home screen is launched with visibility set to true

RESOLVED DUPLICATE of bug 985037

Status

defect
RESOLVED DUPLICATE of bug 985037
6 years ago
5 years ago

People

(Reporter: timdream, Assigned: cedric)

Tracking

unspecified
x86
macOS
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-)

Details

(Whiteboard: [FT:System-Platform][good first bug][mentor=alive][mentor-lang=zh][lang=js][device-required])

Attachments

(1 attachment)

STR:

1. Go to lockscreen.css, change |opacity: 1| to |opacity: 0.5| so we could see through it.
2. |make install-gaia|

Expected:
1. Home screen is loaded and rendered behind lock screen.

Actual:
1. Home screen is loaded but not rendered.

Note:
1. as soon as you turn off the screen and turn it on again, the visibility is correctly set to false.
2. Probably a regression from HomescreenLauncher, alive?

Blocking:
Maybe this has memory management implication? I won't be very worry though but I am not sure.
Flags: needinfo?(alive)
BTW, I have no idea if home screen is set to active or not when the phone is launched with FTU. I tried to observe nice level from shell but I failed to find the right command.
On a second thought, this is probably not a regression because I don't think the original bootstrap.js launches homescreen in background...
Keywords: regression
It's hard to say this is regressed or not because we had a weird bootstrap process before...
Bootstrap did something shall be done by AppWindowManager.

Leave this opened at first.
Flags: needinfo?(alive)
Sorry, it looks like I messed up "Expected" and "Actual" in comment 0.

Actual:
1. Home screen is loaded and rendered behind lock screen.

Expected:
1. Home screen is loaded but not rendered.
Not a regression & not an end-user use case, as this requires modifying the Gaia code directly. Not a blocker.
blocking-b2g: koi? → -
Alive, should this block bug 902766 and planned accordingly?
Flags: needinfo?(alive)
Whiteboard: [FT:System-Platform][good first bug][mentor=alive][mentor-lang=zh] → [FT:System-Platform][good first bug][mentor=alive][mentor-lang=zh][lang=js]
As you wish
Flags: needinfo?(alive)
Is this a device-required good-first-bug? Want to tag it at the whiteboard if it is.
Flags: needinfo?(timdream)
(In reply to Greg Weng [:snowmantw] from comment #8)
> Is this a device-required good-first-bug? Want to tag it at the whiteboard
> if it is.

The visual difference can only be observed on the device (and maybe emulator) as we only remove render of oop frames there.e
Flags: needinfo?(timdream)
Okay. I will add a tag. If the name tag name is improper, please correct it for me.
Whiteboard: [FT:System-Platform][good first bug][mentor=alive][mentor-lang=zh][lang=js] → [FT:System-Platform][good first bug][mentor=alive][mentor-lang=zh][lang=js][device-required]
I am interested in this. It seems like a good first bug for me.

Can you give me some starting locations to scout out and find out the issue? Where is the lockscreen and homescreen set up initially on first boot?

Also I already set up my Keon, and have a build up and running on it.
Asking feedback about way of solving bug.
Attachment #8385433 - Flags: feedback?(alive)
Assignee: nobody → cedric
Comment on attachment 8385433 [details]
Draft commit fixing bug

The idea fix to me is when homescreen window is instantiated, do close it in homescreen launcher or do setVisible(false) after the mozbrowser element is rendered to the DOM tree.
Attachment #8385433 - Flags: feedback?(alive) → feedback-
Hm, do you mean homescreenrendered event?
If I setVisible(false) when homescreenrendered event is fired, the homescreen will be setVisible(true) AFTER, when homescreenopening event is fired (stack trace given in the end of comment).

Note: strangely enough, when switching to the bubble-tea branch, “homescreenopening” is fired AFTER “homescreenopened”, making this discussion complicated. If you have a clue, I take it. :)


BTW, Is a new "homescreen" marionnette test okay and enough for this bug?


aw_setVisible@http://system.gaiamobile.org:8080/js/app_window.js:214:1
atc_handle_opening@http://system.gaiamobile.org:8080/js/app_transition_controller.js:207:7
atc_handleEvent@http://system.gaiamobile.org:8080/js/app_transition_controller.js:311:11
aw_broadcast@http://system.gaiamobile.org:8080/js/app_window.js:962:7
AppWindow.prototype.publish@http://system.gaiamobile.org:8080/js/app_window.js:939:5
atc_changeTransitionState@http://system.gaiamobile.org:8080/js/app_transition_controller.js:98:7
AppTransitionController.prototype.requireOpen@http://system.gaiamobile.org:8080/js/app_transition_controller.js:266:5
aw_open@http://system.gaiamobile.org:8080/js/app_window.js:1411:7
awm_switchApp/<@http://system.gaiamobile.org:8080/js/app_window_manager.js:176:1
Alive, are you still mentoring?
Flags: needinfo?(alive)
This bug should already be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=985037
Sorry for that.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(alive)
Resolution: --- → DUPLICATE
Duplicate of bug: 985037
You need to log in before you can comment on or make changes to this bug.