1278773 - [Remote Control] Packets loss for remote control service from Fennec add-on to FxOS TV

Status: RESOLVED INVALID

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

Description

[C.M.Chang[:chunmin]]

The packets of command messages for remote-control service will be lost in transmission from Fennec add-on to FxOS TV. There are no input packets on TV side but the log from Fennec add-on shows that the messages are already sent. 

Luckily, the situation is not critical. Most of the time, the user won't be aware of this happening, so they can still have smooth user experiences of remote control service. (Thus, I think the solution for this problem is a nice-to-have feature)

This error happens when we send touchmove[0] events from Fennec to TV. The TV can receive touchstart event but it can't receive the corresponding touchend event.

There are some possible situations:
1. The packets aren't really sent from Fennec. 
2. The packets are sent from Fennec, but it is losed in the network
3. The server receives the packets but it might have some parse error

I think we can start from 2 to know whether or not the messages are sent. Some wifi sniffer like wireshark may be helpful, or we can use some android networking debugging tools on Fennec side to analysis. 

[0] https://wiki.mozilla.org/Firefox_OS/Remote_Control#Touch_Events

Comment 1

[Eric Tsai (no more review request accepted)]

As I remembered, last time we trace this issue, it looks like fennec addon sends event, but android doesn't send this packet (sent packet count doesn't increase). We should start from 1 not 2, to see the problem between fennec and android system?

Comment 2

[C.M.Chang[:chunmin]]

From the brief discussion with SC in last time, we can NOT guarantee the message isn't sent from Fennec.
We can NOT use android's packet-sent number to distinguish whether or not the message is sent. The reason is that the necko might merge two messages into one packet, so you didn't know how many messages are contained in the packet. Thus, we should directly use a wifi sniffer like wireshark via a TCP channel instead of TLS to dump all the transmitted messages, so we can see the plain-text of all the packets. Then we can know whether or not the packets are sent. If the packet isn't sent, then we debug on Fennec side. Otherwise, we might need to find out why TV can't receive it. 

We don't have enough information to find the root cause now. If there is Fennec's problem and this bug is emergent and high-priority, we will fix it.

Comment 3

[C.M.Chang[:chunmin]]

The packet loss problem doesn't happen in my tests today. There is no lost packet to either OpenSSL server
or FxOS TV's TLS server. However, I found other issues that might be related. There might be no swipe value in touchend packet from Fennec. There is a move threshold for touch-pad control to filter the input of inadvertent touch[0] on Fennec side. That's why there is no swipe value generated. To prevent unknown error from converting "Undefined" event.detail.swipe[1] to key events, I think we can simply add a check before accessing event.detail.swipe. I open a bug 1281119 to avoid this situation.

[0] https://github.com/ChunMinChang/fennec-fxos-tv/blob/master/content/remote-control-client/js/panel_element.js#L11
[1] https://github.com/mozilla-b2g/gecko-b2g/blob/b2g48_v2_6/b2g/chrome/content/remote_command.js#L133

Comment 4

[C.M.Chang[:chunmin]]

(In reply to Chun-Min Chang[:chunmin] from comment #3)
> To prevent unknown error from converting "Undefined" event.detail.swipe[1] to
> key events, I think we can simply add a check before accessing
> event.detail.swipe. I open a bug 1281119 to avoid this situation.
The code in TV side works well. No need to change anything. False alarm. My bad!

Comment 5

[Josh Cheng [:josh]]

Hi Chun-Min,
Do you have an ETA for this bug? Thanks

Comment 6

[C.M.Chang[:chunmin]]

I don't see this happen again. Maybe we can consider to close it

Comment 7

[Josh Cheng [:josh]]

Close for now and please reopen if same issue happen again.