Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Description • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 1 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 2 • 11 years ago

On a second thought, this is probably not a regression because I don't think the original bootstrap.js launches homescreen in background...

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 3 • 11 years ago

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.

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 4 • 11 years ago

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.

	Jason Smith [:jsmith]
	Comment 5 • 11 years ago

Not a regression & not an end-user use case, as this requires modifying the Gaia code directly. Not a blocker.

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 6 • 11 years ago

Alive, should this block bug 902766 and planned accordingly?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 7 • 11 years ago

As you wish

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 8 • 11 years ago

Is this a device-required good-first-bug? Want to tag it at the whiteboard if it is.

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 9 • 11 years ago

(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

	Greg Weng [:snowmantw][:gweng][:λ]
	Comment 10 • 11 years ago

Okay. I will add a tag. If the name tag name is improper, please correct it for me.

	Robert Gawdzik
	Comment 11 • 11 years ago

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.

	Cédric de Saint Martin Assignee
	Comment 12 • 11 years ago

Asking feedback about way of solving bug.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 13 • 11 years ago

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.

	Cédric de Saint Martin Assignee
	Comment 14 • 11 years ago

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

	Tim Guan-tin Chien [:timdream] (please needinfo) Reporter
	Comment 15 • 10 years ago

Alive, are you still mentoring?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 16 • 10 years ago

This bug should already be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=985037
Sorry for that.