1008161 - [Homescreen] several issues in the icon placement

Status: VERIFIED FIXED

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

Description

[Julien Wajsberg [:julienw]]

I use a Peak on v1.4, with the image images-peak-v1.4-2014-04-29.Gecko-44787e8.Gaia-01b7794.zip.

In case it's useful, this Peak was initially migrated from v1.3.

I'll focus on the issues that are not likely Peak-related.

STR:
* install enough applications to fill the first and second page
* install one more application

Expected:
* the icon is installed on a newly opened 3rd page

Actual:
* no icon is displayed for the last application
* still in the Marketplace the icon is "launch" instead of "free" or "install". And I can launch it.
* I moved an icon to a 3rd page, and then the last application icon appeared on the 2nd page.

Note that one of the application was installed through the App Manager, I don't know if that's relevant. I also didn't try to install yet one more application.

Comment 1

[Julien Wajsberg [:julienw]]

Rationale for nomination: the user doesn't see an icon for an app he installed.

Comment 2

[Jason Smith [:jsmith]]

Adding qawanted to see if we can reproduce this on a production device & whether it happens on 1.3.

Comment 3

[Joshua Mitchell (Inactive)]

This does NOT reproduce on the 1.3 Buri - after filling up the first 2 pages with apps they are installed on the 3rd page.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140501024001
Gaia: 667539f1ed4becc45b182a5f1046221d3eeb9e7c
Gecko: 4b68615ea3e5
Version: 28.0
Firmware Version: v1.2-device.cfg


This also did NOT reproduce on the 1.4 Open_C

1.4 Environmental Variables:
Device: Open_C 1.4
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: FFOS_US_EBAY_P821A10V1.0.0B06_LOG_DL

Comment 4

[Jason Smith [:jsmith]]

Backlog since we don't have proof of this happening on production devices.

Comment 5

[Julien Wajsberg [:julienw]]

I'll try to find a better STR.

Comment 6

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Obviously it seems a problem with devices with different resolution than 320x480 or dppx. I think so because I cannot reproduce it in my tarako or unagi. I don't have an Open C, Peak, Flame or any similar device. Could you Julien give my a hand and check my patch in your device? Thanks in advance

Comment 7

[Julien Wajsberg [:julienw]]

Comment on attachment 8420821 [details]
Patch v1

yep, seems to fix all my issues, both this bug and bug 1004988

Comment 8

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8420821 [details]
Patch v1

Basically the patch fixes the rules which override the hidden icons no-properly in media queries. Thanks for your feedback Julien!!!!! Please, Vivien, could you take a look? 10x

Comment 9

[Chris Lord [:cwiiis]]

Is it really sensible to encode this information in CSS instead of just calculating the limits in JavaScript? This bug is surely just going to manifest again as soon as a device with a slightly different screen resolution/dpi comes along?

Comment 10

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

(In reply to Chris Lord [:cwiiis] from comment #9)
> Is it really sensible to encode this information in CSS instead of just
> calculating the limits in JavaScript? This bug is surely just going to
> manifest again as soon as a device with a slightly different screen
> resolution/dpi comes along?

That's right but that's OK as we are moving from an horizontal based homescreen to a vertical based homescreen right after 2.0.

Comment 11

[Cristian Rodriguez (:crdlc)]

Merged in master:

https://github.com/mozilla-b2g/gaia/commit/70953f779faf6b1a94861c34ffdc3d5fd1c442e5

Comment 13

[Chris Lord [:cwiiis]]

This also affects 1.3. Given that this is a low-risk fix, I think we really ought to get this classified as a blocker. It's very easy to run into and results in very confusing behaviour.

Comment 14

[Julien Wajsberg [:julienw]]

I would not class this patch in the "low-risk" category.

Comment 15

[Cristian Rodriguez (:crdlc)]

I don't know how patches are evaluated to decide if they are low, medium or high risk. I can explain that the patch does: "re-write two rules defined in media queries properly equal to the rule that they are overriding"

Rule by default to be overrided:

body.searchPageEnabled .apps div:first-child ol > li:nth-child(13) {
  display: none;
}

in media queries this rule was written as:

body.searchPageEnabled .apps ol:first-child > li:nth-child(13)

instead of 

body.searchPageEnabled .apps div:first-child ol > li:nth-child(13)

Comment 16

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/2e97bee6bb79d3577dba1bf2a1bbfcba64ee99ab

Comment 17

[Yeojin Chung [:YeojinC]]

The fix was verified on the following devices:

1.4F Environmental Variables:
Device: Flame 1.4F MOZ
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: v10F-3

-----------------------------------------------------

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: v1.2-device.cfg

-----------------------------------------------------

1.4 Environmental Variables:
Device: Open_C 1.4 MOZ
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: v10F-3


----------------------------------------------------

2.0 Environmental Variables:
Device: Open_C 2.0 MOZ
BuildID: 20140522040230
Gaia: ef66efa34ed8a559c8998bde688fae88eb943a7a
Gecko: b40296602083
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL