Closed Bug 1030097 Opened 10 years ago Closed 9 years ago

Loop support for crash reporting for GMP plugins (openh264)

Categories

(Hello (Loop) :: Client, defect, P3)

Product:
Hello (Loop)
Component:
Client
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Blocking Flags:
backlog -

People

(Reporter: RT, Unassigned)

References

Details

(Whiteboard: [gecko, fxa])

User Story

As a Firefox browser user in a call, I get notified that the other user could not be reached when a GMP plugin crash (openH264) occurs locally so that I can try again (this will apply until the client UI handles call-back URLs on Firefox).
Bug 1009764 relates to generic handling for crash reporting for GMP plugins (openh264) whereas this bug relates to Loop specific handling for crash reporting for GMP plugins (openh264). Loop runs a Loop service and uses a Loop UI and therefore needs a separate bug as UX handling for this crash has to be specific to the Loop UI. My understanding is that this crash can occur during call set-up but also during an ongoing call. Also my understanding is that reconnecting to the other peer after the crash is likely to make the problem go away. For the desktop client I mark this as blocking 1030077 (new error notification to the user during an ongoing call allowing him to re-connect to the other peer) and 1000186 (already existing error notification to the user when a failure to connect occurs during call set-up allowing him to retry connecting to the other peer). This won't apply to the link clicker UI given that if you click a link using the Firefox browser you'll be using the desktop client directly UI. There is a scenario if a URL clicker is in a conversation with a Firefox user who experiences a crash, the call should terminate and the link clicker should be notified so he can attempt to reconnect - this has UX but also server side implications. I although believe that for now only the Firefox browser will be supporting H264 and therefore we can ignore this scenario.
Blocks: 1000240
Blocks: 1030106
Blocks: 1035289
scenario not likely with mobile if fxa doesn't make it in fx34
Priority: P2 → --
Whiteboard: [gecko, fxa]
Target Milestone: mozilla34 → mozilla35
Priority: -- → P3
not needed for first release of FxA & contacts
User Story: (updated)
Although from a product perspective this crash handling is part of the blocking bugs, I think it really should be done after them, hence moving the blocking bugs to depending on.
No longer blocks: 1000186, 1000240, 1030077, 1030106, 1035289
Depends on: 1000186, 1000240, 1030077, 1030106, 1035289
backlog: --- → -
Target Milestone: mozilla35 → ---
Mark, my understanding is that H264 is used only when communicating with users of the FxOS application? Given the on hold status with the FxOS application I am marking this as WON'T FIX. We can re-open if/when the FxOS mobile app work starts again.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(standard8)
Resolution: --- → WONTFIX
That seems reasonable.
Flags: needinfo?(standard8)
You need to log in before you can comment on or make changes to this bug.