797175 - B2G Emulator unable to browse the web

Status: RESOLVED DUPLICATE of bug 871475

(Firefox OS Graveyard :: Emulator, defect)

Description

[[e-mail] [:onecyrenus]]

B2G emulator does not seem to use eth0.  

Ex: If you want to run any amount of testing that reaches out to the web the B2G emulator doesn't seem to browse the web. 

I believe what has happened is that we have a hard dependency on wifi needing to be connected. 

Which for web testing purposes makes the emulator fairly useless.

Comment 1

[[e-mail] [:onecyrenus]]

The downside here is that testing would only be able to occur on the actual device vs on the emulator. 

I tested this on the 
B2G Daily Emulator Build: 10/02/2012
I am running on Ubuntu 11.10, running in a virtual machine.

Comment 2

[Andrew Overholt [:overholt]]

Is this a regression?  Does it block automation?

Comment 3

[[e-mail] [:onecyrenus]]

This generally will block any use of the emulator for testing web content. 

It does not block automation, as all automation runs against localhost. 
This is a regression, because this used to work in the past. 

I don't know how many people are still using the emulator as a test environment because most people have access to the otoro, so possibly the emulator has been deprioritized

Comment 4

[Andrew Overholt [:overholt]]

David, do you have an otoro?

Comment 5

[[e-mail] [:onecyrenus]]

Yes, but the emulator is the test environment. 
Ideally we would need to reproduce errors in the test environment, as it gives a non device specific accounting of the problem.

Comment 6

[Andrew Overholt [:overholt]]

Re-nomming for discussion today.

Comment 7

[Andrew Overholt [:overholt]]

Let's get this fixed (blocking community members and also near future tinderbox tests).  It's likely the same fix as was used in bug 793213.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I believe the phone will be shipped even if this is not fixed.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Vivien Nicolas (:vingtetun) from comment #8)
> I believe the phone will be shipped even if this is not fixed.

Should we renom?

Comment 10

[[e-mail] [:onecyrenus]]

Vivien, 
  I think it makes sense for someone who would be familiar with this part of the platform to be on this bug. 
  If it is a 2 hr fix vs a 2 week fix really is what makes the difference in this case. And it does help me debug. 
  The question is not whether we will ship the device with or without this working. 
The question is how many hours does it save devs by helping me more closely identify a problem, and how many community members does it enable if we have community members using the emulator vs not. 
   Whether we ship the phone with / without this fixed is in my opinion not the right question.

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to [e-mail]  [:onecyrenus] from comment #10)
> Vivien, 
>   I think it makes sense for someone who would be familiar with this part of
> the platform to be on this bug. 
>   If it is a 2 hr fix vs a 2 week fix really is what makes the difference in
> this case. And it does help me debug. 
>   The question is not whether we will ship the device with or without this
> working. 
> The question is how many hours does it save devs by helping me more closely
> identify a problem, and how many community members does it enable if we have
> community members using the emulator vs not. 
>    Whether we ship the phone with / without this fixed is in my opinion not
> the right question.

As far as I've understood this is the main meaning of the blocking-basecamp flag.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Vivien Nicolas (:vingtetun) from comment #11)
> (In reply to [e-mail]  [:onecyrenus] from comment #10)
> > Vivien, 
> >   I think it makes sense for someone who would be familiar with this part of
> > the platform to be on this bug. 
> >   If it is a 2 hr fix vs a 2 week fix really is what makes the difference in
> > this case. And it does help me debug. 
> >   The question is not whether we will ship the device with or without this
> > working. 
> > The question is how many hours does it save devs by helping me more closely
> > identify a problem, and how many community members does it enable if we have
> > community members using the emulator vs not. 
> >    Whether we ship the phone with / without this fixed is in my opinion not
> > the right question.
> 
> As far as I've understood this is the main meaning of the blocking-basecamp
> flag.

I entirely agree with Vivien's comments, although I do understand what I think David is describing. He's probably talking more about time to complete the fix along with the benefit of improved debugging.

However - the reality is that we can't fix everything for v1. In the context of the QA team, many of us don't use the emulator to do the style of debugging described. And I do think the phone will ship with this not working.

Renoming to minus.

Comment 13

[Andrew Overholt [:overholt]]

While it'd be great to keep the emulator working, we can't hold the release for it :(

Comment 14

[Vicamo Yang [:vicamo][:vyang]]

(In reply to [e-mail]  [:onecyrenus] from comment #0)
> B2G emulator does not seem to use eth0.

But actually we should remove eth0 from B2G emulator because there is no such device on a phone. We should, however, create emulated rmnet<N> devices, and probably wifi as well. Developers in Taiwan RIL/Network team have been discussing this issue for a while. We're mostly going to implement rmnet first because it seems to be much much more easier than wifi.

Comment 15

[Vicamo Yang [:vicamo][:vyang]]

This bug can be solved with bug 871475.