Closed
Bug 853435
Opened 10 years ago
Closed 10 years ago
Real Player breaks HTML5 videos
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
People
(Reporter: simona.marcu, Unassigned)
References
Details
Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130320 Firefox/22.0 Build ID: 20130320031103 Steps to reproduce: 1. Launch Firefox 2. Navigate to http://eu.real.com/ download the latest Real Player and install it 3. After the restart - allow the RealDownloader 1.3.1. add-on to install - restart the browser when prompted 4. Navigate to http://www.mozilla.org/en-US/contribute/ and click on the Play button. Expected results: The video plays fine. Actual results: On Firefox 20 beta 6 and on the latest Aurora - the video's controls are lost and the context menu is not accessible. On the latest Nightly - the video's content is black. Note: The issue is reproducible also on Firefox 4.0.1. The RealDownloader 1.3.1 add-on is installed with the latest version of the Real Player (16.0.1.18). If the add-on is disabled the videos are not affected in any way so I'm suggesting a blocklisting.
Updated•10 years ago
|
tracking-firefox20:
--- → ?
Reporter | ||
Comment 2•10 years ago
|
||
Tested also with older versions of Real Player and got the following results: - with Real Player 16.0.0.282 - the RealDownloader 1.3.0 add-on is installed and the issue is reproducible; - with Real Player 15.0.6.14 - RealPlayer Browser Record Plugin 15.0.6 is installed and disabled per default, after enabling it the issue is reproducible. - with Real Player 12.0.1.633 - RealPlayer Browser Record Plugin 14.0.2 is installed and disabled per default - the issue is not reproducible.
Comment 3•10 years ago
|
||
Michelle was able to help us get similar issues prioritized in the past. Adding her here.
Comment 4•10 years ago
|
||
We talked about this at the channel meeting today and Jorge will try direct communication channels with Dave (not bug comment) in order to get an investigation going on what other options we might have other than blocklisting in the FF20 release timeframe. Note that we are one week away from shipping FF20.
Updated•10 years ago
|
status-firefox20:
--- → affected
status-firefox21:
--- → affected
status-firefox22:
--- → affected
tracking-firefox21:
--- → +
tracking-firefox22:
--- → +
Comment 5•10 years ago
|
||
We're looking into this with the Real Player people.
Comment 6•10 years ago
|
||
The latest message I got from them said this (with a few edits): ------ The plugin is a transparent windowless window that resides on top of the web page video. Events are not getting passed through our plugin to the video underneath. As far as we’ve been able to ascertain, we are following the correct recipe to enable events to be passed through - as described by the following Mozilla documentation: https://developer.mozilla.org/en-US/docs/Gecko_Plugin_API_Reference/Drawing_and_Event_Handling https://developer.mozilla.org/en-US/docs/NPP_HandleEvent 1) Use NPN_SetValue() to make the plugin window windowless in NPP_New() 2) Use NPN_SetValue() to make the plugin window transparent immediately after setting it windowless 3) Returning false in NPP_HandleEvent to indicate that we have not handled the event. Do those seem like the correct steps for passing events through windowless transparent windows? Could bug 182299 be relevant? ------ I looped in Benjamin but I haven't heard from him in that thread. Is there anyone else who can help answer these questions?
Comment 7•10 years ago
|
||
I'm sorry, I didn't see that email. I think the developers of this plugin have a misunderstanding of how DOM event propagation works. They are modifying the DOM structure of the page like so: <div> -- page container <div id="RDHTML5Video"> -- inserted by the toolbar <object id="RDHTML5Video_Plugin_0"/> -- inserted by the toolbar </div> <video.../> -- page element </div> The <div id="RDHTML5Video"> is absolutely positioned over the <video> with a z-index of 100. So when a click reaches the <object> element and that returns false from NPP_HandleEvent, it is dispatched to the next visible element at that location, which in this case is the injected <div>. There is no bug in Firefox here.
I was asked to test a prototype of RealDownloader 1.3.2. Using the following testcases: * http://mozqa.com/data/firefox/video/test_ogv_video_nosound.html * http://mozqa.com/data/firefox/video/test_webm_video_nosound.html With RealDownloader 1.3.1 installed, when I click "play": * Firefox Nightly 22.0a1 2013-03-20 just shows a black frame * Firefox Aurora 21.0a2 2013-03-20 just shows the first frame * Firefox Beta 20.0b6 2013-03-20 just shows the first frame With RealDownload 1.3.2 installed, when I click "play": * Firefox Nightly 22.0a1 2013-03-20 hangs 10s on 1st frame then plays the video * Firefox Aurora 21.0a2 2013-03-20 hangs 10s on 1st frame then plays the video * Firefox Beta 20.0b6 plays the video immediately If I update Firefox to the latest, when I click "play": * Firefox Nightly 23.0a1 2013-04-26 plays the video immediately * Firefox Aurora 22.0a2 2013-04-26 plays the video immediately * Firefox Beta 21.0b4 hangs briefly on 1st frame then plays video * Firefox 20.0.1 hangs briefly on 1st frame then plays video I would say that RealDownloader 1.3.2 is an improvement but does not resolve this issue completely.
Comment 9•10 years ago
|
||
I'd say that's pretty close to the expected behavior.
Comment 10•10 years ago
|
||
Given the fact that this is being fixed externally, we'll untrack.
Comment 11•10 years ago
|
||
I think there's no further action to take here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•