The homescreen app icons are missing including the bottom four apps which results in limited functionality for the user after rebooting the device in the landscape position. The remaining functionality is swiping the Notifications menu down, and the Power button options like locking the device, restarting, and powering off. Repro Steps: 1) Updated Buri to BuildID: 20131101004000 2) Hold the device in landscape position and restart the device. 3) Keep holding the device in landscape until the lockscreen or homescreen appears. 4) Unlock the device and verify the missing homescreen apps. Actual: Homescreen apps are missing. Expected: Device would reboot properly and user would have regular experience. Environmental Variables: Device: Buri v 1.2 Moz RIL BuildID: 20131101004000 Gaia: e717aec947571f5daf923c040a82f9f0719bb526 Gecko: 54de309e18a9 Version: 26.0 Firmware Version: 20131015 Repro frequency: 100% See attached: Logcats and Screenshot Optional Workaround: You can fix the problem by holding the device in Portrait position and restarting it.

This issue does not reproduce on 1.1. User is able to restart the device in Landscape properly and has all the apps on the homescreen and functionality. Device: Leo v 1.1 Moz RIL BuildID: 20131030041204 Gaia: 39b0203fa9809052c8c4d4332fef03bbaf0426fc Gecko: 41c15ddb7216 Version: 18.0 Firmware Version: V10c

Regression range: -last working- Buri BuildID: 20131026004003 Gaia: de70f4d9b7a8dd3ba2565184735094eaa2bd3d18 Gecko: 780de7966fc0 Version: 26.0a2 Firmware: 20131015 -first broken- Buri BuildID: 20131027004003 Gaia: 04ee9e4430b25ba2c38752d3897f0ee5e2a6ab80 Gecko: 52f24889dccc Version: 26.0a2 Firmware: 20131015

NI on tim C to help with an assignee here.

Similar bug fixed in bug 934906 but it seems a tablet specific patch. I'd suggest backout bug 908601 & bug 911668 ("orientation": "default") in 1.2, since they are originally prepared for support tablet default layout, which is not based on 1.2 anymore. Or we have to uplift several bug 908601 followup bugs to 1.2 to fix the related issues. Alive, any thought?

https://github.com/mozilla-b2g/gaia/commit/52703aec82e8e8a89a82a31da6ddb8a9b9680333 is already in 1.2 I don't know what you are talking about.

Please refer Bug 936355 In Bug 908601 , some code was added in window.js var isDefaultPortrait = (ScreenLayout.defaultOrientation === 'portrait-primary'); var OrientationRotationArray = [ 'portrait-primary', 'portrait-secondary', 'portrait', 'landscape-primary', 'landscape-secondary', 'landscape', 'default']; var OrientationRotationTable = { 'portrait-primary': [0, 180, 0, 90, 270, 90, isDefaultPortrait ? 0 : 90], 'landscape-primary': [270, 90, 270, 0, 180, 0, isDefaultPortrait ? 0 : 270] }; AppWindow.prototype.determineRotationDegree = function aw__determineRotationDegree() { if (!this.manifest) return 0; var appOrientation = this.manifest.orientation; var orientation = this.determineOrientation(appOrientation); //ScreenLayout.defaultOrientation may have other values that not handled in OrientationRotationTable. and cause table == null var table = OrientationRotationTable[ScreenLayout.defaultOrientation]; //here, because table == null, the code was broken. var degree = table[OrientationRotationArray.indexOf(orientation)]; this.rotatingDegree = degree; if (degree == 90 || degree == 270) { this.frame.classList.add('perpendicular'); } return degree; };

Thanks for pointing out. IMO ScreenLayout.defaultOrientation shouldn't be null but only be "portrait-primary" or "landscape-primary" If we don't get these two values then there may be a gecko issue. It doesn't report correct orientation. (In reply to ying.xu from comment #9) > Please refer Bug 936355 > > In Bug 908601 , some code was added in window.js > > var isDefaultPortrait = > (ScreenLayout.defaultOrientation === 'portrait-primary'); > > var OrientationRotationArray = [ > 'portrait-primary', 'portrait-secondary', 'portrait', > 'landscape-primary', 'landscape-secondary', 'landscape', 'default']; > var OrientationRotationTable = { > 'portrait-primary': [0, 180, 0, 90, 270, 90, isDefaultPortrait ? 0 : 90], > 'landscape-primary': [270, 90, 270, 0, 180, 0, isDefaultPortrait ? 0 : > 270] > }; > > AppWindow.prototype.determineRotationDegree = > function aw__determineRotationDegree() { > if (!this.manifest) > return 0; > > var appOrientation = this.manifest.orientation; > var orientation = this.determineOrientation(appOrientation); > > //ScreenLayout.defaultOrientation may have other values that not handled in > OrientationRotationTable. and cause table == null > > var table = OrientationRotationTable[ScreenLayout.defaultOrientation]; > > //here, because table == null, the code was broken. > > var degree = table[OrientationRotationArray.indexOf(orientation)]; > this.rotatingDegree = degree; > if (degree == 90 || degree == 270) { > this.frame.classList.add('perpendicular'); > } > return degree; > };

all the values defined in nsScreen.cpp, so there are also two other values. void nsScreen::GetMozOrientation(nsString& aOrientation) { switch (mOrientation) { case eScreenOrientation_PortraitPrimary: aOrientation.AssignLiteral("portrait-primary"); break; case eScreenOrientation_PortraitSecondary: aOrientation.AssignLiteral("portrait-secondary"); break; case eScreenOrientation_LandscapePrimary: aOrientation.AssignLiteral("landscape-primary"); break; case eScreenOrientation_LandscapeSecondary: aOrientation.AssignLiteral("landscape-secondary"); break; case eScreenOrientation_None: default: MOZ_CRASH("Unacceptable mOrientation value"); } } (In reply to Alive Kuo [:alive][NEEDINFO] from comment #10) > Thanks for pointing out. > IMO ScreenLayout.defaultOrientation shouldn't be null but only be > "portrait-primary" or "landscape-primary" > If we don't get these two values then there may be a gecko issue. It doesn't > report correct orientation. > > (In reply to ying.xu from comment #9) > > Please refer Bug 936355 > > > > In Bug 908601 , some code was added in window.js > > > > var isDefaultPortrait = > > (ScreenLayout.defaultOrientation === 'portrait-primary'); > > > > var OrientationRotationArray = [ > > 'portrait-primary', 'portrait-secondary', 'portrait', > > 'landscape-primary', 'landscape-secondary', 'landscape', 'default']; > > var OrientationRotationTable = { > > 'portrait-primary': [0, 180, 0, 90, 270, 90, isDefaultPortrait ? 0 : 90], > > 'landscape-primary': [270, 90, 270, 0, 180, 0, isDefaultPortrait ? 0 : > > 270] > > }; > > > > AppWindow.prototype.determineRotationDegree = > > function aw__determineRotationDegree() { > > if (!this.manifest) > > return 0; > > > > var appOrientation = this.manifest.orientation; > > var orientation = this.determineOrientation(appOrientation); > > > > //ScreenLayout.defaultOrientation may have other values that not handled in > > OrientationRotationTable. and cause table == null > > > > var table = OrientationRotationTable[ScreenLayout.defaultOrientation]; > > > > //here, because table == null, the code was broken. > > > > var degree = table[OrientationRotationArray.indexOf(orientation)]; > > this.rotatingDegree = degree; > > if (degree == 90 || degree == 270) { > > this.frame.classList.add('perpendicular'); > > } > > return degree; > > };

I know there're four kind of values for mozOrientation, but it should be primary before we do any call to lockOrientation. It shouldn't be secondary before we lock the screen. Viral?

(In reply to Fred Lin [:gasolin] from comment #7) > Similar bug fixed in bug 934906 but it seems a tablet specific patch. > > > I'd suggest backout bug 908601 & bug 911668 ("orientation": "default") in > 1.2, since they are originally prepared for support tablet default layout, > which is not based on 1.2 anymore. > > Or we have to uplift several bug 908601 followup bugs to 1.2 to fix the > related issues. > > Alive, any thought? Please back out them in 1.2 only and find out what's followup if necessary, but I wonder why we have the problem comment 9 addressed.

Fred is working on this bug.

Track it under my team.

Hi Alive, As our offline discussion, when device just boot up before any apps lock orientation, gecko will report the currently orientation when you use screen.mozOrientation. So it could be landscape-secondary. My suggestion here is to lock orientation in default and get orientation, it should be default orientation.

Nikolai, before backout bug 908601 & bug 911668 in 1.2, Can you help confirm if this issue appears in master (I can't reproduce it in master), so we can nail down the cause. Thanks

QA Wanted for comment 17

On the Buri v1.3 2013-11-12 build, after restarting the device in landscape position, the apps did not disappear, but they were locked. I couldn't click on them to enter any app. I was able to long-press to delete them, e.me search bar worked, and long-pressing the home button to get the Recent Apps page worked. For e.me, the first time I tried to use it I was able to click on the premade icons (Social, Games, Music, Entertainment) to get the list of apps in that category. I was not able to enter the apps, only long-press on them to add them to the homescreen. I still could not enter them once they were added to the homescreen. I was able to access all of the apps after restarting the device in portrait position. Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131112040207 Gaia: a013d01d3a0ddee76f60e61f8306d280c10aafbf Gecko: 581d180a37f3 Version: 28.0a1 Firmware Version: 20131104

backout bug 908601 & bug 911668 in v1.2 https://github.com/mozilla-b2g/gaia/commit/3259ac8a9813740ffc43a5e4fdff8e4a024a56c8 add followup bug 938951 based on Comment 19 for issue happens in master