Closed Bug 1493192 Opened 5 years ago Closed 5 years ago

Unsent crash reports have been moved from the top to the bottom of about:crashes and now I don't notice them

Categories

(Firefox :: General, defect, P1)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
Firefox 65
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- unaffected
firefox64 --- fixed
firefox65 --- verified

People

(Reporter: jan, Assigned: sam, Mentored)

References

Details

(Keywords: nightly-community, polish, regression)

Attachments

(1 file)

In the past, unsent crash reports were at the top of about:crashes.

I think bug 1476062 caused them to be at the bottom and now I am regularly missing my own WebRender crash reports.

Offtopic: I don't like throttling. Even if I had 50 crashes I clicked all unsent crash reports to be uploaded. I fear to click on any "Clear" button to not loose any report or anomaly without intention.
(And freshly sent crash reports are appended at the bottom, even though they would have to be at the top.)
A regression was attempted and these are my results:

Good build: 2018-09-01
Bad build: 2018-09-24

2018-09-24T18:07:29: INFO : Narrowed inbound regression window from [249c1194, d2bffd03] (3 builds) to [a26c0dfb, d2bffd03] (2 builds) (~1 steps left)
2018-09-24T18:07:29: DEBUG : Starting merge handling...
2018-09-24T18:07:29: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=d2bffd03584a2b31cd79f5e6dacb532fb0f28bed&full=1
2018-09-24T18:07:30: DEBUG : Found commit message:
Bug 1476062: Update about:crashes UI. r=mconley,flod

- Make crash submission explicit by triggering it via a button instead of by
  clicking on the crash ID link.
- Replace the single "Remove All Reports" button with two "Clear All" buttons,
  one for each category of crashes.
- Add a "View" button instead of making crash IDs links to make it explicit that
  you are viewing crash data and not submitting it.

Remove implicit dependence of the order of crash IDs in about:crashes test.

Differential Revision: https://phabricator.services.mozilla.com/D4728

2018-09-24T18:07:30: DEBUG : Did not find a branch, checking all integration branches
2018-09-24T18:07:30: INFO : The bisection is done.
2018-09-24T18:07:30: INFO : Stopped

Thanks.
Triage: potential regression if not intended.

Mike, care to comment? Thanks.
Flags: needinfo?(mconley)
Priority: -- → P1
If you want to get some crashes, enable gfx.webrender.all, restart Nightly and click on one of them:
attachment 8992406 [details], attachment 9007770 [details]
It looks like this re-ordering was first considered in bug 1476062 comment 8.

jsavory commented in bug 1476062 comment 12 saying that:

> I kind of assumed that people interact with the unsubmitted section more,
> therefore it should be at the top. That said, I'm not very familiar with
> how people use this screen so I am happy to flip them if the submitted
> section is considered more important.

So it doesn't sound like there was a super strong reason to re-order the lists. Putting them in the original order should be straight-forward, and if it makes more sense for our users reporting crashes on Nightly, then we should probably do it.
Flags: needinfo?(mconley)
Dolke: can you find an owner for this?
Flags: needinfo?(dolske)
Keywords: polish
i just want to chime in that for the purposes of doing support it would be easier to have submitted crash ids on top. we often ask users who ask about a crashing issue on support channels to provide their submitted crash ids starting with bp- in order to look into their issue - nevertheless they often come up with not yet submitted (unhelpful) ids, because they are listed on top.
Hmm, this was implemented by :mkelly's intern (who is no longer here to fix any followups).

I'm not familiar with the motivations for the original change, and comments here indicate there are dualing wants, so over to :mkelly for a first pass decision.

Kinda feels like a minor issue to me.
Flags: needinfo?(dolske) → needinfo?(mkelly)
The quote from comment 6 seems to indicate that jsavory actually intended unsubmitted to be at the top. That matches up with what this bug wants, so I think ordering the sections such that unsubmitted is on top and submitted is below it is a fine way to go.
Flags: needinfo?(mkelly)
I would like to work on this.
Sure, I can help mentor you through the fix.
Assignee: nobody → sam
Mentor: mkelly
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b9a0d600e885
Flip order of sent/unsent crashes on about:crashes r=mconley
https://hg.mozilla.org/mozilla-central/rev/b9a0d600e885
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
I can confirm that the "Unsubmitted Crash Reports" section is now displayed above the "Submitted Crash Reports" section on Nightly v65.0a1 from 2018-11-04.
This issue is now verified. Thank you!
Status: RESOLVED → VERIFIED
Hey Mike, worth a Beta approval request?
Flags: needinfo?(mconley)
Comment on attachment 9021739 [details]
Bug 1493192: Flip order of sent/unsent crashes on about:crashes

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1476062

User impact if declined: Users who use about:crashes will find that the lists of unsubmitted and submitted crash reports have switched places.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): We're reordering some nodes to put one list above the other. Very straight-forward.

String changes made/needed: None.
Flags: needinfo?(mconley)
Attachment #9021739 - Flags: approval-mozilla-beta?
Comment on attachment 9021739 [details]
Bug 1493192: Flip order of sent/unsent crashes on about:crashes

simple reordering in new about:crashes, approved for 64.0b8.
Attachment #9021739 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.