Closed Bug 640794 Opened 13 years ago Closed 13 years ago

Flash plugin with CSS transform works in FF 3.6 BUT does not in FF 4.0

Categories

(Core Graveyard :: Plug-ins, defect)

x86
All
defect
Not set
normal

Tracking

(blocking2.0 -)

RESOLVED DUPLICATE of bug 644832
Tracking Status
blocking2.0 --- -

People

(Reporter: wmeier, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: compat, regression, testcase)

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) 

The page was created and installed on the server then using FF3.6 it worked very well.
BUT after installing 4.0ß12 and FF 4.0 RC1 and Minefield (2011-30-10) this page does not work with them.

The only difference that I can see is that the Gecko engine is different; work for Gecko 1.9.1 and 1.9.2 BUT not for Gecko 2

Reproducible: Always

Steps to Reproduce:
1.cleared cache
2.re-started system
3. installed SeaMonkey 2.0.12
4. hardware acceleration on/off

Actual Results:  

When logon with FF 4.0 just a black box is presented although when one places the cursor on any face the cursor changes from a pointer to a hand thus indicating something is there BUT nothing is seen



Expected Results:  
The results are the same. works in FF 3.6 but not in FF 4.0.

The 3D cube should show all three faces with video.

The better way to verify this is to log onto the page with FF 3.6 or SeaMonkey 2.0.1 then logo on to the page with 4.0RC1 or 4.0ß12 or Minefield.
Severity: critical → normal
Regression range on Linux:  2010-11-10-03 -- 2010-11-11-03
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df1d1ff6b489&tochange=0f17e5f1eb01
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
QA Contact: general → plugins
Summary: This page works in FF 3.6 BUT does not in FF 4.0 → Flash plugin with CSS transform works in FF 3.6 BUT does not in FF 4.0
Version: unspecified → Trunk
I can see a problem. I see a similar problem on mac, but mac repaints itself if you scroll up and down a bit. Windows does not. Needs some debugging. wmode=opaque

It would be helpful if this was a smaller testcase that didn't use script to create the <object>, but was just straight up HTML/CSS/<object>
Attached file Testcase
Minimized testcase that does not use any JavaScript. Verified that it works in 3.6 but fails on trunk
Keywords: testcase
http://office.smedbergs.us/flash-css-transform-testcase.html has enough files (needed player.swf) to actually test with.

roc, now that plugins have their own layer, is the CSS transform a problem because it requires readback?
I had forgotten to indicate that the player used is the JWPlayer from Longtailvideo, I apologise for this ommission.

I can supply a copy of the player and the js file that I used when I had originally reported this bug.

thanks
Willie also mentioned this support link in private email:

https://support.mozilla.com/en-US/questions/791325#answer-145766

Any workarounds?

/be
blocking2.0: --- → ?
These is no way we're going to block on CSS transforms of plugins... it's very much an edge case!
blocking2.0: ? → -
Keywords: compat
Ok,, I need to be clued in here.

What is an edge case?  Can you elaborate, please?

As I see it if it works with Gecko 1.9.1 and 1.9.2 and not in Gecko 2 then something has changed in/with Gecko 2.  What has changed for this to occur and then is this change correctable?
This is something of a dejavu for me going back to 1996-1998 with JavaScript.

If one compares using 3.6 which works and then with 4.0 then it seems like a 'hook', or 'door' is not opened or there.  why?

When looking with 4.0 although nothing appears to be showing YET there is there something there;  for if you place the mouse cursor on any of the cube's faces there is a change of the cursor from default to the hand and then perform a mouse click nothing happens.

Doing the same with 3.6 it will begin to play the video.
I believe we explicitly disabled display of *windowed* plugins inside transforms, since they can't actually be transformed.  (roc would know for sure.)

But if wmode=opaque, then it shouldn't be windowed, right?


Could we somehow be hitting this code in nsObjectFrame::BuildDisplayList:

#ifndef XP_MACOSX
  if (mWidget && aBuilder->IsInTransform()) {
    // Windowed plugins should not be rendered inside a transform.
    return NS_OK;
  }
#endif
> What is an edge case?

Something that is done only very rarely.

> But if wmode=opaque, then it shouldn't be windowed, right?

I believe that's correct.
Attached file stack for plugin hide
The problem is that 'nsPluginInstanceOwner::mPluginWindowVisible' is false.
The root cause for that is the optimization in GetPluginGeometryUpdates,
which explicitly hides plugins still in 'closure.mAffectedPlugins'.
The reason it's still there is that RecoverPluginGeometry can't find
inside the nsDisplayTransform item.
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#2532
Attached patch Like so? (obsolete) — Splinter Review
This allows RecoverPluginGeometry() to find it and remove it from
'aClosure->mAffectedPlugins'.
Comment on attachment 518801 [details] [diff] [review]
Like so?

It passed unit tests on Try, fwiw.  I'll try to write a test for this.
Attachment #518801 - Flags: review?(roc)
I just wa\nted to let you all know that I have made an update to the page that is in question that doesnt however affect the issue at hand.

I have updated www.mirana.net/mediaXX.html to include a session message in addition to corrected and improving some of the code.

Further, I've added a second page www.mirana.net/mediaXX2.html that is essentially the same as mediaXX.html.

I've also added a 3rd page of the cube but this doesnt have any video on it so in this respect it doesn't apply

David Baron may have hit it on the nail as when I use FF4.0 and then on any of the black faces of the cube perform a right mouse click and then select 'toggle full screen' a full screen of the video can be viewed.  Btw, this also occurs with any of the other browsers that I test my web pages with.

I did notice one thing with FF3.6 namely that it will only work IF the wmode is set to opaque or transparent.

Now the question that comes to mind is since Adobe flash player 10.1 two additional modes have been made available namely; direct and gpu.

Will this also affect FF4.0?

I truly appreciate the effort that is being made in resolving this issue and for that I thank you all.

My ultimate goal, is to be able to showcase the '3D video cube' with FF 4.0 and I am not too concerned with the other browsers.

Thank You.
(In reply to comment #13)
> Created attachment 518801 [details] [diff] [review]
> Like so?
> 
> This allows RecoverPluginGeometry() to find it and remove it from
> 'aClosure->mAffectedPlugins'.

I don't think we should do this. It will lead to incorrect results because code that calls GetList() expects the coordinate system of the sublist to match the coordinate system of the outer list, which is not the case with transforms.

In this particular case I think it's OK though, since windowless plugins don't care about the geometry except for computing their visibility flag (or visible region in general). So I think we should add a method to nsDisplayItem, say GetPossiblyTransformedList(), which returns GetList() or the stored list for an nsDisplayTransform. The comment on nsDisplayItem::GetList() also needs to be improved to mention that if that returns a list, the list is in the same coordinate system as the item itself.
Assignee: nobody → matspal
Attached patch Patch rev. 2Splinter Review
Attachment #518801 - Attachment is obsolete: true
Attachment #518801 - Flags: review?(roc)
Attachment #522233 - Flags: review?(roc)
Oops, I just submitted a fix for this bug in bug 644832. I should have marked this as a dup already.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
I am confused here.

The bug that when I reported bug 640794 didnt have any dups as I checked prior to submitting the bug report.

So as I now understand it, if a fix has been created what happens now.

Will it appear in Minefield or?

I am somewhat in the dark here and would appreciate the steps and.or clarification that is involved
(In reply to comment #19)
> The bug that when I reported bug 640794 didnt have any dups as I checked prior
> to submitting the bug report.

Sorry, the other bug was filed later but I duped this one to the later bug since the later bug has a patch.

> Will it appear in Minefield or?

The fix will be reviewed and landed on trunk. It will probably appear in Firefox 5, which should be a few months away.
I don't understand this since 640794(2011-03-10) comes before 644832(2011-03-25).
Right.  The other bug was filed later, as roc said.  The reason the dup goes in the direction it does is that the other bug had a fix attached before it was realized that it's the same issue as this bug.
Doesn't make any logical sense to me when something gets reported first then it is marked as a dup to a report submitted later the latter should be the dup
When all else is equal, new bugs get marked as dups of older ones.  But if one bug is closer to being fixed than the other, the one that's further from being fixed is marked as dup.  Taken to its logical extreme, if bug A is fixed, then bug B will be marked as a dup of bug A, even if bug A was filed later.

This is pretty clearly documented at https://developer.mozilla.org/en/Screening_duplicate_bugs#Which_is_the_Duplicate.3f which is the first google hit for "bugzilla duplicate" and "mozilla bugzilla duplicate", for what it's worth....
It's really not worth worrying about which bug is duped to what. The important thing is that the bug be fixed.
Attachment #522233 - Flags: review?(roc)
Out of curiosity when will the fix be applied?  FF5 to be released in June? 

and how will one know that the fix has been applied?
Firefox 5. You can try an Aurora build right now; if it works in Aurora, it will work in Firefox 5.
This works fine in Aurora. Aurora build can be found here:
http://www.mozilla.com/en-US/firefox/channel/
Thank you for that info

Yes, after d/l Aurora it works very well, happy that it got fixed.
This certainly is one up on Chrome as it doesnt work in Chrome.

It was at Brendan's suggestion, after emailing him rehashing old times together from the Netscape era, that I report this issue in Bugzilla on March 10.

I am glad that I did.

Unrelated, when will FF support CSS 3D?
note that it does not work in the beta
What doesn't work? wmode="transparent" should work in a transform, wmode="window" (or just omitted) should NOT work in a transform.
ok, i guess i need to read up on default parameters, i was miffed at why it didn't work with google's default embed code for youtube videos, while it does work with -webkit-transform
I've experimented with Chrome and -webkit-transform and plugins kinda work if the transform is a translation and nothing else, and they break completely if there's anything other than a translation.
It is interesting to note that the same day that I reported this bug on March 3, 2011 which later was fixed in FF55; I did report it to Chrome.

As of today, this bug still remains with Chrome.

The example in question now works in FF, Safari(windows), 
surprisingly in IE9(32 & 64) but totally breaks down in Chrome
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: