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?

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?

(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