1209487 - [New-Homescreen] Sometimes the rocket-bar becomes collapsible

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Chris Lord [:cwiiis]]

I've not been able to find consistent steps to reproduce, but under some conditions, the rocketbar on the homescreen becomes collapsible. This is an error, it should always be expanded, and this is done by making sure overflow on the body element is hidden and it never exceeds the size of the viewport.

I don't know whether this is a bug in system (incorrectly collapsing the rocketbar) or in homescreen (letting the body exceed the size of the viewport), so filing under homescreen for now.

If anyone finds reliable steps to reproduce, please let me know.

Comment 1

[Teri Wen [:twen]]

I noticed this too when I opened bug 1202998, and I just recreated it on the latest master using the steps below.

[Repro Steps]:
Prereq: apply the new home screen
1. Install youtube from marketplace
2. Tap to open the game, SWOOP and wait until it finishes loading
3. Tap homescreen button
4. Scroll to the top and scroll to the bottom


Build ID               20151004181256
Gaia Revision          f3d9981dccfa4dfdfcb865d95fdcfb85e4077e1e
Gaia Date              2015-10-02 13:52:20
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3d7532ce81ac571962abc3b99582fe7f5d685192
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151004.173222
Firmware Date          Sun Oct  4 17:32:29 UTC 2015
Bootloader             s1

Comment 2

[Chris Lord [:cwiiis]]

I can reproduce by running SWOOP - I'm guessing something about full-screen landscape apps (or just landscape apps?) causes the homescreen to get resized in a way that triggers the collapsible rocketbar? I'm going to look into this.

Comment 3

[Chris Lord [:cwiiis]]

So when Swoop forces the orientation change, it appears the scroll-area-changed signal also gets sent to all the background apps (well, at least homescreen anyway), but the container element only updates for the foreground app.

Still going and thinking of the best way to deal with it. Possibly we ignore scroll-area-changed if the app isn't foreground, then call the signal handler manually when the app becomes visible. That'd probably fix it...

Comment 4

[GitHub Autolander Bot]

Attachment: [gaia] Cwiiis:bug1209487-incorrect-rocketbar-collapsed > mozilla-b2g:master

Comment 5

[Chris Lord [:cwiiis]]

Comment on attachment 8671964 [details] [review]
[gaia] Cwiiis:bug1209487-incorrect-rocketbar-collapsed > mozilla-b2g:master

This stops us from responding to scroll-area-changed while not visible. This fixes the rocketbar incorrectly collapsing in the case of the foreground app changing the orientation of the device (this would cause background browser elements to change size, but not their container elements - leading to them all becoming scrollable).

I also changed the comparison from >= to > because I was seeing some false positives caused by that when you background a fullscreen app.

Comment 6

[Etienne Segonzac (:etienne)]

Comment on attachment 8671964 [details] [review]
[gaia] Cwiiis:bug1209487-incorrect-rocketbar-collapsed > mozilla-b2g:master

The change makes perfect sense, but it's a change to code than never got any testing love :/

r=me with a couple of unit tests dispatching |mozbrowserscrollareachanged| events and asserting on the presence (or not) of the |scrollable| class. Thanks!

(Of course if you'd rather add integration tests serving up web pages with different scroll areas and changing them while in the background that'd work for me too ;))

Comment 7

[Chris Lord [:cwiiis]]

Unit tests added, confirmed on IRC - merged: https://github.com/mozilla-b2g/gaia/commit/8b79556de1e0d602650b985a2b0af9c86b528c05