Open Bug 1506065 Opened 6 years ago Updated 2 years ago

[Win] Liveleak - few video frames played after rightclick on share_link overlay

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Platform:
All
Windows
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr60 --- affected
firefox63 --- affected
firefox64 --- affected
firefox65 --- affected

People

(Reporter: cfogel, Unassigned)

Details

Attachments

(2 files)

liveleak_rightClick.gif
4.09 MB, image/gif
Details
test.html
624 bytes, text/html
Details
Attached image liveleak_rightClick.gif — 
[Affected versions]:
- 63.0.1, 64.0b7, 65.0a1 (2018-11-05);

[Affected platforms]:
- Win 10x64; Win 7;
 
[Steps to reproduce]:
1. Launch Firefox;
2. Access any video from liveleak.com; ex: https://www.liveleak.com/view?t=9syly_1541528379
3. Click on Play;
4. Right Click anywhere on the video to bring up the share overlay;
5. Right Click anywhere on the video, even the socialMedia_share/X links;

[Expected result]:
- Nothing happens;
- that is the behavior on other browsers as well;

[Actual result]:
- the video plays for a few more frames;
*audio included

[Regression range]:
- not a regression;
Checking for regression, on older versions the issue was harder to reproduce; the overlay is removed on the second right-click;
- date of changes: 2014-05-16 
pushlog URL: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58c5a3427997&tochange=2893f60d5903

[Additional notes]:
- attached gif with the issue;
- another issue, but that might be caused by this is that after scrolling down and repeating steps 4+5 the video is no longer positioned to the side;
cfogel, can you still reproduce the problem or has the site fixed it?

I can't reproduce the problem. The first right click brings up the overlay. The next right click removes the overlay and the video continues normally.
Flags: needinfo?(cristian.fogel)
Still reproducible with 65.0a1(20181119220031) - Win10x64.

Even as you describe it, there is still a difference from Chrome/IE with the behavior. With the other 2 browsers mentioned, the video keeps the overlay on the second right-click.
Flags: needinfo?(cristian.fogel)
Indeed, I can also reproduce that on macOS, I suspect a web compatibility issue.
Flags: needinfo?(miket)
Priority: -- → P3
inline, there's some js setting up a contextmenu event handler:

$('#player_file_91N5l_1541528286').on('contextmenu', function(e) {
  e.preventDefault();
  $('.vjs-share-button').click();
});

The .vjs-share-button element is hidden inside the gear menu.

Let me redirect to Tom to dig in.
Flags: needinfo?(miket) → needinfo?(twisniewski)
Attached file test.html —

After adding some console logging to their jquery instance to see what handlers are being called, I found that the important handler is this one right in their markup:

$('#player_file_91N5l_1541528286').on('contextmenu', function(e) {
    e.preventDefault();
	$('.vjs-share-button').click();
});

This ends up "clicking" on an element, which is detected by JS handler in a surprisingly obfuscated script: https://ne1.wac.edgecastcdn.net/80281E/ll_as_u1/misc/videojsn/nuevo_ll3.min.js

Ultimately that handler shows the share prompt, then sets another click handler which will clear the prompt the next time a click event happens on the window:

    jQuery(window).bind(setEvent('click'), function(e) {
        e.preventDefault();
        jQuery(window).unbind(setEvent('click'));
        jQuery(share_overlay).addClass('vjs-hidden');
        settings.isAddon = false;
        thiso.pauseLock = false;
        if (player_state != true) player.play()
    })

However, Chrome and Firefox differ in how they will handle this case.

When a contextmenu event is fired, although its default action is prevented (in the first script-fragment I showed above), Firefox stills send a subsequent click event after the user releases the mouse button. This causes the script's clean-up click handler to trigger, closing the dialog.

Chrome will not fire the second click event, so the dialog remains open.

I've attached a test case to show the different behavior.

I'm actually not sure what the best fix would be for the site. They could wrap their click() call in setTimeout, but there's no guarantee that they will wait long enough for Firefox to potentially fire its click event. They could potentially listen for an extra click event if they sniff Firefox, but that would break if/when we fix this interop issue.

Thoughts, Mike?

Flags: needinfo?(twisniewski) → needinfo?(miket)

When a contextmenu event is fired, although its default action is prevented (in the first script-fragment I showed above), Firefox stills send a subsequent click event after the user releases the mouse button. This causes the script's clean-up click handler to trigger, closing the dialog.

Chrome will not fire the second click event, so the dialog remains open.

Hsin-Yi, do you know if we have a bug on file for this?

Flags: needinfo?(miket) → needinfo?(htsai)

(In reply to Mike Taylor [:miketaylr] from comment #6)

When a contextmenu event is fired, although its default action is prevented (in the first script-fragment I showed above), Firefox stills send a subsequent click event after the user releases the mouse button. This causes the script's clean-up click handler to trigger, closing the dialog.

Chrome will not fire the second click event, so the dialog remains open.

Hsin-Yi, do you know if we have a bug on file for this?
Seems this one https://bugzilla.mozilla.org/show_bug.cgi?id=990614#c3

Flags: needinfo?(htsai)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: