IssueTracker

The problem is very serious.
Currently html5 clearRect isn't working within any android 4 devices.
Please, solve this problem as soon as possible.

we have the same problem

We are waiting for a patch since November because none of the workaround we have tried is stable.

We hope that the patch will come before the launching of our app and if not...well, sadly, we will launch the app on iOS and windows only

[Comment deleted]

Still appears to be an issue as I'm getting quirky results when trying clearRect in a loop. #3 solution is good but too heavy to work in a loop.

What about using requestAnimationFrame for loop rather than using a timer loop ?

Hey, this is a serious issue that is affecting our production components, could someone please look into this???

is there any solvtion for that issue ?  

Something like that works for me:

function bug_workaround() {
  $(canvas).hide();
  setTimeout(function() {
    $(canvas).show();
  }, 1);
}

I call this function after clear.

Opacity trick is better because will not initiate page reflow and hide /
show will.

which trick would that be? modify the opacity?

Yes,

function bug_workaround() {
  canvas.style.opacity = 0.99;
  setTimeout(function() {
  canvas.style.opacity = 1;
  }, 1);
}

[Comment deleted]

Hi,

I'm having the same problem but the workaround doesn't seem to help. Was wondering if this issue is somehow fixed by now?

Thank You.

This opacity hack works for me. I've had this issue on 4.1.1 and 4.1.2, both Galaxy S3 and the S3 mini.

Calling this function between clearing the canvas and the next draw call seems to have fixed the problem.

function bug_workaround() {
  canvas.style.opacity = 0.99;
  setTimeout(function() {
  canvas.style.opacity = 1;
  }, 1);
}

Thanks, dennis.ra!

The opacity trick doesn't seem to work for me (Android 4.3).
Hide & show causes a lot of nasty flicker.

This solution works form me:
https://medium.com/@dhashvir/android-4-1-x-stock-browser-canvas-solution-ffcb939af758
But only the second one:
canvas.clearRect(0, 0, w, h);
canvas.style.display = 'none';// Detach from DOM
canvas.offsetHeight; // Force the detach
canvas.style.display = 'inherit'; // Reattach to DOM

Performance hit seems to be minimal for my app (game with multiple canvas one over another).

seems android 4.1/4.2/4.3 both have this problem?

Ok thanks for the detail.

Will this be released as a fast .X release or in the next normal scheduled cycle? (Just to have an idea if I should already start again using it to find other issues or have time for that).

This has been fixed for the next release, almost certainly as part of a fast .X release

So doing some more tests I see other differences in loaders behavior from before :(

Like onLoadFinished is being called when returning to fragment when it was not the case before (before any call to reload or init made)

And much more important a change in how onLoaderReset is now called.

The documentation of restartLoader Says: "If a loader with the same id has previously been started it will automatically be destroyed when the new loader completes its work. The callback will be delivered before the old loader is destroyed."

But new implementation does not that at all. It calls onLoaderReset then onCreateLoader then onLoadFinished. (Previous implementation was sometimes broken and never called onLoaderReset but at least there was no long duration where we have no data to display).

This is a major change because this means you can't keep the previous data during the load as it's invalidated but you have nothing to display since the new loader is not finished. Meaning empty screen on reload = quite bad UX.

The onLoaderReset problem described in #20 makes working with CursorLoader and CursorAdapter suddenly very cumbersome in 27.1.0.

In order to avoid the "empty data" period of time after onLoaderReset, my extremely hacky workaround is to create a second identical loader, with a separate Loader ID, and flip between the two Loaders with each call to restartLoader, so that the previous Cursor remains alive until the next onLoadFinished callback.

I've opened https://issuetracker.google.com/issues/74135998 to follow that as per Ian request.

Before 27.1.0, loaders initialized with getSupportLoaderManager() used to receive a call to onStartLoading() while the activity was executing super.onStart(). This allowed synchronous loaders to initialize resources before the remaining body of onStart() executed. In 27.1.0, loaders no longer start loading until some time after onStart(). This change caused a few NPEs in our onStart() methods. Is this 27.1.0 behavior a violation of the "between onStart/onStop" contract?

I think https://issuetracker.google.com/issues/73976255#comment13 is referencing this same guarantee which appears to be broken.

With a bit more digging I found https://issuetracker.google.com/issues/74225064 which appears to reference and fix the exact issue that I mentioned in #23. Sorry for the noise.

please update your support libraries with 27.1.1

This bug has been fixed in  Support Library 27.1.1.

(Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver Message{kind=ERROR, text=Program type already present: android.arch.lifecycle.LiveData$LifecycleBoundObserver, sources=[Unknown source file], tool name=Optional.of(D8)})

solv this problam