Closed julianthompson closed 1 year ago
Hi @julianthompson I tried to test this but couldn't see it happen. I'll leave this open for someone else to maybe help out.
It's like 1 in 10 / 20 refreshes on chrome (os x) for me.
I'm occasionally seeing incorrect values as well.
If I refresh I can get updated / correct information. This is infrequent, but frequently enough to where we hear complaints about it.
Thank you, by the way, for a fantastic component. It is much appreciated! Great work.
I'm all ears to fix this but without any additional data or insight into why this might happen sometimes I can't reserve the time to look into this now.
@rikschennink, understood. I'll take a look next time it occurs and see if I can trace the issue back.
@rikschennink, I looked into this a little more. The counter is counting down using an negative epoch time.
Additionally the tick is happening incredibly rapidly, the numbers are just flying by. The timeout on the setTimeout
call is a negative value so the timeout executes immediately.
This is where it gets interesting: I cannot reproduce this issue by refreshing the page many times. No matter how many times I attempt to refresh (I tried about 30 times), the countdown works as expected. HOWEVER, If I open a new browser tab and type in the URL, let the autocomplete do its thing and show the site as a suggested site and then click on it, most of the time I will get the clock counting down this large number as shown in my previous screenshot.
I further noticed that if I have my dev tools open and have "Disable Cache" enabled, the page seems to pull up correctly each time.
I know browsers like Chrome do a pre-fetch of sites when typing them into the browser's search bar before actually clicking on the suggested site. I'm wondering if that has anything to do with this. I'm not sure why, or how, but its very interesting.
@rikschennink I have the fix to this, but not sure the best way to commit it. I created a fork but see multiple variations of the source code in the tick
folder. It seems the source code is duplicated in each of these variants.
How do you prefer your pull requests? I'd like to get this merged and rebuilt / deployed ASAP so I can put this in my rearview mirror.
Thanks for all your hard work on this library!
The tick folder is a build dist, the source can be found here: https://github.com/pqina/tick/
What did you change to make it work?
What did you change to make it work?
I moved where the determination of tickExpectedTime
is performed in the start()
function. We need to determine the tickExpectedTime
value before we have the opportunity to sleep or hide the timer due to page visibility changes.
I submitted a pull request for the change. I did not create a new dist, however (required old Python and VS 2017)
Thanks! I'll explore the fix next week, currently packing for a trip.
Thanks! I'll explore the fix next week, currently packing for a trip.
Enjoy!
@rikschennink, just checking in on this. I'd prefer to use an official build vs. a build I do myself. Any plan on merging this soon? Hope the trip went well.
@ryno1234 sorry for the delay, just merged and published new release.
@rikschennink, I realized this change was submitted in tick, but it hasn't been used to create a new version of the flip library. Is this something you can do? Or, instruct me how and I can do it and check it in and submit a PR.
Thank you!
Ah okay, I'll see if I can merge.
Just pushed 1.8.1
Thanks Rik!
Not sure if I'm doing something wrong, but sometimes the counter displays the incorrect value. (I'm essentially using the slow reveal code from https://pqina.nl/flip/ (slow reveal).
Here is my code:
https://codepen.io/julianthompson/pen/poVOwdW
You'll need to refresh a few times to get the wrong value. Its usually one digit out. I got two wrong values in 10 refreshes. Counter 1 should be 631 and it displayed 231.