561126 - [adbe 2898554] Resizing Flash with Core Animation shows the background

Status: RESOLVED INCOMPLETE

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Benoit Girard (:BenWa)]

When resizing Flash RC2 using Core Animation the plug-in appears to take a few frames to adjust its position. This appears to be within Flash's rendering context since the plugin window is not adjusted during this period. This behavior is seen in chrome. Since we are depending on the InvalidateRect event, we do not receive InvalidateRect while the position is being updated and the background is showing through until something else trigger an complete Invalidate.

Comment 1

[Benoit Girard (:BenWa)]

Attachment: Screenshot

Comment 2

[Benoit Girard (:BenWa)]

This bug is reproducible on the nightly trunk build with Flash RC2.

Comment 3

[Benoit Girard (:BenWa)]

Can we discuss this issue with Adobe?

Comment 4

[Charles]

Would you be able to provide an actual build number associated with Flash so we can investigate?  Right click on any flash content and click on About Flash Player 10.

Comment 5

[Benoit Girard (:BenWa)]

I'm using the latest Flash 10.1 and the latest nightly (Firefox 4.0 beta1 will reproduce too).

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100719 Minefield/4.0b2pre

File: Flash Player.plugin
Version: 10.1.53.64
Shockwave Flash 10.1 r53

Comment 6

[Benoit Girard (:BenWa)]

This issue should be blocking Final+. Can we follow up with Adobe to make sure this issue is under their Radar?

This issue is still reproducible with Flash 10.1.x update:
File: Flash Player.plugin
Version: 10.1.82.76
Shockwave Flash 10.1 r82

Comment 7

[Josh Aas]

blocking-final+ on Benoit's recommendation. I haven't actually tried to reproduce this myself yet.

Comment 8

[Benoit Girard (:BenWa)]

I forgot to include clear STR:
1. Visit http://www.youtube.com/watch?v=ftyPMdocotA
2. Press either Apple+PLUS, Apple+MINUS to resize repeatability.

Comment 9

[Charles]

Benoit thanks for the additional information.  I can reproduce this issue on the current trunk 4.0b6pre.  This issue is not reproduceable for me on either Safari or Chrome which leads me to believe something is wrong with the latest Firefox branch.   

I am adding one of our engineers who might be able to comment on this issue.  I'll file a bug internally to be sure its not on our side.

Comment 10

[Benoit Girard (:BenWa)]

(In reply to comment #9)
> This issue is not reproduceable for me on either
> Safari or Chrome which leads me to believe something is wrong with the latest
> Firefox branch.   

This is possible but not necessarily since this depends on how the page composition is performed by the browser. 

Last I checked the problem was that InvalidateRect events where not received for the correct region as the object frame content was updating.

Comment 11

[Johnny Stenback (:jst)]

This needs an ower, BenWa, feel free to reassign if you're not the right person for this.

Comment 12

[Michelle Sintov]

Josh, do you think this is a dupe of 614623?

Comment 13

[Benoit Girard (:BenWa)]

No, this bug is not a dupe of 614623, it's not the same issue and also affects 32-bits.

I don't think I can do much on this bug as the assigne. 

(In reply to comment #9)
> I am adding one of our engineers who might be able to comment on this issue. 
> I'll file a bug internally to be sure its not on our side.

Has this issue been investigated? I'm 90% sure that the issue is that Flash is not invoking InvalidateRect when the frame bound is adjusting to the new size (this seems to take a few frames to happen). This issue would not happen in Chrome/Safari because they are not using NPAPI:InvalidatingCoreAnimation: https://wiki.mozilla.org/NPAPI:InvalidatingCoreAnimation

If the frame move then we expect a call to InvalidateRect otherwise we get visual artifact like the one in the screenshot.

To see this in action resize the a youtube video and watch as the bounds of the video moves for a few frames. If the pixel changes we need an invalidation.

Comment 14

[Josh Aas]

While I don't doubt that this problem is real I haven't seen it myself nor have I heard many complaints about it. For that reason and because Benoit believes it to be a Flash bug I'm changing to blocking2.0-.

Re-categorizing as a Flash bug.

Comment 15

[Josh Aas]

I misunderstood the problem here and I can reproduce it easily after all. We should fix this but I still don't think we need to block on it.

Comment 16

[Alex Butin]

As written in bug 635878:
It does another oddity. When I switch on/off Bookmarks or History sidebars, the
full-size Flash app drags slowly from a different size to the correct, like a
very slow stretching. It takes 1-2 seconds.

Comment 17

[smadayag]

(In reply to comment #15)
> I misunderstood the problem here and I can reproduce it easily after all. We
> should fix this but I still don't think we need to block on it.

not sure where this was left off...  let us know if any action is needed.

Comment 18

[u279076]

Adding test case from bug 635878 which easily reproduces this issue.

Steps:
1. Open test case URL
2. Open Bookmarks sidebar via keyboard shortcut (CMD+B on Mac)
3. Close Bookmarks sidebar

Result:
Noticeable resizing "animation".

Expected:
Simply pop to resize.

Comment 19

[Alex Butin]

Just downloaded FF 4.0 RC2. Wrong re-rendering is returned back!
Resize of viewport (History bar, Bookmarks bar, etc.) absolutely destroys full-size Flash! This is the worst thing in RC ever!

Comment 20

[Benoit Girard (:BenWa)]

I found the exact problem that is happening here:

CALayer have a default animation property that I'm assuming most plugin overlook when building their layers. This causes the layer to animate when we resize since we update the position/bounds of the layer to render it. Since this is a default property of the CALayer/CATransaction neither the browser or the plugin is accounting for it or expecting it.

There's no specification to how the browser can use the CALayer provided by the plugin so it doesn't make sense for this animation to be there. It is very noticeable when resizing as it causes the frame to animate to its new position. Or as mentioned in Comment #18.

Plugin should disable these default animations but I suppose there wouldn't be much harm in the browser disabling it. Perhaps this is something that should be clarified in the NPAPI specification?

Comment 21

[Josh Aas]

If that's true then we should probably start by filing a bug with Adobe about the default property issue.

Comment 22

[smadayag]

i'll take care of it.  i don't have access to our bug system at the moment, but will make sure it's enter tomorrow.

Comment 23

[smadayag]

issue entered internally as W2898554.  it is currently in review...

Comment 25

[Benjamin Smedberg]

I'm closing a lot of bugs which are filed as Adobe Flash bugs which are either irrelevant, not actionable, or not serious enough to track in the Mozilla bug tracker. For the most part, Flash bugs should be filed in Adobe bugbase, and we'll only track a few highly-critical issues in the Mozilla tracker.

Comment 26

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.