Clicking on the quick tour movies on the linked page should select a new movie, but it opens a new page with the first one instead. Happens in the nightly build from yesterday, but not in the 10.4.2 version of Safari.
This is happening because the behavior of document named elements in WebKit was changed to match IE, but in this case it doesn't: IE considers an object element with and id as a named element (roughly) only if the object's only children are param elements, while WebKit does not make this check. (I'm tempted to raise the bug priority since it affects a high-profile website).
Created attachment 4418 [details] testcase
Comment on attachment 4418 [details] testcase IE6 prints "undefined" on the 3rd and 6th lines (param and text).
P1 anyway since it's a regression.
Created attachment 4419 [details] approximate IE's behavior One difference that I'm aware of is that IE doesn't allow HTML comments inside the object and this patch allows them (since they're not in the DOM tree).
Created attachment 4420 [details] extended testcase
Comment on attachment 4419 [details] approximate IE's behavior Unfortunately, this patch does not fix the problem with the Aperture page (which is also broken in IE; I guess it was written to work with WebKit 412).
Comment on attachment 4419 [details] approximate IE's behavior Great to have a patch and a test case, but if this patch won't fix the Aperture site then we probably need a separate bug report about the site being broken. We can maybe get the site changed to be compatible with both versions of WebKit.
Created bug 5449.
This bug may be related to <rdar://problem/4214080> document.embeds: embeds[0].Play() undefined at languageguide.org prevents audio playing on mouseover.
Given what we now know about this, it might be necessary to get the Aperture team to revise their site. We should propose something to them that will work on WinIE, the newer Safari, and also the older Safari.
getElementById will work in every other browser as a way to get a specific element and we should recommend that to the Aperture team.
Now that bug 5449 is fixed, this Apple page: http://www.apple.com/imac/tour/ is also broken in TOT.
This one too: http://www.apple.com/ipod/features.html
Just created a Bugzilla account and started tracking this. Thanks for the great reports so far. You are correct we had planned this for 412, where referencing the QT by name was the only way compatible with Safari at the time. Comment 12 is correct that now, getElementById will work with browser, but this is not the case for older builds of Safari. Please assign this to me.
i've found that referencing the quicktime movie object by id is now working as expected in safari, but only referencing the movie by document['name'] is working in firefox. firefox assigns the object HTMLObjectEmbed to the id when using getElementById, but views it as the parent container of the embedded "embed" object and therefore won't permit the .Play() method. I'm still hacking away at this, but if anyone has any ideas please share them.
(In reply to comment #16) How about giving IDs (obviously distinct) to both elements (object and embed) and then choosing the one that implements Play. Something along the lines of: Aperture.QTMovie.obj = document.getElementById('pmObj').Play ? document.getElementById('pmObj') : document.getElementById('pmEmbed');
Turns out you can't detect the availability of methods in the activex quicktime component (i.e., if(obj.GetPluginStatus)) as you can in other implementations of quicktime, but you can still call those methods (i.e., obj.GetPluginStatus()). So, now that we know that, we've fixed the object assignment, and only had to incorporate a few things to get it working properly: 1. Keep looping until the pluginstatus changes to "playable" or "complete" before attempting to play the movie 2. Wait 1000ms before actually playing the movie. I don't really know why this is necessary -- maybe Eric Carlson can chime in -- but it's the only way we can get it to work as needed. http://www.apple.com/aperture/quicktours/
s there a radar tracking the problem with the other two pages mentioned above (imac/tour/ and ipod/ features.html)? If so, I think this WebKit bug can be changed to RESOLVED. I think a similar solution can apply to the above two pages (which are very similar to one another).
I contacted Justin, and there are Radars tracking the other two pages. Tim, you can close this bug if you like.