Closed Bug 1097359 Opened 10 years ago Closed 10 years ago

[Window Management]With the software home button option enabled, the button will get pushed out of place and the icons in the notifications bar will overlap when the user selects on the cookies link

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 unaffected)

VERIFIED FIXED
2.1 S9 (21Nov)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- unaffected

People

(Reporter: cnelson, Assigned: gduan)

References

()

Details

(Whiteboard: [2.1-Exploratory-3][systemsfe])

Attachments

(2 files)

Attached file log.txt
Selecting the cookies link will cause the software home button to get pushed out of place, and the notification bar icons to become overlapped with the rocket bar.  The user must enable the software home button in order to reproduce this issue.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141111001201
2) Open the settings app, and go into the developer menu.
3) Turn on software home button, and then open the device information menu.
4) Select the credits option, and scroll down and select the Mozilla projects link.
5) Scroll to the bottom of the page, and select the cookies link.
6) Notice the software home button will get pushed out of place.
  
Actual:
Software home button becomes pushed out of place when selecting the cookies link
  
Expected: 
The software home button doesn't become pushed out of place.
  
Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141111001201
Gaia: 7154f9aa0a69af56c8bd89be0c98d9791449527b
Gecko: 452db1a0c9a0
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 100%
See attached: logcat, video clip https://www.youtube.com/watch?v=LJBHY9g9JR0
Flags: needinfo?(dharris)
This issue does not occur Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash).

The software home button doesn't become pushed out of place.
  
Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141111040202
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: 76b85b90a8cb
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
[Blocking Requested - why for this release]:

This bug can occur without SHB enabled, and causes the status bar overlap everything on the homescreen, as well as cause part of the homescreen to be blank at the bottom. Nominating to block 2.1
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Whiteboard: [2.1-Exploratory-3][shb-enabled] → [2.1-Exploratory-3]
blocking-b2g: 2.1? → 2.1+
Whiteboard: [2.1-Exploratory-3] → [2.1-Exploratory-3][systemsfe]
Can we get a reverse regression-window?
Alberto, this looks like a fun one. Wanna take a shot?
Flags: needinfo?(apastor)
Assignee: nobody → apastor
Flags: needinfo?(apastor)
After bisecting 2.1, it seems that the 2.1 patch in bug 1082864 is causing this bug.

Reverting https://github.com/mozilla-b2g/gaia/commit/23fb3d2dae7dc6e27cf18e9b178569c9292cf274 fixes the problem.
Note that the rocketbar doesn't work properly (it doesn't get hidden when scrolling) when this bug occurs.

George, any idea? Thanks!
Flags: needinfo?(gduan)
it seems like comment 5 satisfies both a regression-window and the reverse regression window request from comment 3. (removing tag). What is identified as the 'fix' is more accurately described as why 2.2 is not affected. Even though the patch from bug 1082864 is marked 2.2 fixed in the tracking flags it looks like it was never landed to 2.2, so this bug is not seen there.
Bug 1066607 is about to be uplifted to v2.1, perhaps it could fix this?
I just checked it, with Bug 1066607 already uplifted in v2.1, and I can confirm that it does *not* fix the problem :(
Target Milestone: --- → 2.1 S9 (21Nov)
:alive, as you reviewed 1082864 patch, you might have some clues? Thanks!
Flags: needinfo?(alive)
No idea what's wrong, but I think George will take a look.
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #10)
> No idea what's wrong, but I think George will take a look.

Assigning to George based on comment 10.
Assignee: apastor → gduan
I found the scrollTop of #screen is 30px when the bug happened. I'm still investigating.
Flags: needinfo?(gduan)
Chris: we found that the scrollTop of system app's #screen element will be changed once the link of 'Cookies' in https://www.mozilla.org/en-US/about/legal/ is clicked. This sounds to me a scrollgrab issue, do you have any idea?
Flags: needinfo?(chrislord.net)
Can you verify that the frame is OOP? There was a bug, but I thought we had fixed this by uplifting some recent changes to browser.js.

Also scrollgrab should not impact the #screen element as it's just the browser container per app window.
Attached file PR to v2.1
I have no idea why the scrolling effect may effect #screen, but it seems fine with master's code. (waiting for test.
Comment on attachment 8525262 [details] [review]
PR to v2.1

I guess this is to v2.1. Argh - it seems that this could have still be doing in-process frames, which could be causing lots of problems =/
Attachment #8525262 - Attachment description: PR to master → PR to v2.1
Flags: needinfo?(chrislord.net)
(For reference, scrollgrab is only implemented in apz, so it doesn't work with sync scrolling)
Comment on attachment 8525262 [details] [review]
PR to v2.1

Hi Kevin,
could you review this patch? Just like what you mentioned comment 14, my previous patch doesn't set the appWindow's oop to true, because app_window_factory would reset the config data. Perhaps we can just use the same code from master.
Attachment #8525262 - Flags: review?(kevingrandon)
Comment on attachment 8525262 [details] [review]
PR to v2.1

Looks good to me, thanks!
Attachment #8525262 - Flags: review?(kevingrandon) → review+
Comment on attachment 8525262 [details] [review]
PR to v2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 1082864
[User impact] if declined: See comment 0, unexpected gap between app and SHB
[Testing completed]: Yes, same as master branch.
[Risk to taking this patch] (and alternatives if risky): No.
[String changes made]:
Attachment #8525262 - Flags: approval-gaia-v2.1?
Keywords: verifyme
Attachment #8525262 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Merged to 2.1: https://github.com/mozilla-b2g/gaia/commit/0b8002b6a78ac33d040518b475eb26fe5823b2cb
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified the issue is fixed on 2.1 Flame

The "Software Home button" is not shifted when opening the "cookies" option

Device: Flame 2.1
BuildID: 20141124001201
Gaia: f93f2b92c7410815b785f6d8b286593d703a65d9
Gecko: 1de2c2a21068
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: