Closed Bug 1095805 Opened 7 years ago Closed 7 years ago

[System] With Software Home button on, when a crash occurs the Mozilla crash report screen is cut off where the buttons are located

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

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

People

(Reporter: jlee, Assigned: kgrandon)

Details

(Keywords: regression, Whiteboard: [systemsfe][2.1-exploratory-3] [shb-enabled])

Attachments

(5 files)

Mozilla crash report screen is slightly cut off where buttons are located when Software Home button is enabled. 
   
Repro Steps:
1) Update a Flame device to BuildID: 20141107001205
2) Go to Settings > Device Information > More Information
3) Turn on Developer Menu
4) Go to Developer Menu > turn on Software Home button
5) Cause crash on device. Crash is necessary to see issue.
In terminal with device connected to comp with USB enabled, type: adb shell b2g-ps (then enter)
adb shell kill -11 [enter correct PID here without brackets] (then enter)
6) Observe crash report screen

  
Actual: 
With Software Home button enabled, when a crash occurs that causes Crash Reports screen to appear, the crash report is seen slightly cut off where the buttons are located.

Expected: 
With Software Home button enabled, when a crash occurs that causes Crash Reports screen to appear, the crash report is seen fully and buttons are not cut off.
  

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141107001205
Gaia: 6295f6acfe91c6ae659712747dd2b9c8f51d0339
Gecko: 8c23b4f2ba29
Gonk: 
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
  
Repro frequency: 100% after a crash
See attached: screenshot (SoftwareHome_CrashReport.png)
Issue is also seen on 2.2.

With Software Home button enabled, when a crash occurs that causes Crash Reports screen to appear, the crash report is seen slightly cut off where the buttons are located.

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141107040206
Gaia: 779f05fead3d009f6e7fe713ad0fea16b6f2fb31
Gecko: 64f4392d0bdc
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Issue does not occur on 2.0.

With Software Home button enabled, when a crash occurs that causes Crash Reports screen to appear, the crash report is seen fully and buttons are not cut off.

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash
BuildID: 20141107000206
Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3
Gecko: 9836e9d81357
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3] [shb-enabled]
Keywords: regression
[Blocking Requested - why for this release]: regression, poor UX / looks bad
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Moving severity to normal. If the buttons are still functional, I am not sure I would block on this issue.
Severity: critical → normal
Looking at this.
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Whiteboard: [2.1-exploratory-3] [shb-enabled] → [systemsfe][2.1-exploratory-3] [shb-enabled]
Target Milestone: --- → 2.1 S9 (21Nov)
Comment on attachment 8519781 [details] [review]
[PullReq] KevinGrandon:bug_1095805_shb_crash_dialog to mozilla-b2g:master

Mike - think you could review this one?
Attachment #8519781 - Flags: review?(mhenretty)
I'll clear the regression window request to save you guys some time. Shouldn't be needed now that we have a patch here.
Broken feature.
blocking-b2g: 2.1? → 2.1+
Comment on attachment 8519781 [details] [review]
[PullReq] KevinGrandon:bug_1095805_shb_crash_dialog to mozilla-b2g:master

This seems like a reasonable solution. The one bummer here is that modal_dialog.js adds an inline style height to #dialog-overlay, which will override the css bottom property in this patch. I couldn't find a way to break it though, and I hear we are moving modal_dialogs out of #dialog-overlay in favor of the app window soon, so your solution seems like the correct way going forward.

I remember specifically verifying the crash dialog several weeks ago too, so I'm interested in what broke it. But I'm ok with just fixing it and moving on.
Attachment #8519781 - Flags: review?(mhenretty) → review+
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Attachment #8519781 - Flags: review+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
There was an error creating the taskgraph, please try again. If the issue persists please contact someone in #taskcluster.
I want to verify if this works on v2.1 before requesting approval.
Flags: needinfo?(kgrandon)
Comment on attachment 8519781 [details] [review]
[PullReq] KevinGrandon:bug_1095805_shb_crash_dialog to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): SHB feature implementation.
[User impact] if declined: Fairly rare, but poor UX when the crash report dialog appears and SHB is enabled.
[Testing completed]: Manual and marionette test for layout.
[Risk to taking this patch] (and alternatives if risky): Fairly low risk as it's mainly just a few simple style changes.
[String changes made]: None.
Flags: needinfo?(kgrandon)
Attachment #8519781 - Flags: approval-gaia-v2.1?
Attachment #8519781 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This issue still occurs on Flame 2.2.

Result: The crash report screen is cut off at the bottom with SHB enabled.

Device: Flame 2.2 (319mb, KK, Shallow Flash)
BuildID: 20141113040205
Gaia: be8b0151d2f9a4c41fc63952128e0b723cd1161d
Gecko: ab137ddd3746
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
====================================================

This bug still reproduces on Flame 2.1. Since the patch was uplifted yesterday, I'll try to verify again with tomorrow's nightly build. Leaving verifyme for 2.1.
QA Whiteboard: [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Keywords: verifyme
Flags: needinfo?(ktucker)
This issue still occurs on Flame 2.1.

Result: The crash report screen is cut off at the bottom with SHB enabled.

Device: Flame 2.1 (319mb, KK, Shallow Flash)
BuildID: 20141117001201
Gaia: 81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko: 3572aa3e6766
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Attached image 2014-11-20-13-50-17.png
This issue occurs on Flame 2.1:
Gaia-Rev        1b231b87aad384842dfc79614b2a9ca68a4b4ff3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/95fbd7635152
Build-ID        20141119001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2

Repro Steps:
1) Update a Flame device to BuildID: 20141107001205
2) Go to Settings > Device Information > More Information
3) Turn on Developer Menu
4) Go to Developer Menu > turn on Software Home button
5) Cause crash on device. Crash is necessary to see issue.
In terminal with device connected to comp with USB enabled, type: adb shell b2g-ps (then enter)
adb shell kill -11 [enter correct PID here without brackets] (then enter)
6) Observe crash report screen

Actual: 
With Software Home button enabled, when a crash occurs that causes Crash Reports screen to appear, the crash report is seen slightly cut off where the buttons are located.
log:logcat.txt
happen time:13:50
Picture:2014-11-20-13-50-17.png
Flags: needinfo?(jocheng)
Attached file logcat.txt
This attachment is for comment19.
Hi Kevin,
Could you please help to check again? The problem seems still exist on 2.1 and 2.2. Thanks!
Flags: needinfo?(jocheng) → needinfo?(kgrandon)
Reopening due to comment 21. It appears this issue still occurs *some* of the time, due to the reason in comment 9. Only somtimes the height path from modal_dialog.js is taken, and when we do take it the SHB manager returns a height of 0.
Status: RESOLVED → REOPENED
Flags: needinfo?(kgrandon)
Resolution: FIXED → ---
Here is a handy snippet to execute if you need to reset the state of the dialog: navigator.mozSettings.createLock().set({'crashReporter.dialogShown': false});
(In reply to Kevin Grandon :kgrandon (In Europe/Conf until 11/24) from comment #23)
> Here is a handy snippet to execute if you need to reset the state of the
> dialog: navigator.mozSettings.createLock().set({'crashReporter.dialogShown':
> false});

What is the reproduction rate here? Are we hitting a new issue and file a followup?
(In reply to Gregor Wagner [:gwagner] from comment #24)
> What is the reproduction rate here? Are we hitting a new issue and file a
> followup?

I am not sure. I think the STR QA is doing is slightly different than the fix, so the reproduction rates may be different. I'm trying to verify the repro now and if it's low I'll file a follow-up. Though if the STR from the verification attempt and the original STR are the same, I suppose they should be the same bug.
[Blocking Requested - why for this release]:

Changing this bug from a 2.1+ to a 2.1 nomination for a re-evaluation due to SHB being a lower priority now
blocking-b2g: 2.1+ → 2.1?
Priority doesn't change.
We are supporting SHB with 2.1
blocking-b2g: 2.1? → 2.1+
Sorry, my comment above was wrong, so obsoleting to correct it and not confuse people.

So our understanding about this was a bit wrong. The bug in it's current form appears to only reproduce for devices which have a physical home button. This would not occur on devices which only ship with SHB (tako/nexus4/nexus5).

The resize event is fired when we enable the SHB, but the modal dialog stays the same height. The alternative patch would be to try to resize the modal dialog when showing the crash reporter, but I think that this is the less-risk approach, and can potentially fix more areas at once as well.
Attachment #8526843 - Flags: review?(mhenretty) → review+
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Comment on attachment 8526843 [details] [review]
[PullReq] KevinGrandon:bug_1095805_crash_reporter_dialog_height to mozilla-b2g:master

Add my R+ as well for autolander delegation purposes.
Attachment #8526843 - Flags: review+
Keywords: checkin-needed
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Comment on attachment 8526843 [details] [review]
[PullReq] KevinGrandon:bug_1095805_crash_reporter_dialog_height to mozilla-b2g:master

Oops, old habits die hard - I accidentally uplifted this to v2.1 before requesting approval. I'll request approval now, if it's not granted I'll backout.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): SHB feature implementation (missing).
[User impact] if declined: Relatively rare, requires SHB enabled and a crash, but the dialog UX will be poor when it happens.
[Testing completed]: Manual and simple unit test.
[Risk to taking this patch] (and alternatives if risky): Low risk, basically a ~2 liner which is quite simple.
[String changes made]: None.

Landed in v2.1 here: https://github.com/mozilla-b2g/gaia/commit/befddbb401cad3fd2eb53255aa3a2a4d37ebd740
Attachment #8526843 - Flags: approval-gaia-v2.1?
Keywords: verifyme
Attachment #8526843 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Landed a follow-up for v2.1 specific Gij fixing (testonly): https://github.com/mozilla-b2g/gaia/commit/8ae086c39011bc8842b2a19bb5267906fa22345a
This issue still reproduces on Flame 2.2 and Flame 2.1.

The crash report buttons will be cut off by the software home button, when software home button is enabled during a crash.

Flame 2.2

Device: Flame 2.2  (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141125040209
Gaia: 824a61cccec4c69be9a86ad5cb629a1f61fa142f
Gecko: acde07cb4e4d
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141125001201
Gaia: 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko: db893274d9a6
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(ktucker)
Craig, please check 2.1 again tomorrow.
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage-][failed-verification]
Flags: needinfo?(ktucker) → needinfo?(cnelson)
This issue is verified fixed on Flame 2.1.

The crash report buttons do not become overlapped by the software home button.

Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141126001202
Gaia: db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko: 211eae88f119
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(cnelson)
This issue is verified fixed on Flame 2.2.

Result: The crash report page is displayed properly with SHB enabled.

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141210040201
Gaia: e17c5656dbf517d48fb61ac9bc92119e023fd717
Gecko: be1f49e80d2d
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage-][failed-verification] → [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.