Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Top Site Tiles disappear after clicking on them #11043

Closed
LaurenWags opened this issue Sep 20, 2017 · 9 comments
Closed

Top Site Tiles disappear after clicking on them #11043

LaurenWags opened this issue Sep 20, 2017 · 9 comments

Comments

@LaurenWags
Copy link
Member

Description

With a clean profile on 0.19.7, if you click on one of the top site tiles, after 5 seconds it is removed from the Dashboard.

Steps to Reproduce

  1. Clean install of 0.19.7
  2. Open up a new tab, click on one of the top site tiles.
  3. Site is loaded in the tab.
  4. Open a new tab.
  5. If it took you less than 5s to open the new tab, your tile will be displayed and then it will disappear from view. If you took more than 5s to open the new tab, the tile will not be there at all.

Actual result:
topsitetiles

Expected result:
Top site tile should not disappear after it is used.

Reproduces how often: 100%

Brave Version

Brave | 0.19.7
rev | c8481a9
Muon | 4.4.16

Additional Information

@LaurenWags
Copy link
Member Author

this issue is not reproducible in 0.18.36:
topsitetiles01836

@bbondy
Copy link
Member

bbondy commented Sep 22, 2017

@LaurenWags is this still reproducible with 0.19.12 or later? I can't reproduce. It does change the icon with a similar affect but it doesn't remove the tile.

@bbondy bbondy added the needs-info Another team member needs information from the PR/issue opener. label Sep 22, 2017
@srirambv
Copy link
Collaborator

It is still reproduced on 0.19.13
11043

@LaurenWags
Copy link
Member Author

@bbondy I am still reproducing in 0.19.13 but only if you click on those tiles with a clean profile:
11043

If I have a profile that I've been using for a bit (like the profile I used for testing yesterday), clicking on the tiles does not make them disappear:
11043-existingprofile

@bbondy
Copy link
Member

bbondy commented Sep 22, 2017

Thanks for the confirmations.

I can reproduce on the release profile no problem.
I cannot reproduce on my dev profile with the same changeset.

Strange

@bbondy
Copy link
Member

bbondy commented Sep 22, 2017

By profile above I meant config actually. Both are fresh profiles. Production builds cause the problem, development builds do not.

@bbondy
Copy link
Member

bbondy commented Sep 22, 2017

Even stranger I reproduce when I build a production build locally with a fresh profile.

bbondy added a commit that referenced this issue Sep 23, 2017
Fix #11043

The problem is that top sites caching keeps the smallest count, so that it doesn't need to consider items that is smaller than that count. But for top sites it is 1, and when added to history it is 0

This change is only for 0.19.x and 0.20.x

Auditors: @cezaraugusto
bbondy added a commit that referenced this issue Sep 23, 2017
Fix #11043

The problem is that top sites caching keeps the smallest count, so that it doesn't need to consider items that is smaller than that count. But for top sites it is 1, and when added to history it is 0

This change is only for 0.19.x and 0.20.x

Auditors: @cezaraugusto
@bbondy
Copy link
Member

bbondy commented Sep 23, 2017

Fixed:

0.19.x: 82d2eac
0.20.x: 12f516d
Fix does not apply to 0.21.x, but 0.21.x (currently master) has other issues which I posted for

@bbondy bbondy closed this as completed Sep 23, 2017
@bbondy bbondy added release-notes/exclude and removed needs-info Another team member needs information from the PR/issue opener. labels Sep 23, 2017
@bsclifton
Copy link
Member

@bbondy looks like you got bit by the wonderful Cmd + C bug 😄
0.19.x hash is 455742d

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.