So I'm working on a mobile website for a client and have added a css loading animation that triggers when users navigate pages or on ajax load.
The animations work fine in Chrome, but in IOS I've found that immediately after triggering navigation (via window.location.href or just clicking an anchor tag), the loading animation just freezes. This happens at the beginning of the call, not after the page is loaded, so there is a decent amount of time where the css isn't doing anything and the site looks like its hung up on something. I'd also add that the animation works when I'm just doing ajax calls.
In the meantime I've set up a delay between when the animation loads and when the navigation actually happens, and it helps somewhat with the look and feel of the site, but its not great.
Any solutions or ideas around why this might be happening?
Animations freezing after navigation is triggered seems to be a general issue with Webkit browsers.
See https://bugs.webkit.org/show_bug.cgi?id=16177
There is a workaround if you can send the request via Ajax/XHR. Then the animation will keep playing. You can trigger the navigation after receiving a 200/ok response from the backend service.
Should you load the entire next page and swap content by Javascript, you may want to pay attention to the browser history API, i.e. add an entry to it for the swapped page.
Apparently there is a workaround if that suits your case: using transform instead of all other properties. See https://stackoverflow.com/a/53178319/647845
Related
Is there a way to let PWA users know that a clicked link is being loaded. Usually in the browser we see the blue progress line indicating this but in the pwa the user is left to assume the page is loading except there is a pseudo effect on the buttons programmed by the developer. I understand the idea behind pwa includes giving users immersive visuals and if pages load faster, the users will not bother about the blue line but sometimes it's needed.
Going through the same thing but i think i found a way.
We can use bootstrap spinners to animate this. We can use javascript to detect a link click and show the spinner. We can also add this on submit button click.
If you look at http://www.sportsdirect.com you will see that when you click on a category whole pages doesnt get refereshed, ie you dont notice any flicker, content above menu doesn't get repainted.
How do i achieve that? Is it only speed or something else? My site locally works fine (most of the time, but sportsdirect gets slight flicker sometimes). Online page gets "refreshed", ie there is 300ms when there is gray screen.
This is something that is very important for a client and i dont know how to fix it.
You should look into AJAX. This allows you to update parts of your page without refreshing the whole page. This will often reduce or eliminate flicker since it does not rebuild the entire page.
A good place to start is Here
Is there a way to get Web Inspector to make my style changes stick past page refreshes?
As I make changes and fixes, before I upload or commit them to the server, it's helpful to see them in the inspector. However, as soon as a link is clicked, the page refreshes and the inspector grabs the server-based version. Is there any way to get around that?
I'm designing an extension for Google Chrome, and I'd really like to earn a little cash from it (if possible) so I'm not eager to post the code in its entirety. I hope this isn't a prohibitive limitation for my question.
I'm injecting a content script into all websites as part of my extension, and part of the content script includes a touch-sensitive overlay; it's an invisible HTML div that's been assigned a swipe listener. The idea is to add swiping functionality to every website on which the script is run.
I'm having issues, though, with the overlay seeming to "die" on certain pages, especially after scrolling down the page. It registers swipes flawlessly all across google.com- scrolling or otherwise- but, for example, seems to die on engadget.com after scrolling down the page a bit. (After scrolling a bit more, it often starts registering swipes again.) Doing something like opening the console (F12) also causes it to start registering swipes, and refreshing the page (to the same place the object was before) lets it start registering again.
The HTML/JavaScript I'm utilizing for the overlay is this:
$("/<div class = \"touch_sensitive_overlay\" style = \"top:40%;opacity:1;position:fixed;height:247px;z-index:99999;width:50%;left:50%;border:2px solid black;\"></div>").prependTo('body');"
I'm using the jQuery Mobile library to register the swipes.
Any helpful insights would be profoundly appreciated.
Update:
A solution was proposed by Sumurai8, and was successfully implemented. The document was listened to for scrolling, and- whenever scrolling occurred- the overlay was removed from the injected HTML, then immediately re-injected. In this way, the overlay is continuously "active," and responds to input on all websites. Thanks for the good thinking, Sumurai8.
You could try to have a small script that does 'something' with the overlay when any element is scrolled. E.g. $('*').on('scroll', function() { $('#overlay').css( {'top': '0'} ); } ); and see if that fixes the problem. While in itself it doesn't do anything, it might make Chrome render your overlay again.
As you said in the comments, removing the overlay and re-appending it will force Chrome to render it again too.
Please see this link. Notice that the search bar first renders near the top of screen. Then aligns itself to be opposite to the logo. I think some css rules are causing this but I am unable to figure out. Can you please help me in pinpointing the reason. What one should avoid in the code to avoid/minimize this behaviour.
This almost aways happens when you have a css rule for blocking that is overwriting the previous. The best thing to do is to have the first thing in the css file to be blocking and normalizing. Every time you need something to be in a place or have a specific size, you should go to the blocking section of your code.
But the most preocupying part of the site you shown is the time it takes to load a fancybox css file.
This issue could just be how each browser loads and renders the content, and also on how fast your network can download content. Since there is many multiple Javascript and CSS files it can just be parsing them slowly and configuring the site as it goes while your network and browser is still downloading and loading everything.
I viewed it in Chrome and Firefox and it seemed to load fine for me.