853435 - Real Player breaks HTML5 videos

Status: RESOLVED FIXED

Description

[Simona Badau [Away. Please needinfo? Alin Deac [:alindeac]]]

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.

Comment 1

[Jorge Villalobos [:jorgev]]

Dave, can you please look into this?

Comment 2

[Simona Badau [Away. Please needinfo? Alin Deac [:alindeac]]]

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

[Alex Keybl [:akeybl]]

Michelle was able to help us get similar issues prioritized in the past. Adding her here.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 5

[Jorge Villalobos [:jorgev]]

We're looking into this with the Real Player people.

Comment 6

[Jorge Villalobos [:jorgev]]

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

[Benjamin Smedberg]

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.

Comment 8

[Anthony Hughes (:ashughes) [QA]]

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

[Benjamin Smedberg]

I'd say that's pretty close to the expected behavior.

Comment 10

[Alex Keybl [:akeybl]]

Given the fact that this is being fixed externally, we'll untrack.

Comment 11

[Jorge Villalobos [:jorgev]]

I think there's no further action to take here.