WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
61229
REGRESSION (
r70748
): WebKit cannot play QuickTime movies on Mac OS X Wiki Server pages
https://bugs.webkit.org/show_bug.cgi?id=61229
Summary
REGRESSION (r70748): WebKit cannot play QuickTime movies on Mac OS X Wiki Ser...
Andy Estes
Reported
2011-05-20 17:19:00 PDT
WebKit cannot play videos created by Podcast Producer.
Attachments
Patch
(6.24 KB, patch)
2011-05-20 17:32 PDT
,
Andy Estes
no flags
Details
Formatted Diff
Diff
Patch
(4.86 KB, patch)
2011-05-24 16:50 PDT
,
Andy Estes
ggaren
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Andy Estes
Comment 1
2011-05-20 17:20:32 PDT
<
rdar://problem/9440255
>
Andy Estes
Comment 2
2011-05-20 17:32:56 PDT
Created
attachment 94301
[details]
Patch
Darin Adler
Comment 3
2011-05-20 17:50:14 PDT
Comment on
attachment 94301
[details]
Patch It’s unfortunate that we need a rule that is not the same as what’s in HTML5. We should raise this issue with the HTML5 folks.
Andy Estes
Comment 4
2011-05-20 18:07:22 PDT
Committed
r87007
: <
http://trac.webkit.org/changeset/87007
>
Ademar Reis
Comment 5
2011-05-23 07:47:43 PDT
Revision
r87007
cherry-picked into qtwebkit-2.2 with commit c6d8071 <
http://gitorious.org/webkit/qtwebkit/commit/c6d8071
>
Andy Estes
Comment 6
2011-05-23 17:46:29 PDT
In the process of drafting an email to whatwg I convinced myself that this is the wrong approach to take. By permitting object elements with classids, we can end up loading content meant for an ActiveX component in a Netscape plug-in in certain circumstances (e.g. the url happens to have a file extension that a Netscape plug-in claims to support). Preventing a plug-in from loading content not meant for it is the rationale behind falling back for non-empty classids (even falling back to nothing). I don't think we should allow this to happen in general just because we happen to know that doing so is safe for this one case. I think a better approach for this case is to restore QuickTime's classid mapping (perhaps even wrapped with a site-specific hacks runtime guard). It seems safer to specifically permit loading QuickTime in this manner (under the assumption that content loadable in the QuickTime ActiveX component is also loadable in the NPAPI plug-in).
Andy Estes
Comment 7
2011-05-24 16:50:27 PDT
Created
attachment 94714
[details]
Patch
Geoffrey Garen
Comment 8
2011-05-24 17:03:12 PDT
Comment on
attachment 94714
[details]
Patch r=me
Jeff Miller
Comment 9
2011-05-24 17:10:37 PDT
Comment on
attachment 94714
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=94714&action=review
> Source/WebCore/html/HTMLObjectElement.cpp:250 > + if (!document()->page()
Is this a problem with Mac OS X Wiki Server, or with Podcast Producer specifically?
Andy Estes
Comment 10
2011-05-24 17:17:36 PDT
(In reply to
comment #9
)
> (From update of
attachment 94714
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=94714&action=review
> > > Source/WebCore/html/HTMLObjectElement.cpp:250 > > + if (!document()->page() > > Is this a problem with Mac OS X Wiki Server, or with Podcast Producer specifically?
It's a problem with any QuickTime movie hosted by Wiki Server.
Andy Estes
Comment 11
2011-05-24 17:48:06 PDT
Committed
r87244
: <
http://trac.webkit.org/changeset/87244
>
Ademar Reis
Comment 12
2011-05-25 11:36:57 PDT
Revision
r87244
cherry-picked into qtwebkit-2.2 with commit f8d4988 <
http://gitorious.org/webkit/qtwebkit/commit/f8d4988
>
Ryosuke Niwa
Comment 13
2019-03-11 23:14:39 PDT
I think we can remove this quirk now since OS X Sever shipped with Mountain Lion and later has been emitting video element as fallback.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug