User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 When I hit this page using FF3 beta 5 I get a warning about a missing plugin (which apparently is Shockwave but I can't check because of another FF3 bug). When I hit this same page using FF2 2.0.0.14 it works fine. I tried reinstalling Flash and Shockwave and verified that FF3 listed them as enabled plugins but this didn't help. The page still refuses to render properly. Reproducible: Always Steps to Reproduce: 1. 2. 3.

I see the same problem with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042902 Minefield/3.0pre. Somehow the EMBED element acquires a type="application/x-shockwave-J" attribute. But the src attribute points at http://www.ymap.co.il/ymapimg/Waiting.swf, which is correctly served as application/x-shockwave-flash, so I'd expect it to work.

For <embed>, @type takes priority over the server-provided type. That hasn't changed since Gecko 1.8, or at least shouldn't have... The type="application/x-shockwave-J" thing comes from the script on the page, which document.writes the <embed>. Looking at http://map.ymap.co.il/sdk_v3/atlasSDK.asp?Key=gjbnM9c62LAejQ9&SdkBuild=1_0_6 line 1 column 21675, we have: flashHtml+=' TYPE="application/x-shockwave-J"

Can we get a minimal testcase? Using the type attribute over the server provided one should not have changed since FF2, so it's weird that it works there.

So... What we _used_ to do on branch is use @type. Then if we had no plug-in enabled for that type, we fell back on the file extension from the URL, which in this case is "swf". So we'd allow the URI extension to override the type attribute if we didn't support the type specified in the type attribute. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp&rev=MOZILLA_1_8_BRANCH&mark=3873-3896#3873 for the code we used to have. Note that the bug# in that checkin comment is wrong; the correct bug is bug 163568. Not that it has a testcase or anything... In any case, the pluginhost code in question is still in place. But now, we never even get to trying to instantiate a plug-in, because of this code: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsObjectLoadingContent.cpp&rev=1.81&mark=1077-1079#1076 As a result, we only look at the URI extension for <embed> if the type attribute is missing. It would be pretty easy to change the !aTypeHint.IsEmpty() part to also check whether there is a plug-in enabled for that type. We might also need to change the logic in nsObjectLoadingContent::Instantiate in a similar way; not sure offhand. The question is whether we want to do that, I guess... Another option that would also solve this case is to not let the @type override the server type if we have a plugin enabled for the server type but not the @type. This might be a preferable solution to extending the extension-sniffing, and would also help this testcase...

Note that there is also the option of doing absolutely nothing here for 1.9. Not sure whether this sort of behavior is something we would want to change in a dot-release or whether any sort of change would need to wait for Gecko.next if we decide to do nothing for 1.9.0.0.

I think we should revert to doing what 1.8 was doing. I see no point in trying to do a half-way cleanup here. Ideally we should figure out a strategy that works for both <object> and <embed> and implement that early in a release cycle.

I don't think we can do the same thing for <object> and <embed>.... For <embed> (as here), I'm fine with reverting to the 1.8 "use extension if the type is not supported by a plug-in" behavior, esp. since <embed> doesn't usually support documents.

Comment on attachment 318523 [details] [diff] [review] Fix. Yeah, I think this does it. Since we set mContentType in the override case, we don't need to worry about changing Instantiate() to handle this.

Comment on attachment 318523 [details] [diff] [review] Fix. This makes us more compatible with Fx2 and other browsers in how we determine what plugin to use when dealing with embed tags in HTML. Super low risk, simply moving back to what we used to do.

Comment on attachment 318523 [details] [diff] [review] Fix. a1.9+=damons

Did this land?

Landing now...

Fix checked in.

verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050104 Minefield/3.0pre as well as the Win Vista nightly. I verified using the URL in the bug.