904488 - [Buri][TOR][MMI] Slow MMI while browsing device menu

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
 Firefox os  v1.1
 Mozilla build ID:20130806071254
 
 DEFECT DESCRIPTION: Man Manich Interface on FF OS 1.1 is much more slow than older versions (1.0.1), maybe new user won

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: browser performance on v1.1

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: browser performance on v1.0.1

Comment 5

[Cheng-An, XIONG]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184
Firefox os  v1.1
Mozilla build ID:20130806071254

DEFECT DESCRIPTION: Man Manich Interface on FF OS 1.1 is much more slow than
older versions (1.0.1), maybe new user won´t noticed about it but some
engineers how already works with 1.0.1 and now they change to 1.1 and some of
them noticed about the slow  performance while browsing phone menu

 EXPECTED BEHAVIOUR: Improve Speed while browsing device menus, for example
settings, when you unlock display, to open and close calendar,write new e-mail,
etc.

 REPRODUCING PROCEDURES:
1.- After use FF OS 1.0.1 you will noticed menu browsing is a little bit slow
in FF OS 1.1

 ASSOCIATE SPECIFICATION:

 TEST PLAN REFERENCE:

 TOOLS AND PLATFORMS USED:

 USER IMPACT: Unfriendly interface.

 REPRODUCING RATE: 100%

 For FT PR, Please list reference mobile's behavior:

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

the data attached are for launch time of browser only. and they are both below 1sec which should not be too much of a difference for end users.

Can you provide more specific information on the below? and create bugs for each app?
" EXPECTED BEHAVIOUR: Improve Speed while browsing device menus, for example
settings, when you unlock display, to open and close calendar,write new e-mail,
etc."

Thanks

Comment 7

[Cheng-An, XIONG]

(In reply to Joe Cheng [:jcheng] from comment #6)
> the data attached are for launch time of browser only. and they are both
> below 1sec which should not be too much of a difference for end users.
> 
> Can you provide more specific information on the below? and create bugs for
> each app?
> " EXPECTED BEHAVIOUR: Improve Speed while browsing device menus, for example
> settings, when you unlock display, to open and close calendar,write new
> e-mail,
> etc."
> 
> Thanks

1 seconds is enough to understand the slow. if you compare v1.0.1 and v1.1 at the same time.

another conclusion from the 2 pictures shows that the average time is increased about 10%.

and on the other hand, this takes browser for example, you can also take other applications to understand the performance is slower.

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

both v1.1 and v1.0 are under 1 sec so v1.0 and v1.1's differences are not 1 sec. they are roughly 0.1 sec difference on the graph which i don't believe most users will notice but yes there can be room for improvement

i compared your device on v1.1 and v1.0. to be honest i do not find much differences between them so this is why i am asking to be more specific 

Thanks

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

before we have anything solid for v1.1
move this to koi? for browser performance improvement

Comment 10

[remco]

Coming back to the original defect description, everyone using v1.1 TCL build is saying the performance is much slower compared to v1.0.1.

How can we analyze this problem? Can we check driver versions and compatibility issues with latest v1.1 Firefox OS? 

Trying to figure out how we move the slow performance issue forward (not just browser launch).

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

(In reply to remco from comment #10)
> Coming back to the original defect description, everyone using v1.1 TCL
> build is saying the performance is much slower compared to v1.0.1.
> 
> How can we analyze this problem? Can we check driver versions and
> compatibility issues with latest v1.1 Firefox OS? 
 
This is on the OEM partner. Mozilla does not own the drivers. + I don't find much difference between v1.1 and v1.0

> Trying to figure out how we move the slow performance issue forward (not
> just browser launch).

please provide side by side video of v1.1 and v1.0 and steps to reproduce

Thanks

Comment 12

[Chris Lee [:clee]]

(In reply to remco from comment #10)
> Coming back to the original defect description, everyone using v1.1 TCL
> build is saying the performance is much slower compared to v1.0.1.
> 
> How can we analyze this problem? Can we check driver versions and
> compatibility issues with latest v1.1 Firefox OS? 
> 
> Trying to figure out how we move the slow performance issue forward (not
> just browser launch).

We need concrete examples that are reproducible on what it means when they say "performance is much slower".  

Based on what I see in this bug, there isn't anything that is actionable. 

Joe is right, the delta on the browser app launch times are in the 100ms range which isn't significant enough to really be detected.  

However, I doubt that's what our partners are referring to.

Comment 13

[Cheng-An, XIONG]

Attachment: FF_browser_video.mp4

Comment 14

[Cheng-An, XIONG]

the problem is much more evident when connected on 3G network than Wi-Fi

Comment 15

[Andreas Gal :gal]

Thank you for the video upload! This is very helpful. This looks like network or caching. Lets try to reproduce this. Will block on this until we know whats up.

Comment 16

[Andreas Gal :gal]

After reviewing the video it seems the video is comparing Android with Firefox OS 1.1. We are very keen on improving performance and 1.2 has many performance improvements coming already. Please provide any additional performance metrics such as concrete page load times for 1.2. For 1.1 IOT we can't fix this issue. It would require major re-architecting of the system which we have done for 1.2, but which is not stable in time for 1.1. Setting blocking-.

If you see any regressions from 1.0 performance in comparison with 1.1, please nominate those bugs. We can and will fix any regression from 1.0. Any improvements should go into 1.2.

Comment 17

[Cheng-An, XIONG]

Attachment: 20130818_234428_Browsing_not_responsiv_Compress.7z.001

video part 1/2

Comment 18

[Cheng-An, XIONG]

Attachment: 20130818_234428_Browsing_not_responsiv_Compress.7z.002

video 2/2

reproduced video provided

Comment 19

[Joe Cheng [:jcheng] (please needinfo)]

in the latest video, can you share the URL of that website?

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

Can you please provide the 1.1 image you are testing with in teleweb?  I do not see it there currently and would like to try to reproduce the problem on the same image.

Thank you!

Comment 21

[Ben Kelly [:bkelly, not reviewing]]

I've been trying to reproduce this for the last few hours on the US20130808 image from teleweb which is v1.1.I'm using an AT&T sim card in the US.

So far I've only been able to trigger the OOM killer on browser tabs by visiting a combination of washingtonpost.com, slashdot.org, and cnn.com.  (For this issue I believe you want to look at bug 797189.)

I have not been able to reproduce slowness, however.

Can you provide exact steps starting from flashing the image until you see the behavior?  Is the problem immediate and constant?  What apps do you install, what data do you load on the device, and what websites do you visit?  How strong is your 3G signal?  Are you switching back and forth between 3G/wifi?

Comment 22

[sync-1]

Created an attachment (id=498054)
 3G browsing not acceptable. test on 176 sw on  22August2013

Comment 23

[sync-1]

Attachment: 3G browsing not acceptable. test on 176 sw on 22August2013

Comment 24

[sync-1]

Hi 
 
 I have added the new video, taken on 21 of August by customer.
 Even if for LATAM the behaviour on latest sw is accetbale, this will be blocking for EU launch, unfortunately.
 Please continue to work on this one.
 
 If you need some more information, don't hesitate to ask.
 
 Best regards
 Daygina Eleouet

Comment 25

[Joe Cheng [:jcheng] (please needinfo)]

seem like the website is http://www.aftenposten.no/

Comment 26

[Joe Cheng [:jcheng] (please needinfo)]

Base on the latest video and information. it seems like the focus is on the browser rendering performance

Drom the video, i guessed the URL of the site and i think i got it right. it is http://www.aftenposten.no/
i did a quick test. on B2G, it's loading the desktop website with all the fancy images, scripts..so i think it's just going to run slowly on low end phones.
also, i did a quick test on Android, the site actually returns a mobile version http://mobil.aftenposten.no/ 
and i tried typing the same mobile URL into B2G browser, but it always return the desktop site.

Other than doing some engineering analysis on this i think we also need to do some evangelism on this site so it returns mobile site to B2G browser

Comment 27

[remco]

> Other than doing some engineering analysis on this i think we also need to
> do some evangelism on this site so it returns mobile site to B2G browser

Any concrete ideas? This is happening more often, Telenor mentioned this in one of the meetings. Another example is www.vg.no site. Although here you can put in the mobile site and load it on B2G. Need a plan for this specific issue.

Comment 28

[Joe Cheng [:jcheng] (please needinfo)]

Attachment: browser performance on http://www.aftenposten.no/ using HTC ChaCha

I tried the same site (http://www.aftenposten.no/) using Firefox for Android on HTC ChaCha (which is a similar hardware speced device with 512MB of RAM - double the RAM) running Android 2.3.5.

It is slightly better but you can still observe the slow rendering and blanks when you do scrolling. This site is very likely too heavy for low end devices

Comment 29

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Ben Kelly [:bkelly] from comment #21)
> So far I've only been able to trigger the OOM killer on browser tabs by
> visiting a combination of washingtonpost.com, slashdot.org, and cnn.com. 
> (For this issue I believe you want to look at bug 797189.)

I think I actually triggered a new bug with this.  See bug 908455.  Not setting as dependent, though, since I don't recall seeing this in your video.

For the slowness with the aftenposten.no website, please see bug 908250 and its child bugs.  As Joe noted above they are serving desktop sites to b2g which are not designed for mobile devices.  We need to work with the sites to get b2g properly recognized as mobile.

I was unable to observe any other system wide slowness.  If you feel this is still the case, though, we will need a more detailed set of steps to reproduce. (Note, running desktop websites will use more memory and could possibly affect overall system performance.)

Therefore, I'm handing this off to Karl and his team to work on the compatibility issue.

Joe, please follow-up with the partners and let me know if you need more engineering assistance.  Thanks!

Comment 30

[Mike Lee [:mlee]]

Assigning to Karl per Ben's comment #29.

Comment 31

[Karl Dubost💡 :karlcow]

Hmm. There is already an open bug for aftenposten.no Bug 908391 with regards to the mobile version of the site. 

This seems to be a core issue and not related specifically to the site. It just that it exhibitis the issue that Firefox OS has with some sites. :)

It should be assigned to a person working on the core performances, no?

Comment 32

[Preeti Raghunath(:Preeti)]

Mike, please reassign.

Comment 33

[Ben Kelly [:bkelly, not reviewing]]

I believe our view was that it would not be possible to optimize the B2G adequately for these desktop sites as they are simply too heavy-weight for low powered devices.

So I guess we were thinking this bug would get closed once the sites properly returned mobile versions for our UA.

I think we need to know if this is still an issue for our partner.  Joe? (needinfo is still out for jcheng.)

Comment 34

[Karl Dubost💡 :karlcow]

(In reply to Ben Kelly [:bkelly] from comment #33)
> I believe our view was that it would not be possible to optimize the B2G
> adequately for these desktop sites as they are simply too heavy-weight for
> low powered devices.

If it's not possible, you might want to close it as WONTFIX. It's just a question of choice.

> So I guess we were thinking this bug would get closed once the sites
> properly returned mobile versions for our UA.

Nope because you will always find a Web site out there that will be too heavy for a specific set of parameters. 

> I think we need to know if this is still an issue for our partner.  Joe?
> (needinfo is still out for jcheng.)

This is a different issue which is address by a different and unrelated to this one ;).

Comment 35

[Faramarz Rashed]

if that's the decision then please close this. :jcheng, can you find out if the resolution discussed here is acceptable to our partners?  let's not have this hanging in there...

Comment 36

[remco]

I believe we should close this and open another bug on a more specific matter.

The original issue also had to do with overall performance. I've just checked a production v1.0.1 versus the new intermediate v1.1 build provided on Aug 20 by Alcatel and the performance is almost identical.

Comment 37

[Ben Kelly [:bkelly, not reviewing]]

Closing per comment #35.  jcheng, please reopen if necessary based on partner feedback.  Thanks!

Comment 38

[Joe Cheng [:jcheng] (please needinfo)]

yes our feedback is provided and i am waiting for further feedback 
we may close it for now before we hear any further feedback
we can open another bug with more specifics as needed
and the top sites should return in about a week