Make PopularSites long-lived |
|||||||||||||||
Issue descriptionPaired with crbug.com/619584 . In the common case, PopularSites reads and parses a file that past NTPs have already read, and there's no need to do that again.
,
Sep 27 2016
,
Oct 11 2016
,
Oct 12 2016
Not time critical
,
Dec 9 2016
,
Jan 18 2017
,
Jan 18 2017
Adjusting priority as this is now marked as a blocker for the M57 full launch of popular sites on iOS
,
Mar 8 2017
,
Mar 8 2017
Let me know if you'd like me to do progress on https://codereview.chromium.org/2619993002/
,
Jun 16 2017
sfiera@: could you give a quick status update? thx!
,
Jun 16 2017
,
Jul 10 2017
Gentle ping for sfiera@. More specifically, fhorschig@ and I had the impression that Chrome Home is already using Popular Sites (indirectly) as a long-lived object. Is that an issue? If not, should we close this bug?
,
Jul 10 2017
The future state of this on various platforms is: * Android: long-lived via Chrome Home (I believe) * iOS: short-lived, per NTP * Desktop: long-lived via local NTP #7 says "marked as a blocker for the M57 full launch of popular sites on iOS" but clearly it wasn't, since we launched and it's still not fixed there.
,
Jul 10 2017
Desktop: long-lived via InstantService. That's independent of local/remote NTP. (It's not yet fully launched though - going out with M60.)
,
Jul 10 2017
Any objection to closing the bug?
,
Aug 14 2017
Dropping priority and obsolete target milestone based on comment #13.
,
Sep 27 2017
,
Mar 16 2018
With Chrome Home and Local NTP on hold, this is back to square one. Not clear how desired it is anymore.
,
Mar 19 2018
|
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by treib@chromium.org
, Sep 27 2016