overlordq wrote:

I found that if I skip the code on lines 613 through 622 that attempt to use an iframe it will embed the applet successfully, only when trying to embed the applet on an iframe will it not appear.

Ugh, this ain't good. Also breaking on Firefox 3.1b3 (where native <video> does work, but isn't default yet)

mdale wrote:

the java issue seems to be with iframe invocation method. fixes in:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/48449

Also if you have ogg plugin support firefox is taking over the <object type="audio/ogg" or type="video/ogg"> resulting in a weird invocation with scroll bars ... for the default usage.

I recommend we bump up <video> tag since many people expect to use native support when visiting the site with the beta firefox builds.

As noted I also committed a test against safaris crippled support of the video tag pre bug 13421 (via gmaxwells recommended fix) .. I tried to test in windows nightly safari builds .. but they don't seem to support the video tag at all. If we can find an OSX person to test... that would be good.

I'm seeing on Safari 3.2.1/Mac:

"Sorry, your system does not appear to have any supported player software. Please download a player."

Something's odd...

Since this has working Java *and* Ogg components for QuickTime, it ought to be working with all the following methods:

• Java
• QuickTime
• <video>

r48457 fixed the Safari buggage. Was relying on <video> type checks that are only implemented in WebKit nightlies, not in current release versions. Adding a try/catch block prevents this from killing the rest of the checks, so it correctly falls back to the Java player now. Yay!

And... looks good on FF 3.0.7 and 3.1b3/Mac.

Reopened, the proposed fix is wrong and broken.

There's probably 2-3 bugs here on the Mozilla side:

• The fact that the iframe is necessary in the first place (even in 3.0.7)
• The breakage of various methods of iframe creation between 3.0.6 to 3.0.7, including data: and javascript: protocol URLs
• Spurious errors of the form "Permission denied to get property XULElement.accessibleType" for the remaining methods of iframe creation

r48477 should fix it for now, until Mozilla introduces the next creative breakage for Java applet embedding. Attempting to isolate these Mozilla bugs to the point where they might not be ignored on the Mozilla bug tracker can wait until another day (or until someone else cares to look at it).

At least with FF 3.1/3.2/3.5 we'll be able to ditch the Java applet platform in favour of video elements.