Video/audio wrongly starts playback when sent with "Add to queue" if previously a Vimeo played video was in "Replay/Close" screen

[SoftVision-CarmenFat]

[Affected versions]:

• Firefox 54.0.1 and up
• Min-Vid 1.0.10

[Affected Platforms]:

• All Windows
• All Mac
• All Linux

[Prerequisites]:

• Latest Min-Vid add-on (1.0.10) was previously installed on a clean profile.

[Steps to reproduce]:

1. Open the browser with the profile from prerequisites and navigate to www.vimeo.com
2. Send a video to the Min Vid player and wait to end.
3. Send another video (or audio) to the player from "Add to queue" button and observe what happens next.

[Expected result]:

• Video/audio added through "Add to queue" does not start playback automatically.

[Actual result]:

• Video/audio added through "Add to queue" starts playback automatically.

[Notes]:

• Attached a screen cast of the issue:

[meandavejustice]

I think this was fixed in https://github.com/meandavejustice/min-vid/pull/951 pretty sure it was an underlying bug in the audiosource package

[SoftVision-CarmenFat]

I have retested this issue and is still reproducible on the build made from sdk-to-webextension branch (built on 7/8/2017).

[meandavejustice]

I see what's going on here, it has to do with the way we are forwarding the videos in replay view and a race condition with the video added to queue. This will take some time to rework around the current hack. Since this is an edge case and is probably unrelated to the sdk conversion, I'm going to push it out of this milestone.