Flash of un-animatd content similar to rdar://problem/12081774 . A demo is at http://jsfiddle.net/DFTzk/ . I found this problem initially using Core Animation. It seems that even though an animation is added and the model value is set within the same transaction, there appears to be slight media timing differences. The workaround is to use kCAFillModeBoth, which ensures that there are no gaps. The bug was not present in OSX 10.5 Leopard, I believe it was introduced when Core Animation was re-written in C++. Unfortunately CSS transactions do not allow fill mode to be specified, only CSS animations. The choice of component "WebCore Misc." was just a guess.
I know the problem is related to rdar://problem/12081774 because I wrote a framework that swizzles out CALayer and CAAnimation fillMode and setFillMode: to only allow kCAFillModeBoth. This obviously breaks lots of other stuff so I didn't upload it, but it does fix this bug. I wouldn't even know where to begin to create a patch.
Created attachment 201297 [details] Patch
Attachment 201297 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCore/platform/graphics/ca/mac/PlatformCALayerMac.mm']" exit_code: 1 Source/WebCore/ChangeLog:5: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:6: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:7: Line contains tab character. [whitespace/tab] [5] Source/WebCore/ChangeLog:12: Line contains tab character. [whitespace/tab] [5] Total errors found: 4 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
A better demo of this bug can be seen at http://jsfiddle.net/RndZs/ This was my first attempt at contributing to WebKit and creating a patch. I encountered many difficulties while trying.
This is the best demo showing the bug, red is exposed in Safari for OSX: http://jsfiddle.net/xyAbp/
Comment on attachment 201297 [details] Patch Attachment 201297 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/280135 New failing tests: compositing/reflections/animation-inside-reflection.html compositing/reflections/nested-reflection-transition.html animations/change-transform-style-during-animation.html compositing/reflections/nested-reflection-animated.html
Created attachment 201304 [details] Archive of layout-test-results from webkit-ews-01 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.2
Comment on attachment 201297 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=201297&action=review Thanks for tackling this. Need to use spaces, not tabs. Doesn’t compile on Mac, need to find out why. > Source/WebCore/platform/graphics/ca/mac/PlatformCALayerMac.mm:445 > + // Workaround for <rdar://problem/7311367> flash of un-animated content <https://bugs.webkit.org/show_bug.cgi?id=115278> Not a good WebKit comment. We need the comment to say briefly what this is working around and why this works.
I don't want to take this patch without further analysis of why the flash occurs. Just applying this bandaid is not a good idea.
I believe further analysis will show that this is the same as rdar://problem/12081774 , and that it is a Core Animation bug, not a WebKit one. For the radar, I uploaded a third regression that shows the bug but requires heavy GPU usage to trigger it. It is also available here: https://github.com/KevinDoughty/FlashOfUnAnimatedContent and the best web based test so far is here: http://jsfiddle.net/R6UW5/ The github repo shows that animations just do not start when expected every time. It quickly and repeatedly adds an animation with the same from and to value, so there should be no gaps without animation. I hope you will permit me to continue to work on this regardless. It is a good learning experience for me. I would like to properly perform the test suites and submit a patch, because everything blew up last time. I will be sure to put a note in the ChangeLog that the patch should not to be accepted. (It is a good thing that it failed the first time because I left out a pretty important conditional to ensure that only CSS Transitions were given the fillMode.) However, this would show the effectiveness of the workaround and suggest that it is indeed related to the radar.