Closed Bug 821304 Opened 12 years ago Closed 12 years ago

[Mac OS] Shockwave games no longer work in FF 18

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
18 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox17 unaffected, firefox18+ verified, firefox19 verified, firefox20 verified, b2g18 fixed)

Status:
VERIFIED FIXED
Milestone:
mozilla20
Tracking Flags:
Tracking Status
firefox17 --- unaffected
firefox18 + verified
firefox19 --- verified
firefox20 --- verified
b2g18 --- fixed

People

(Reporter: pauly, Assigned: smichaud)

References

Details

(Keywords: regression)

Attachments

(1 file)

Fix
3.13 KB, patch
BenWa
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review
http://www.miniclip.com/games/ice-hockey-heroes/en/ http://wickedgoodgames.com/shockwave.shtml Actual results: Blank plugin screen when trying to play shockwave games. Tested on FF 18b4 on Mac OS X 10.7.4, 10.8.2. This is Mac OS related only. Works fine in FF 17.0.1. I'll come back with a regression range.
Last good nightly: 2012-10-17 First bad nightly: 2012-10-18 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5
Steven, could this be a side effect of bug 794038?
It's possible, I suppose, but it seems unlikely. Could you bisect to find out exactly which patch triggered the problem? I can get to this eventually, but right now I'm totally swamped.
> Could you bisect to find out exactly which patch triggered the problem? And if the trigger *is* one of the patches for bug 794038, it might be helpful to find out exactly which one.
Georg - can you help out here? Given the user impact here, this may be our highest priority Firefox 18 issue at this point.
Assignee: nobody → georg.fritzsche
tracking-firefox18: ? → +
I already started bisecting.
(In reply to Georg Fritzsche [:gfritzsche] from comment #6) > I already started bisecting. Any update here ?This is our top issue right now, before we goto build for FF18 beta 5,tomorrow.
I hope to finish my work on 800948 today (which has been ongoing for several weeks). So I should be able to get to this bug starting tomorrow. I respectfully suggest, though, that it's very unlikely this bug can be fixed by tomorrow -- even if Georg starts right away spending 100% of his time on it. The earliest we can reasonably hope for a fix is beta 6.
Right, tomorrow is very unlikely. What i know is that this is apparently limited to the Shockwave Director plugin (at least the linked games are). It's worth noting that the plugin is i386 only, so a universal build instead of the default x86_64 only is required. My local attempt to build the universal one per the release configs failed, so i'm currently running some try jobs.
> My local attempt to build the universal one per the release configs failed See bug 733905 comment #62. That should work on OS X 10.7 and up (with sufficiently recent versions of XCode and its command-line utilities). If you're building on OS X 10.6, though, even I haven't yet figured that out :-(
(In reply to Georg Fritzsche [:gfritzsche] from comment #9) > It's worth noting that the plugin is i386 only, so a universal build instead > of the default x86_64 only is required. My local attempt to build the > universal one per the release configs failed, so i'm currently running some > try jobs. Does this mean that you'd have to be running Firefox as a 32-bit app to use Shockwave?
QA Contact: jbecerra
(In reply to Steven Michaud from comment #10) > See bug 733905 comment #62. That should work on OS X 10.7 and up (with > sufficiently recent versions of XCode and its command-line utilities). That config over there worked, thanks. I must have been doing something wrong when i adapted the universal nightly config. (In reply to Alex Keybl [:akeybl] from comment #11) > Does this mean that you'd have to be running Firefox as a 32-bit app to use > Shockwave? No, but it at least needs a 32-bit plugin-container process. In a 64bit-only build i wouldn't have that one.
(In reply to Georg Fritzsche [:gfritzsche] from comment #12) > (In reply to Alex Keybl [:akeybl] from comment #11) > > Does this mean that you'd have to be running Firefox as a 32-bit app to use > > Shockwave? > > No, but it at least needs a 32-bit plugin-container process. In a 64bit-only > build i wouldn't have that one. We build both firefox-bin and plugin-container 32/64-bit, so I'm still not clear. Will this impact all Mac OS X release users who also use Shockwave?
(In reply to Alex Keybl [:akeybl] from comment #13) > We build both firefox-bin and plugin-container 32/64-bit, so I'm still not > clear. Will this impact all Mac OS X release users who also use Shockwave? This impacts all release users who wants to use the shockwave plugin. The plugin is 32bit but it can be used on a 64bit OSX if a universal 32/64 bit Firefox build is used. All Firefox release builds are universal builds. Georg has problems with his own build that he wants to use to find the checkin that caused this bug (via "hg bisect") The default config for a self compiled build on OS X 64bit is a 64bit Firefox and not an universal build (32/64 combined) btw: That's the reason why I bisected and failed to find the checkin.
I'll start on this bug tomorrow. But you guys will have to wait til then. I need a break, and some sleep.
It's in this m-i -> m-c merge: http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=a76c1f4c4112 The debug builds are really broken (nothing drawn and no sound for the whole nightly range) and hit "null plugin instance during PaintPlugin": http://hg.mozilla.org/mozilla-central/file/62f61773ad45/layout/generic/nsObjectFrame.cpp#l1795 ... but as they are broken earlier already, i'm not sure if that's related.
bad: http://hg.mozilla.org/mozilla-central/rev/eaccb5bb50c0 good: http://hg.mozilla.org/mozilla-central/rev/e7497bc33b3c (universal opt build, tested on osx 10.8) That exactly covers the revisions for bug 794038. I'll build eaccb5bb50c0 locally and try figuring out which of the changes is triggering this.
CCing Jonathan per bug 794038.
Georg, if you don't mind I'll take this bug now. I've got a nice fast machine to build on, and it seems this bug was triggered by one of my patches.
Assignee: georg.fritzsche → smichaud
Sure, go ahead :) The build-times on my Mac are definitely too long for dealing with universal builds.
FWIW, neither the miniclip nor wickedgoodgames are working for me in FF 17.0.1, either. I have Shockwave Flash 11.5.502.136 and Shockwave for Director 11.6.8r638 installed, both of which claim to be up-to-date. This is on a retina MBPro with 10.7.4.
I get the same results as Jonathan with http://www.miniclip.com/games/ice-hockey-heroes/en/ (it doesn't work in FF 17.0.1, though it does work in FF 16.0.1), but not with the games at http://wickedgoodgames.com/shockwave.shtml (Ant Run works in FF 17.0.1 but not in a recent nightly). I have the same versions of Flash and Shockwave, and am also running OS X 10.7.4 on a Retina MacBook Pro. I'll keep digging.
(In reply to Steven Michaud from comment #22) > I get the same results as Jonathan with > http://www.miniclip.com/games/ice-hockey-heroes/en/ (it doesn't work in FF > 17.0.1, though it does work in FF 16.0.1) It works for me in FF 17.0.1 on a non-Retina-Mac, OS X 10.8.2
Georg, Jonathan: By any chance do you have an external monitor attached (HiDPI or non-HiDPI)? I don't (though I have one I can test with).
I have two external non-HiDPI monitors (Mac mini here).
(In reply to Steven Michaud from comment #24) > Georg, Jonathan: By any chance do you have an external monitor attached > (HiDPI or non-HiDPI)? No, I'm running the retina-MBP standalone.
Testing with the Ant Run game (http://wickedgoodgames.com/shock/gm1.html) I find this bug has two different regression ranges -- one HiDPI mode on, the other with HiDPI mode off. But each implicates one of my HiDPI-mode-plugin-support patches, so I'm the right one to be working on this bug. Regression range in HiDPI mode: firefox-2012-10-02-03-05-26-mozilla-central firefox-2012-10-03-03-05-45-mozilla-central http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85dd8e346102&tochange=635fcc11d2b1 Regression range with HiDPI mode off: firefox-2012-10-17-03-05-48-mozilla-central firefox-2012-10-18-03-06-18-mozilla-central http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dac5700acf8b&tochange=cb573b9307e5 I'll be working on this. One thing I'll need to figure out is how this bug can happen with HiDPI mode off. I probably won't have anything more to say until sometime tomorrow.
Our highest priority is to fix Shockwave for users on non-retina Macs. If this was only impacting retina MBPs, we'd wontfix for FF18 already. This is one of a very small handful of fixes that we're targeting for our final beta (going to build 12/27).
I've figured this out, and should have a patch by tomorrow. The executive summary is that Shockwave plugins can't be displayed at full HiDPI resolution if we're compiling with the 10.6 SDK (as we should for compatibility with OS X 10.6.X). I'd already discovered this is true for any OOP plugin that uses CoreGraphics mode (which we implement using our CGBridgeLayer subclass of CALayer). The work that remains is figuring out exactly how to detect plugins (or more specifically CALayer subclasses) whose contentsScale property we shouldn't manipulate unless we're compiling with the 10.7 SDK or above.
(Following up comment #29) When we try to manipulate Shockwave's CALayer subclass's contentsScale property it stops working.
Attached patch Fix — — Splinter Review
This patch extends my existing workaround for the CGBridgeLayer subclass of CALayer (which we use to implement CoreGraphics mode for OOP plugins). There's almost certainly nothing we can do to get HiDPI resolution working with plugins that use CALayer subclasses when we compile with the 10.6 SDK. But there *may* be something we can do to get HiDPI resolution working with CAOpenGLLayer (or its subclasses) when we compile with the 10.7 SDK or above. I'll look further into this next year. In the meantime it's better to display plugins in non-HiDPI resolution than it is to either display them not at all or at the wrong size. I'm quite sure bug 823537 is a dup of this bug, but I haven't yet got confirmation.
Attachment #694465 - Flags: review?(bgirard)
Fortunately Flash and Silverlight use a layer that belongs to the CALayer class. So they aren't effected by this bug, and won't be effected by my patch for it.
I've started a tryserver build for my patch from comment #31, which should be available in an hour or two.
Attachment #694465 - Flags: review?(bgirard) → review+
Comment on attachment 694465 [details] [diff] [review] Fix [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 785667 and bug 794038 part 3 User impact if declined: Shockwave, SlingPlayer and possibly other plugins broken Testing completed (on m-c, etc.): Moderate testing by myself here and others at bug 823537 Risk to taking this patch (and alternatives if risky): low risk String or UUID changes made by this patch: none
Attachment #694465 - Flags: approval-mozilla-beta?
Attachment #694465 - Flags: approval-mozilla-aurora?
> Bug caused by (feature/regressing bug #): bug 785667 and bug 794038 part 3 A workaround for an OS bug in those patches didn't have wide enough scope.
Attachment #694465 - Flags: approval-mozilla-beta?
Attachment #694465 - Flags: approval-mozilla-beta+
Attachment #694465 - Flags: approval-mozilla-aurora?
Attachment #694465 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/81de116c12ad
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Works fine in Nightly 2012-12-26 Mac OS X 10.8.2. Verified fixed Waiting for 18b6.
status-firefox20: fixed → verified
Verified fixed FF 18b6 Mac OS X 10.7.5
status-firefox18: fixed → verified
Re comment #31, I'm working on a plugin that uses core animation with a vanilla CALayer and ran into exactly this issue (works on FF 17, nothing is rendered on FF18). I was able to work around it by creating an empty subclass implementation. It is building against the 10.7 SDK but with -mmacosx-version-min=10.5. I tried switching min version to 10.7, but I still get no rendering without the workaround. If you have any other potential fixes, I'd be happy to test them out!
(In reply to comment #44) Your problem may turn out to be more closely related to bug 829284. I'm about to post a patch there (and a tryserver build) -- sometime later today, I hope.
I'm testing on a non-retina MBP.
Also, if it helps - the CALayer is receiving a CGImage as is .contents, so I don't directly modify anything about the layer (besides setting contentsScale and clearing out the frame to frame transition animation).
Sorry, typed that too fast. I'm setting .contentsGravity, I don't modify contentsScale.
(In reply to comment #46 and comment #47) OK, so the patch for bug 829284 probably won't help (though it's available now, and you should still try it). If your plugin is publicly available (to test with), and it has specific, reproducible problems in Firefox that it doesn't have in other browsers, you should open additional bugs on each one. > the CALayer is receiving a CGImage as is .contents As far as I know this shouldn't make any difference. Firefox code doesn't play with (or even look at) any plugin CALayer's "contents" or "contentsGravity".
(In reply to Steven Michaud from comment #49) Thanks Steven, I just added a comment on bug 829284 to let you know that the tryserver build *does* fix the issue for me. > If your plugin is publicly available (to test with), and it has specific, reproducible problems in Firefox that it doesn't have in other browsers, you should open additional bugs on each one. Not publicly available yet, but it will be soon.
Verified fixed FF 19b4 Mac OS X 10.8.2
Status: RESOLVED → VERIFIED
status-firefox19: fixed → verified
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: