Closed
Bug 1471873
Opened 7 years ago
Closed 7 years ago
[10.14] After Firefox crashes, crash reporter icon shows in dock when "Show Recent Applications" pref is on
Categories
(Toolkit :: Crash Reporting, defect, P2)
Toolkit
Crash Reporting
Tracking
()
VERIFIED
FIXED
mozilla64
People
(Reporter: marcia, Assigned: spohl)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(6 files)
41.97 KB,
image/png
|
Details | |
3.18 KB,
text/plain
|
Details | |
196.44 KB,
image/png
|
Details | |
89.47 KB,
image/png
|
Details | |
62.46 KB,
image/png
|
Details | |
2.10 KB,
patch
|
mstange
:
review+
pascalc
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr60+
|
Details | Diff | Splinter Review |
Seen while running Nightly 20180627120029. After I turned on my machine which was low on power, the crash reporter dialog was present in the dock. I submitted the crash (https://crash-stats.mozilla.com/report/index/6a432b83-6b6b-4ced-9c87-279f00180628), but following that the crash reporter icon stayed in the dock with the attached screenshot.
I was able to remove the crash reporter icon by using the options menu. I will attach the other information that was present in the dialog.
Reporter | ||
Comment 1•7 years ago
|
||
Perhaps this was an odd, one off issue but filing just in case because I am not accustomed to seeing the crash reporter in the dock.
Comment 2•7 years ago
|
||
I managed to bring up the crash reporter dialog with the macOS 10.14 SDK build.
Reporter | ||
Comment 3•7 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #2)
> Created attachment 8992057 [details]
> macOS 10.14 SDK build crash reporter screenshot
>
> I managed to bring up the crash reporter dialog with the macOS 10.14 SDK
> build.
Hello Tim - the crash reporter dialog comes up fine, this bug is about the crash reporter icon that is stuck in the dock following the crash. I just updated the bug summary to make it more clear. It just happened to me again a few minutes ago running 10.14.0 18A336e.
Keywords: regression
Summary: [10.14] After Firefox crashes, crash reporter shows in dock but won't open → [10.14] After Firefox crashes, crash reporter icon shows in dock but won't open
Reporter | ||
Comment 4•7 years ago
|
||
Just to be clear, I can dismiss the icon by right clicking and using the "Remove from Dock" function. But the icon shouldn't be showing up in the dock following the submission of a crash report.
Assignee | ||
Comment 5•7 years ago
|
||
It sounds like the icon is displaying in the "recently used apps" section of the Dock, which is new on 10.14.
Reporter | ||
Comment 6•7 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #5)
> It sounds like the icon is displaying in the "recently used apps" section of
> the Dock, which is new on 10.14.
I turned off the "Show Recent Applications" pref in System Preferences, and the crash reporter icon still shows up in the dock. Also, if you click "OK" all of those reports appear to go to Apple.
Assignee | ||
Comment 7•7 years ago
|
||
Can you post a screenshot of your Dock?
Reporter | ||
Comment 8•7 years ago
|
||
Here is a screenshot of the crash reporter icon in the dock with the pref for Show Recent Apps turned on in System Preferences (I think it was turned on by default). I see the icon after I press the dialog to submit my crash or quit.
Assignee | ||
Comment 9•7 years ago
|
||
Okay, this icon is displayed in the recently used apps section of the Dock. If you remove the icon, disable "Show recent applications in Dock" and cause another crash, does the icon reappear and stay in the Dock?
We may want to explore a way to not show up in the "recently used apps" section of the Dock regardless. But it would be good to get confirmation for the question above first.
Assignee | ||
Comment 10•7 years ago
|
||
The "recently used apps" section is shared with currently running apps that are not pinned to the Dock, so you will want to make sure that the crash reporter has exited before checking. Your last screenshot shows the crash reporter as currently running (see the dot below the app icon).
Reporter | ||
Comment 11•7 years ago
|
||
Here is another screenshot with exact STR. The icon did persist after quitting the crash dialog.
STR:
1. Make sure "Display Recent Apps" is turned on in Preferences
2. Crash Firefox
3. Select "Quit" in the Firefox Crash Reporter Dialog
4. Observe the attached screenshot.
The issue doesn't happen when I uncheck the "Display Recent Apps" in preferences.
Reporter | ||
Updated•7 years ago
|
Summary: [10.14] After Firefox crashes, crash reporter icon shows in dock but won't open → [10.14] After Firefox crashes, crash reporter icon shows in dock when "Show Recent Applications" pref is on
Assignee | ||
Comment 12•7 years ago
|
||
I just tried setting LSUIElement to true in Crash Reporter's Info.plist to see if this would make a difference, but it turns out that I'm not currently able to reproduce the issue. The crash reporter app icon never persists in the "recently used apps" section of the Dock...
Reporter | ||
Comment 13•7 years ago
|
||
Adding Camelia to see if they see this issue in testing using the STR in Comment 11.
Flags: needinfo?(camelia.badau)
Comment 14•7 years ago
|
||
I tested this issue on Mac OS X 10.14 Beta 4 (18A336e) with FF Nightly 63.0a1 (2018-07-26) and I can reproduce the issue.
I used steps from comment 11, and also if I submit the crash report the issue is still there.
Flags: needinfo?(camelia.badau)
Assignee | ||
Updated•7 years ago
|
Priority: -- → P2
Comment 15•7 years ago
|
||
Ovidiu, could you test in Mac OS X 10.14 Beta 5 if the bug is still there? Thanks
Flags: needinfo?(ovidiu.boca)
Reporter | ||
Comment 16•7 years ago
|
||
I still see the issue in the latest seed, 18A353d.
Comment 17•7 years ago
|
||
Thanks marcia. Stephen, do you think you can investigate this in August?
Flags: needinfo?(ovidiu.boca) → needinfo?(spohl.mozilla.bugs)
Comment 18•7 years ago
|
||
I tested on Mac OS X 10.14 Beta 5 with FF Nightly 63.0a1 (2018-08-08) and the issue is still reproducible.
Assignee | ||
Comment 19•7 years ago
|
||
How exactly are you crashing Firefox? I haven't been able to make the icon appear and stay in the Dock so far...
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(ovidiu.boca)
Flags: needinfo?(mozillamarcia.knous)
Reporter | ||
Comment 21•7 years ago
|
||
(In reply to ovidiu boca[:Ovidiu] from comment #20)
> I use the about:crashparent in the URL bar.
Yes, that is what I did as well.
Flags: needinfo?(mozillamarcia.knous)
Reporter | ||
Comment 22•7 years ago
|
||
(In reply to Marcia Knous [:marcia - needinfo? me] from comment #21)
> (In reply to ovidiu boca[:Ovidiu] from comment #20)
> > I use the about:crashparent in the URL bar.
>
> Yes, that is what I did as well.
But not in the initial report - that was a different crash that was not self generated. Most recently I used about:crashparent to still see if it was happening.
Assignee | ||
Comment 23•7 years ago
|
||
Thanks, I was just able to reproduce this in Nightly. However, I'm unable to reproduce with a local build off of m-c. There, the crashreporter app icon disappears once the crash reporter dialog is dismissed.
Reporter | ||
Comment 24•7 years ago
|
||
During triage, I was asked to confirm this is is still happening on the latest seed, 10.14 Beta (18A365a). I can confirm using the latest nightl Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0 that it is.
I can still remove the crash reporter icon from that recent apps area, but if I click on it I am forced to hit OK and submit the report to Apple.
Reporter | ||
Comment 25•7 years ago
|
||
I just crashed in the latest nightly, and since Comment 24 another new seed has been pushed - the issue still occurs with the latest seed 18A371a.
Comment 26•7 years ago
|
||
I'm surprised we aren't seeing similar things here for the updater (separate executable running, which could show up in the recent applications). Can you see if this could/would happen with that, also?
Flags: needinfo?(spohl.mozilla.bugs)
Assignee | ||
Comment 27•7 years ago
|
||
I do not have the bandwidth for exploratory testing at the moment. I will take a look when I get back to this bug.
Flags: needinfo?(spohl.mozilla.bugs)
Updated•7 years ago
|
Assignee | ||
Comment 29•7 years ago
|
||
I have been able to confirm that setting LSUIElement to true in the crashreporter's Info.plist prevents the app icon to persist in the recent apps section of the Dock. I went ahead and applied the same change to the updater app's Info.plist for good measure, even though we have not heard of the updater icon persisting there yet.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Attachment #9014937 -
Flags: review?(mstange)
Comment 30•7 years ago
|
||
Comment on attachment 9014937 [details] [diff] [review]
Patch
Review of attachment 9014937 [details] [diff] [review]:
-----------------------------------------------------------------
Oh, it also means that it won't show up in the Dock entirely, is that right? So users will get less UI feedback during the update process. Maybe that's ok.
Attachment #9014937 -
Flags: review?(mstange) → review+
Assignee | ||
Comment 31•7 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #30)
> Comment on attachment 9014937 [details] [diff] [review]
> Patch
>
> Review of attachment 9014937 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> Oh, it also means that it won't show up in the Dock entirely, is that right?
> So users will get less UI feedback during the update process. Maybe that's
> ok.
It is true that this isn't ideal, but this is the preferred behavior over the risk of showing the updater app icon in the recent apps section.
Assignee | ||
Comment 32•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/25abcd86698efbc460d097fa682d15a56c29b0f8
Bug 1471873: Ensure that the updater and crashreporter app don't appear in the recent apps section of the Dock on macOS 10.14+. r=mstange
Comment 33•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Updated•7 years ago
|
Flags: qe-verify+
QA Contact: ovidiu.boca
Comment 34•7 years ago
|
||
Is this something we should consider for Beta/ESR60 still? RC week is next week.
status-firefox62:
--- → wontfix
status-firefox-esr60:
--- → fix-optional
Flags: needinfo?(spohl.mozilla.bugs)
Assignee | ||
Comment 35•7 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #34)
> Is this something we should consider for Beta/ESR60 still? RC week is next
> week.
I'm a bit torn about this one. Adding keys to our .plist files has had unintended consequences in the past. However, this patch is limited to the updater and the crash reporter app bundle and I can't think of a consequence for this particular key that would be so risky that an uplift request shouldn't be approved. I'll go ahead and request uplift.
Flags: needinfo?(spohl.mozilla.bugs)
Assignee | ||
Comment 36•7 years ago
|
||
Comment on attachment 9014937 [details] [diff] [review]
Patch
[Beta/Release Uplift Approval Request]
Feature/Bug causing the regression: macOS 10.14
User impact if declined: The crash reporter app and the updater app risk showing in the new "recent apps" section of the Dock. Clicking the icon later will not do anything.
Is this code covered by automated tests?: No
Has the fix been verified in Nightly?: Yes
Needs manual test from QE?: Yes
If yes, steps to reproduce: We have only seen the crash reporter appear in the recent apps section so far, so testing will have to be limited to the crash reporter. To test, crash the browser by typing `about:crashparent` in the URL bar. A build with the fix should not leave a crash reporter icon in the "recent apps" section of the Dock.
List of other uplifts needed: none
Risk to taking this patch: Low
Why is the change risky/not risky? (and alternatives if risky): There is minimal risk that this change may have unexpected consequences because of a side-effect of adding a new key to the two applications' .plist files. We are not aware of any potential side-effect.
String changes made/needed: none
[ESR Uplift Approval Request]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: Bad & confusing UX on macOS 10.14 when displaying crash reporter and/or updater.
User impact if declined: The crash reporter app and the updater app risk showing in the new "recent apps" section of the Dock. Clicking the icon later will not do anything.
Fix Landed on Version: 64
Risk to taking this patch: Low
Why is the change risky/not risky? (and alternatives if risky): There is minimal risk that this change may have unexpected consequences because of a side-effect of adding a new key to the two applications' .plist files. We are not aware of any potential side-effect.
String or UUID changes made by this patch: none
Attachment #9014937 -
Flags: approval-mozilla-esr60?
Attachment #9014937 -
Flags: approval-mozilla-beta?
Comment 37•7 years ago
|
||
Comment on attachment 9014937 [details] [diff] [review]
Patch
The patch is minimal and looks low rik enough for a P2, uplift accepted for our last 63 beta.
Attachment #9014937 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 38•7 years ago
|
||
Comment on attachment 9014937 [details] [diff] [review]
Patch
Ugly UI issue on 10.14, approved for ESR 60.3 too.
Attachment #9014937 -
Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
Comment 39•7 years ago
|
||
bugherder uplift |
Comment 40•7 years ago
|
||
bugherder uplift |
Comment 41•7 years ago
|
||
I started to verify this issue and I saw that with the builds that have the fix the "Crash Report" icon is no longer display in the Dock even though the Crash Report window is open, please tell if this is intended or the icon of the Crash Report should be displayed in the dock and after the Crash Report window is closed the Crash Report from the dock should disappear? Please note that I tested with Nightly 64.0a1(2018-10-14) and Beta 63.0b14.
Flags: needinfo?(spohl.mozilla.bugs)
Comment 42•7 years ago
|
||
Update: I tested on Mac OS X 10.13 with FF beta 63.0b13 and the Crash Report icon is displayed in the dock and after the crash is submitted the icon from the dock disappears as intended, but with FF beta 63.0b14 the icon from the Crash Report doesn't appear any more in the dock.
Assignee | ||
Comment 43•7 years ago
|
||
(In reply to ovidiu boca[:Ovidiu] from comment #41)
> I started to verify this issue and I saw that with the builds that have the
> fix the "Crash Report" icon is no longer display in the Dock even though the
> Crash Report window is open, please tell if this is intended or the icon of
> the Crash Report should be displayed in the dock and after the Crash Report
> window is closed the Crash Report from the dock should disappear? Please
> note that I tested with Nightly 64.0a1(2018-10-14) and Beta 63.0b14.
The issue of the Dock icon not disappearing can only be reproduced on macOS 10.14, which has a new section in the Dock for "recent applications". This fix makes it so that the Dock icon will no longer appear anywhere in the Dock, be that the regular Dock on 10.13 and below or the "recent applications" section on 10.14.
Flags: needinfo?(spohl.mozilla.bugs)
Comment 44•7 years ago
|
||
Thanks, Stephen for clarifying this, my understanding is that now you shouldn't see in the Dock the Crash Report icon anywhere (normal Dock or recent application section from the Dock).
I tested this on Mac OS X 10.14 with FF Nightly 64.0a1(2018-10-15), Beta 63.0b14 and Firefox ESR 60.3.0 and I can't reproduce the issue any more and the Crash Report icon is no longer displayed in the Dock in any section if it.
I tested this on Mac OS X 10.13 with FF Nightly 64.0a1(2018-10-15), Beta 63.0b14 and Firefox ESR 60.3.0 and I can't reproduce the issue any more and the Crash Report icon is no longer displayed in the Dock in any section if it.
Please note that for ESR builds to crash I used this steps:
1. Go to about:config -> devtools.chrome.enabled (set it to true)
2. Open Scratchpad with Shift + F4.
3. Switch the Environment from Content to Browser.
Cu.import("resource://gre/modules/ctypes.jsm");
let zero = new ctypes.intptr_t(8);
let badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t));
badptr.contents;
**I can't crash the ESR build if I go to about:crashparent
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•