Open Bug 850294 Opened 11 years ago Updated 2 years ago

Create some mochitests for verifying that onXXX handlers fire at the correct time with a local and remote PC

Categories

(Core :: WebRTC, defect, P4)

defect
Points:
2

Tracking

()

mozilla35

People

(Reporter: jsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tests])

Create some mochitests that verify that onXXX handlers fire at the correct time with a local and remote peer connection. Such onXXX handlers that should be analyzed include:

- onicecandidate
- onstatechange
- ongatheringchange
- onicechange
- onclosedconnection
- onconnection
- onopen

Note - we do need to analyze two things with these event handlers - what's feasible to automate right now and what makes sense with this list. I already cut some event handlers that we're either already known to be not supported soon temporarily or are not implemented right now.
Blocks: pc-tests
Important because we need to make sure events fire at the *right* time within the large state machine of a peer connection object. Into the ? pool for blocking analysis.
Priority: -- → P2
Whiteboard: [WebRTC][blocking-webrtc?]
(In reply to Jason Smith [:jsmith] from comment #0)
> - onclosedconnection
> - onconnection

Given by the IDL those are data connection only events, right? Those will be covered by the tests I'm writing for at the moment.
(In reply to Henrik Skupin (:whimboo) from comment #2)
> (In reply to Jason Smith [:jsmith] from comment #0)
> > - onclosedconnection
> > - onconnection
> 
> Given by the IDL those are data connection only events, right? Those will be
> covered by the tests I'm writing for at the moment.

Ah. Well, whatever we don't cover should probably encompassed by the mochitests written on this bug. I filed this bug as basically as a "let's get enough tests that at least touch each onXXX handler on a PC." In other words, fill the API coverage gap for whatever it is.
Assignee: nobody → jsmith
Whiteboard: [WebRTC][blocking-webrtc?] → [WebRTC][blocking-webrtc+]
Whiteboard: [WebRTC][blocking-webrtc+] → [WebRTC][blocking-webrtc-][tests]
Assignee: jsmith → nobody
Priority: P2 → P3
QA Contact: jsmith → drno
onicechange is covered since checkin fc7cd53d9dd1.
Assignee: nobody → drno
I think the list of events in this ticket is a little outdated.
These are the events defined in RTCPeerConnection.webidl as of today:

* implemented && covered by tests
  - onsignalingstatechange
  - onaddstream
  - oniceconnectionstatechange
  - ondatachannel
* implemented && not covered by tests
  - onicecandidate
  - onconnection
  - onclosedconnection
* stub implementation only && not covered by tests
  - onnegotiationneeded
  - onremovestream
  - onidentityresult
  - onpeeridentity

So it looks like we are missing tests for the second category.
Whiteboard: [WebRTC][blocking-webrtc-][tests] → [WebRTC][blocking-webrtc-][tests][p=2]
Target Milestone: --- → mozilla32
Whiteboard: [WebRTC][blocking-webrtc-][tests][p=2] → [WebRTC][blocking-webrtc-][tests][p=2, s=fx32]
Status update:

* implemented && covered by tests
  - onsignalingstatechange
  - onaddstream
  - oniceconnectionstatechange
  - ondatachannel
* implemented && not covered by tests
  - onicecandidate (will get implemented as part of Bug 850268 - not in 32)
* stub implementation only && not covered by tests
  - onnegotiationneeded
  - onremovestream
  - onidentityresult
  - onpeeridentity
* exist in our webIDL, but on in the WebRTC standard (Bug 1014304)
  - onconnection
  - onclosedconnection
Much of the work for this is done.  The remaining work will be completed in Fx 33.
No longer blocks: 970426
Target Milestone: mozilla32 → mozilla33
Whiteboard: [WebRTC][blocking-webrtc-][tests][p=2, s=fx32] → [WebRTC][blocking-webrtc-][tests][p=2, s=fx33]
Target Milestone: mozilla33 → mozilla35
backlog: --- → webRTC+
Points: --- → 2
Rank: 35
Whiteboard: [WebRTC][blocking-webrtc-][tests][p=2, s=fx33] → [tests]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
I don't have the capacity any more to work on this any time soon.
Assignee: drno → nobody
QA Contact: drno
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.