Hello.
Here is the problem:
JS

 $(".spinBox").css("display","block");
 //....
 $(".spinBox").css("display","none");

CSS:

.spinBox {display:none; z-index:6; position:absolute; top:-45px; left:0; bottom:0; right:0; background:rgba(0,0,0,0.5); }
.spinBox img {position:absolute; display:block; width:50px; height:50px; margin:auto; top:0; left:0; bottom:0; right:0;}

HTML:

<div class="spinBox">
    <img id="spinImg" src="images/bg/spinner.png" alt="spinner" />
</div>

All that works fine in webview in Gingerbread and Jelly Bean. But in Ice cream sandwich works like 30 out of 100 times. The spinner would rotate(css keyframes) until I touch the screen. It seems like there is no redraw until screen is touched.Perhaps you had expirienced something similar. Please help me. Thanks.

Dani AI

Generated

Short summary and a likely cause: ’s “double toggle” behavior is a classic WebView repaint/compositor quirk from the ICS-era WebView — the CSS animation runs but the compositor doesn’t push new frames to the screen until an input or an explicit repaint is triggered. The double display toggle simply forced a reflow/paint, which explains why it “fixed” the spinner in that case. (stackoverflow.com)

Practical, low-risk fixes (try these in order):

  • Prefer animating transform or opacity rather than top/left; that is far cheaper and more reliable in WebKit/Blink. Promote the animated element to its own compositing layer so the engine actually repaints it. Example CSS to try on the spinner element:
.spinner {
  -webkit-transform: translateZ(0);
  -webkit-backface-visibility: hidden;
  /* animate transform or opacity only */
}

This frequently eliminates the “no redraw until touch” symptom. (stackoverflow.com)

JS workarounds when CSS alone doesn’t help:

  • Force a synchronous reflow between style changes (read a layout property) or schedule the next step with requestAnimationFrame / setTimeout(0). Example pattern:
var el = document.querySelector('.spinBox');
el.classList.add('anim-start');   // start animation class
void el.offsetWidth;              // force layout/reflow
// next steps or removal can go here or in rAF

Reading offsetWidth or using requestAnimationFrame reliably forces the browser to perform the layout/paint pass instead of waiting for a touch. (stackoverflow.com)

Native / last-resort options:

  • From the host app you can call webView.invalidate() or change layer type / disable hardware acceleration for that WebView (or view) — this can fix painting bugs but may hurt performance and battery life, so use it only if the CSS/JS fixes fail. See Android docs on hardware acceleration and use these native changes sparingly. (developer.android.com)

Recommended troubleshooting order: 1) switch animation to transform/opacity + promote to layer, 2) add a tiny JS reflow/RAF step, 3) consider native invalidate / layer-type changes. Test on a real ICS device (not just emulator) to confirm the fix.

have no idea what was wrong, but putting this

if($('.spinBox').css('display') == "block"){
           $('.spinBox').css('display', 'none');
       } 

after

$(".spinBox").css("display","none");

fixed the issue.
So setting display to none twice with some time difference solved the problem.
The problem is solved but I will continue on investigating this some more. It's possible that the problem is in my code.(but then again, it was working on 4.1.x and 2.3.3 but not on 4.0.4 . tested on real devices.) Weird o.O

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.