812922 - Detaching a tab containing a windowless Flash video results in Flash object misalignment relative to mouse coordinates

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[IU]

Attachment: windowless youtube test case

Because of OOPP, when you detach a tab containing a windowless Flash video, the Flash object misalignment relative to mouse coordinates, making it difficult to click the controls -- have to fish around for it.

I originally reported this as bug 686673 but subsequently closed it because it seemed as though it was reasonably resolved.  Well, it was not and after several months of putting up with issue, I'm filing it again.

This time, I'm attaching video test cases Jim Mathies posted on a different bug.  They very clearly illustrate the difference and issue.  Below is a simple STR:

1. Make sure your browser window is neither maximized nor occupies too much of your display
2. Middle-click the testcase labeled, "windowless youtube test case"
3. Detach the tab opened from Step 2
4. Attempt to play or interact with the video controls.  Brutal, huh?

5. Now notice the difference when performing the same actions (Steps 3 and 4) with the "windowed youtube test case"
6. Disabling IPC plugins and restarting, if that option still works (haven't retested), would also make the windowless case of Step 2 work

Currently the only workaround is to reload the page; however, if you were playing a video (or possible a Flash game) when you detached, it's not so great a situation -- especially if the video is one of those broken ones where seeking doesn't work and you have to endure the whole thing over again, just to have ability to pause or change any other controls.

This is a long-standing issue that affects all current Windows platforms Windows XP to Windows 8, but I cannot vouch for other platforms (i.e. Linux and OS X), as I have not tested those.

Comment 1

[IU]

Attachment: windowed youtube test case

Comment 2

[Georg Fritzsche [:gfritzsche]]

Note comment 8 in bug 478976:
> This bug has served it's tracking purpose and we're no longer using it.

Comment 3

[Georg Fritzsche [:gfritzsche]]

Not happening on OSX. On Windows mouse moves are apparently still delivered correctly (hover reactions of the player still work as expected).

Comment 4

[IU]

(In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> ...On Windows mouse moves are apparently still delivered
> correctly (hover reactions of the player still work as expected).

Are you saying you can't reproduce the windowless case?

Comment 5

[Georg Fritzsche [:gfritzsche]]

(In reply to IU from comment #4)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #3)
> > ...On Windows mouse moves are apparently still delivered
> > correctly (hover reactions of the player still work as expected).
> 
> Are you saying you can't reproduce the windowless case?

I mean that for me (Windows 7, Nightly) the clicks don't work as reported, but hovering the mouse over elements works fine (e.g. volume control expands on mouse over).

Comment 6

[IU]

> I mean that for me (Windows 7, Nightly) the clicks don't work as reported,
> but hovering the mouse over elements works fine (e.g. volume control expands
> on mouse over).

That's exactly what you should be seeing/experiencing.  You should notice that if you fish around, you will find an alternate pain where clicking activates the control.

Comment 7

[IU]

(In reply to IU from comment #6)
> you will find an alternate pain...

I meant alternate _point_

Must have been a Freudian slip. :-)

Comment 8

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.