838634 - Better integration of e.me to the landing page

Status: RESOLVED FIXED

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

Description

[Joey Simhon]

We'd like to explore changes to the way e.me is integrated with the homescreen

Comment 1

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Redirect to PR

Comment 2

[Cristian Rodriguez (:crdlc)]

Comment on attachment 714345 [details]
Redirect to PR

1) Sorry but I cannot review this huge change nowadays and I guess that you cannot ask for v1 in this feature. Is it in the roadmap for v1? I guess that no if I am not wrong.

Comment 3

[Josh Carpenter [:jcarpenter]]

Comment on attachment 714345 [details]
Redirect to PR

Needs to go through Product channels before landing.

Comment 4

[Ran Ben Aharon [:ranbena] EverythingMe]

Guys, we're gonna keep pushing commits to the PR's branch EverythingMe/design-update for dev convenience.
Whenever the review process starts - let us know and we'll rebase and squash.

Comment 5

[Axel Hecht [:Pike]]

Comment on attachment 714345 [details]
Redirect to PR

Changes to existing strings will also need to change the string ID, r- on the l10n parts of the current diff.

Comment 6

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

An updated version of the patch will come soon.

I would like to see a version that lazy load the e.me backend living in the homescreen (do call loadAssets only when the user has touch the search field).

The main reasons for that is because the current version of the backend generates an additional overhead of ~4.59mb of RAM comsumption at startup after a GC and an additional ~520ms of startup time to load the necessary files for the backend without even looking into the call for Evme.init().

Comment 7

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

A quick look tell me that Evme.init() is a new ~210ms overhead too. So it brings the overhead at startup time around ~750ms. Lazy load! :)

Comment 8

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

The cursor repaints way too much too. Not sure why yet.
I have also noticed a panning regression, there are a lot of extra repaints there.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Sounds like new feature work for v1.2, not a blocker for leo, moving to koi?

Comment 10

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

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #8)
> The cursor repaints way too much too. Not sure why yet.

Custom cursor implementation! Can we remove it?

> I have also noticed a panning regression, there are a lot of extra repaints
> there.

Seems like there are many things that are expensive here. Some seems related to the fact that the branch is a few months old, some seems related to the new look of the landing page and some are just bugs...:
 1) Removing etmmanager.js from the loading save more than 10fps. Could it be because of the removal of the stopPropagation call on the touchstart event in grid.js? I think you remove it because now the code in e.me needs this event and something in the e.me code path is expensive here.

 2) Removing the clock will help too. Since the clock is exactly at the bottom of the page it force to repaints what is between the search bar and the clock (a transparent area...).

 3) The opacity effect when transitioning from the landing page to the right page and vice versa

 4) The height of the pages. Making the |apps > div| rule in grid.css to have a |height: calc(100% - 76px);| instead of |height: 100%| seems to make panning better for all pages, especially on the geekphones. Seems like this is because 2 layers needs to be composited otherwise (the page and the bottom bar)

 5). Removing a hack to force the page to be painted in |.page > div| as well. Seems like it forces repaints of the full size of the layers when only the real height of the page is painted otherwise (the size depends on the content)

 6). Call .preventDefault() inside the touchstart event handler. Actually someone call stopPropagation but this does not prevent the BrowserElementPanning code be in the middle during panning while preventDefault() does.


Now:

1), 2) are directly part of this PR imo.

3) Is a known issue already.

4) Should be pretty harmful and a big win but it does not depends on this PR. I will open a followup to fix that for 1.2.

5). The branch is on a very old gaia tree. this has been fixed since.

6). Should be a win as well. But this one could have a lot of side effects. I will open a separate bug for that as well for 1.2.

Comment 11

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

(In reply to [e-mail] [:lsblakk] from comment #9)
> Sounds like new feature work for v1.2, not a blocker for leo, moving to koi?

There are discussions around that. Let's keep it leo? for now.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #11)
> (In reply to [e-mail] [:lsblakk] from comment #9)
> > Sounds like new feature work for v1.2, not a blocker for leo, moving to koi?
> 
> There are discussions around that. Let's keep it leo? for now.

Can you clarify more information on why this is being leo nominated? Triage doesn't understand why we need to block on this for 1.1, given that we are not taking features for 1.1 at this point.

Comment 13

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

I opened bug 900989 and bug 900990 for 4) and 6). I will nominate those for koi?

Comment 14

[Axel Hecht [:Pike]]

It'd be great if we could get the string modifications landed early in the queue, that'd give us an opportunity to give localizers a head start.

Comment 15

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

(In reply to Axel Hecht [:Pike] from comment #14)
> It'd be great if we could get the string modifications landed early in the
> queue, that'd give us an opportunity to give localizers a head start.

Pike I can do a patch to land the localization for this patch NOW assuming it will not have a lot of changes.

Do you need those landed into v1-train to get the localization of is master enough?

Comment 16

[Axel Hecht [:Pike]]

We're not tracking master yet, so v1-train is preferred. That said, we'd be pre-landing strings, and that has bitten us in the past. We should have extremely high confidence in the strings being the strings.

I'm writing up an email just now, too.

Comment 17

[Wayne Chang [:wchang]]

Triage with partners - 
In general this should be attempted to land on v1.1 but leo will assess when patches are avialable if this will be LeoVB'd.

Leaving blocking status for Mozilla triage.

Comment 18

[Dietrich Ayala (:dietrich)]

Per driver & partner meetings -> +.

Comment 19

[Ran Ben Aharon [:ranbena] EverythingMe]

Vivien and the Evme team are working on a different patch. One that is less risky and has all the feature changes decided on last weekend workshop. Stay tuned for a release in the next few days.

Comment 20

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Patch - redirect to github PR.html

Comment 21

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

Comment on attachment 786461 [details]
Patch - redirect to github PR.html

Strings have changed a little bit, sorry Axel and localizers...

Comment 22

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

https://github.com/mozilla-b2g/gaia/commit/06e7146ad60268833af648ce257f95c5927fa800

There are still 2 underlying bugs that are UI/UX issues that needs to be resolved but this is the first step to get QA and to iterate until friday.

Comment 23

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

Axel correct me if I'm wrong. The list of languages for 1.1 is located at https://bugzilla.mozilla.org/show_bug.cgi?id=893802#c0

Comment 24

[Axel Hecht [:Pike]]

That's not the list. Every department has their own list, most are some variant of https://l10n.mozilla.org/shipping/dashboard?tree=gaia.

Comment 25

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

https://github.com/mozilla-b2g/gaia/commit/60ca81600a080dae33058b0692ecaa213556c926

Pushed to v1-train.

Comment 26

[Tim Guan-tin Chien [:timdream] (please needinfo)]

v1.1.0hd: 60ca81600a080dae33058b0692ecaa213556c926

Comment 27

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This bug some how nullified the hd effort on master and v1.1.0hd, I will file bug on that.

Comment 28

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

Attachment: e.me.add.back.removed.strings.patch

Seems like too many strings has been removed in the patch. Let's add some of them back.

Comment 29

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

Attachment: e.me.add.back.removed.strings.patch

Comment 30

[Axel Hecht [:Pike]]

Comment on attachment 787732 [details] [diff] [review]
e.me.add.back.removed.strings.patch

Review of attachment 787732 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, thanks for the quick patch.

Comment 31

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

master:
https://github.com/mozilla-b2g/gaia/commit/91cf9b7de0546e61dfcd927a6a1aa1edc8a70026

v1-train:
https://github.com/mozilla-b2g/gaia/commit/e9c1e41d73a0de5a8a6b2958f1e9d159fb879e17

Comment 32

[Tim Guan-tin Chien [:timdream] (please needinfo)]

v1.1.0hd: e9c1e41d73a0de5a8a6b2958f1e9d159fb879e17

Comment 33

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

Move block to depends on for bug 898639.  This one only happens on master too.