Closed Bug 1191745 (new-homescreen) Opened 9 years ago Closed 9 years ago

[meta] Switch to new homescreen by default

Categories

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

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cwiiis, Assigned: cwiiis)

References

Details

(Keywords: qawanted, verifyme, Whiteboard: [systemsfe])

Attachments

(1 file)

Meta bug to track switching to the new homescreen.
Depends on: 1191746
Depends on: 1181555
Whiteboard: [systemsfe]
Depends on: 1180666
Depends on: 1193392
Depends on: 1197174
Depends on: 1197175
Depends on: 1197177
Depends on: 1197179
Depends on: 1197180
Depends on: 1197489
Depends on: 1197509
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Depends on: 1198212
Depends on: 1199182
Depends on: 1200911
Alias: new-homescreen
Depends on: 1200894
Depends on: 1200851
Depends on: 1200867
Depends on: 1201098
Depends on: 1201101
Depends on: 1201137
Depends on: 1201433
Depends on: 1201141
QA Whiteboard: [COM=New Homescreen]
Depends on: 1202422
Depends on: 1202423
Depends on: 1202190
Depends on: 1202611
Depends on: 1202740
Depends on: 1202998
Depends on: 1203993
Depends on: 1206177
Depends on: 1207308
No longer depends on: 1207308
Depends on: 1207534
Depends on: 1207616
No longer depends on: 1208265
Depends on: 1206418
Depends on: 1209487
Depends on: 1209489
Depends on: 1209491
Depends on: 1209493
Depends on: 1209495
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master This switches over the default homescreen to the new homescreen and fixes all the marionette test failures caused by this. One test is removed from system that checked the dialog size on the homescreen (this is doesn't apply in the same way anymore and that functionality is adequately tested by homescreen already). This also incorporates a gaia-app-icon update necessary for app_window_manager_bookmarked_sites_test to pass. Most, if not all changes here are trivial.
Attachment #8666724 - Flags: review?(kevingrandon)
Depends on: 1209792
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Naoki, could you take a quick look at this and let me know if there are any issues QA side, maybe with tests outside of integration/unit tests? I don't really know anything about what other testing frameworks we use, I'm guessing this may cause issues elsewhere.
Attachment #8666724 - Flags: feedback?(nhirata.bugzilla)
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Playing around with launch times the application felt quite slow to get to a visual readiness state. Eli - I was looking for datapoints for launch times regarding the verticalhome and homescreen apps, do you have cycles to help with this? I looked on raptor.mozilla.org and couldn't find apps labeled verticalhome or homescreen.
Attachment #8666724 - Flags: feedback?(eperelman)
Sure! First, verticalhome results are from the reboot test, not coldlaunch, hence why it isn't listed with the other apps. I could probably make a change for that, but for now, here is the data you seek: https://raptor.mozilla.org/dashboard/script/measures?var-device=flame-kk&var-memory=319&var-branch=master&var-test=reboot As far as testing out the new homescreen, and making sure we can properly test existing apps with the new homescreen using Raptor, this should help (based on a new homescreen on the device with the origin homescreen.gaiamobile.org): Run the restart-b2g test against the new homescreen: raptor test restart-b2g --homescreen homescreen To test an existing app works against the new homescreen: raptor test coldlaunch --app clock --homescreen homescreen If you have trouble with any of these commands, lemme know and I can get a fresh build on my device tomorrow and try it out (provided I get tips on enabling the new homescreen).
Running raptor on a Z3C, new homescreen takes ~2 seconds longer to reach visually loaded state. About the same time to reach fully-loaded state. I've not tried too hard to optimise startup performance, there are certainly quite a few things we can do to reduce the cost of layout on startup. Kevin, do you think this should block switching over? I'd really like to get some more testing and fix this post-switch, but I can reshuffle priorities and start tackling it now if you think this is a blocker.
Flags: needinfo?(kevingrandon)
Lets switch to the new homescreen and optimize the performance in the next few weeks.
Depends on: 1210737
I've filed bug 1210737 to track startup performance. My initial comment #6 is incorrect, visuallyLoaded is basically the same, it's fullyLoaded that takes longer to reach.
One of the requirements for the verticalhome was that we stress tested it with a tool which installed hundreds of apps. I need to locate and perform tests with that tool. Using a local indexedDB used to be a requirement in order to have acceptable load times with many apps installed. I'm not sure of the current state of mozapps, but we need to stress test it. I'll try to find the tool and take a look at this.
Flags: needinfo?(kevingrandon)
(In reply to Kevin Grandon :kgrandon from comment #9) > One of the requirements for the verticalhome was that we stress tested it > with a tool which installed hundreds of apps. I need to locate and perform > tests with that tool. > > Using a local indexedDB used to be a requirement in order to have acceptable > load times with many apps installed. I'm not sure of the current state of > mozapps, but we need to stress test it. I'll try to find the tool and take a > look at this. Sounds good - I'm looking at improving our startup performance now, I think this particular test will probably kill new homescreen perf-wise, but we can easily make it better. Hundreds does seem overkill to me (I don't even have hundreds of apps on my Android devices...), but it can't hurt to know.
(In reply to Chris Lord [:cwiiis] from comment #10) > Hundreds does seem overkill to me (I don't even have hundreds of apps on my > Android devices...), but it can't hurt to know. I agree, but it was a partner certification blocker. I'm not sure if that's still relevant or not, but I'll try to dig up some bugs.
Depends on: 1210869
Depends on: 1211266
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Unfortunately I don't think I can review this while bug 1211266 exists - I don't think we can enable it with missing icons and I'm not sure if it's masking performance issues. Chris - can you either look at that issue or perhaps change it to use the certified APIs?
Flags: needinfo?(chrislord.net)
Attachment #8666724 - Flags: review?(kevingrandon)
Depends on: 1211887
Kevin, can you let me know if there are any issues besides bug 1211266 so that I can make sure this is ready when that gets fixed?
Flags: needinfo?(chrislord.net) → needinfo?(kevingrandon)
(In reply to Chris Lord [:cwiiis] from comment #13) > Kevin, can you let me know if there are any issues besides bug 1211266 so > that I can make sure this is ready when that gets fixed? I still want to run through everything functionality wise again, and I would like to do some additional perf testing once bug 1211266 has landed. Leaving NI.
Depends on: 1212864
Depends on: 1212905
Depends on: 1212345
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Handled in comment 5.
Attachment #8666724 - Flags: feedback?(eperelman)
Kevin, any update? We'd really like to make the switch so we can get some better testing done. Going on updates in bug 1211266, it sounds like the bug affects all homescreens, not just this one, and it doesn't sound like the fall-out (very occasional missing app icon images only after flashing) is so terrible that we need to block this on it. It should certainly be a release blocker though, no question about that. The longer we leave to switch over, the less time we're going to have to address issues that come up.
(In reply to Chris Lord [:cwiiis] from comment #16) > Kevin, any update? We'd really like to make the switch so we can get some > better testing done. Going on updates in bug 1211266, it sounds like the bug > affects all homescreens, not just this one I was never able to reproduce bug 1211266 on the current home screen, so I think it's only with privileged APIs. I'm not willing to review something with a regression like that - maybe someone else would though? If you can prove that it also happens on verticalhome I could change my mind. One option could be to use certified APIs until that bug is fixed, then switch back to privileged APIs.
Flags: needinfo?(kevingrandon)
Kevin, what makes you thinking that the problem is because of privileged API ? So far my finding points toward something bad happening with the Blob we are sending back with |getIcon()|, and it might be cause of process separation because the error happens in codepath involving sharing blob in the same process. However that is crashing on the Parent and obviously the homescreen's Child is not the same process. But if you have more infos to share I'd be happy to hear them :)
Flags: needinfo?(kevingrandon)
Oh and all the STRs I could attempt were mostly pointing toward some kind of bad race condition: i.e., on a too slow device, no problem.
I spoke to janv on IRC, he says that if things go well, he should get to bug 1211266 next week. Either way, that bug is a blocker for release because replaceable homescreens is one of our core features. I don't think it makes sense to block on this before switching over, given it doesn't make applications inaccessible (just bad-looking, in reasonably rare circumstance). Changing to certified is unlikely to fix this going on Alexandre's comments, verticalhome probably escapes this by not using the getIcon utility function (and instead using system XHR to fetch the icon directly).
(In reply to Alexandre LISSY :gerard-majax from comment #18) > Kevin, what makes you thinking that the problem is because of privileged API? As Chris mentioned in comment 20 this is only apparent with the getIcon method, which previous certified home screens do not use. I personally would like to see this fixed before introducing known visual regressions.
Flags: needinfo?(kevingrandon)
Depends on: 1214137
Bug 1211266 is extremely rare with this patch applied - I can more easily reproduce it when switching homescreens, as opposed to when the homescreen is the default. Does this tally at all with your experience Kevin? In about a dozen reset-gaia's, I reproduced it once with two icons in the dev apps (I couldn't reproduce it with a production build with new homescreen as default).
Flags: needinfo?(kevingrandon)
Depends on: 1214607
It's probably more pronounced on a flame or slower device. I've seen this with up to four missing icons, which looks pretty bad: https://bug1042807.bmoattachments.org/attachment.cgi?id=8669431 My recommendation is that you either get the platform bug fixed first, or temporarily switch the code to use systemXHR instead of getIcon(). Once the platform code is fixed you could switch back to a privileged app.
Flags: needinfo?(kevingrandon)
Kevin, I've coded a work-around that works consistently for me (I've put in far more conservative consts than there need to be): https://github.com/gaia-components/gaia-site-icon/pull/12 - is this ok with you, in lieu of the platform bug being fixed? (which should also happen soon, after which we can back this change out)
Flags: needinfo?(kevingrandon)
Depends on: 1215553
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Re-adding r? with patch rebased on master with the work-around applied (which is ready to land, pending tests).
Attachment #8666724 - Flags: review?(kevingrandon)
The work-around is merged now, so the pull request is a single commit again.
Depends on: 1215706
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master I'm sorry, but I am going to clear the review request because I don't think that this is an approach that we should be doing in 2.5. I'm not happy trading one heavily used feature (app grouping) for another (pin the web). If there was some way to continue to get to verticalhome and it's functionality, bookmarks included, then I would probably feel differently. I don't necessarily want to block people, or have people think I am the downfall of an entire project, so here are some suggested options to move forward: - Since you are the home screen owner, you can delegate the patch to another non-peer to review (Ben, or anyone on the Pin the Web project). This is how we grow peers after all, and we've discussed this possibility on the mailing list before. - If you are looking for a symbolic approval, consider flagging Tim and Vivien as owners of gaia, or Fabrice as the chief architect, for a review. If you take either of these approaches please remove my name from the r= in the commit message.
Flags: needinfo?(kevingrandon)
Attachment #8666724 - Flags: review?(kevingrandon)
we decided at UX and Product level that we will be ok for 2.5 not to have app grouping. We will be reviewing the app grouping feature as part of the UX evolution and how to come up with a design that would work better for the new UI. there will be re-definition of appgrouping in future release.
I'm uncertain as to the next course of action at this point. The least risk if we want to ship pin-the-web is to carry on with what we were doing and I think this would be the best choice long-term. Some alternatives that are all a mix of riskier/poorer UX, in order from least to most risky: 1. Ship the homescreen as a marketplace app (see bug 1196992), with the intention of replacing app-grouping style functionality asap. 2. Remove pinned pages, retain pinned sites (basically replacing pre-existing bookmark functionality with very little difference), ship verticalhome. 3. Ship both home-screens, allow the user to enable pin-the-web, toggle homescreens when enabling/disabling pin-the-web. 4. Ship verticalhome, put pinned pages in the empty rocketbar search page - Requires porting of the pinned pages bits from homescreen into search (the code is quite modular, so may not be *too* hard - I'd be most worried about how long it'd take to get good test coverage and the lack of anyone having tried it) 5. Ship verticalhome, port pinned pages into verticalhome - There were good reasons we didn't do this in the first place. gaia-grid is very inflexible, and the current searchbar arrangement is hard to change. I'm still not confident we can do this well, and especially so if we only have a week to do it and get it tested. 6. Play banjo I'm providing alternatives because I think that's what I should do, but I must also be absolutely clear that picking any of them (except possibly the first one) is more work to something that was already at risk. I'd also like to state that I'm no big fan of losing app grouping, but we had long meetings about this where we set out what was physically possible in the time, and agreed on this course of action. This isn't really the right time to be changing our minds about things.
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master I'm flagging a few people that I think would make suitable reviewers for this. Please see the conversation above - remember we can always back this out, but we need an r+ before we can continue. What this patch does: - Switch default homescreen from 'verticalhome' to 'homescreen' - Rename 'New Home Screen' to 'Default Home Screen' - Rename 'Default Home Screen' to 'Legacy Home Screen' - Amend test-system tests to use homescreen instead of verticalhome where appropriate - Fix system integration tests to use homescreen's convenience library instead of verticalhome's What this patch doesn't do: - Remove verticalhome - Disable installation of verticalhome - Disable switching to verticalhome - Migrate users from verticalhome to homescreen (see bug 1202422) In short, this patch will make newly flashed/reset builds use the new home screen, but existing builds will continue to use verticalhome until migration patches land (which will probably be in pretty short order after this lands) or they manually switch. This patch mostly needs someone to do a basic sanity check on the configuration and test changes, and preferably to also give it a run-through on a device to make sure nothing is seriously broken (via both install-gaia over an existing build and reset-gaia).
Attachment #8666724 - Flags: review?(gmarty)
Attachment #8666724 - Flags: review?(etienne)
Attachment #8666724 - Flags: review?(bfrancis)
Attachment #8666724 - Flags: review?(21)
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master I left a comment on Github but it looks good to me!
Attachment #8666724 - Flags: review?(gmarty) → review+
I left a comment about localizing the App name in manifest.webapp (this should fix bug 1215706)
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master Sorry for the bug spam, other reviewers - and thanks Guillaume. I've made the changes you and Theo suggested and, pending a full run of green tests that isn't obviously broken, will merge... Fingers crossed! Advanced apologies to sheriffs, I'm only intermittently around this weekend, but as best I can I'll try to keep an eye on it. If we get catastrophic failures, we should back out immediately - small failures (e.g. intermittent integration test failures), I'd prefer a bit of leniency to fix if possible. Cheers to everyone that's provided feedback - I don't think anyone is 100% happy, so let's knock this one out and get to improving it for 2.x/3.0 :)
Attachment #8666724 - Flags: review?(etienne)
Attachment #8666724 - Flags: review?(bfrancis)
Attachment #8666724 - Flags: review?(21)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Thank you everyone. Be assured that figuring out a new solution for organising pinned content on the homescreen is our top priority for 2.6. Flagging QA to get this on their radar so we can test for regressions and make sure the migration works smoothly.
Flags: needinfo?(nhirata.bugzilla)
Keywords: qawanted, verifyme
Depends on: 1215967
I've backed out bug 1202422 and bug 1191745 on causing the fairly disastrous Gij17 bustage. Could you please look into it?
Status: RESOLVED → REOPENED
Flags: needinfo?(chrislord.net)
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Flags: needinfo?(chrislord.net)
Resolution: --- → FIXED
Depends on: 1216084
Blocks: 1216101
Depends on: 1216355
Depends on: 1216700
No longer depends on: 1216355
No longer depends on: 1214388
No longer depends on: 1214349
No longer depends on: 1211266
No longer depends on: 1201141
Note: A new FOTA build is on the way to update people completely on the gonk layer for the migration to be complete.
Depends on: 1218329
Comment on attachment 8666724 [details] [review] [gaia] Cwiiis:bug1191745-new-homescreen-by-default > mozilla-b2g:master This has long since been checked in, removing f?
Attachment #8666724 - Flags: feedback?(nhirata.bugzilla)
Ya, it's been long since checked in. We've filed bugs here and there in regards to it, those bugs have been looked at; clearing NI on me.
Status: RESOLVED → VERIFIED
Flags: needinfo?(nhirata.bugzilla)
This bug is already closed, it solves little to add polish blockers to it.
No longer depends on: 1221340
Depends on: 1217350
Depends on: 1222707
No longer depends on: 1217350, 1222707
A note to people that find this bug (hey Ed :)) - we aren't hanging new bugs off of this bug anymore, the new homescreen has been the default for a long time and we aren't going to back it out. Any issues you find now, feel free to individually nominate as blockers to 2.5 or 2.6 (and note that I track all homescreen bugs, so I'll be aware of anything that gets filed).
Depends on: 1222709
No longer depends on: 1222709
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: