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

NEW
Unassigned

Status

()

P3
normal
6 years ago
6 years ago

People

(Reporter: fehe, Unassigned)

Tracking

Trunk
All
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 682931 [details]
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.
(Reporter)

Comment 1

6 years ago
Created attachment 682932 [details]
windowed youtube test case
(Reporter)

Updated

6 years ago
Blocks: 478976
Note comment 8 in bug 478976:
> This bug has served it's tracking purpose and we're no longer using it.
No longer blocks: 478976
Not happening on OSX. On Windows mouse moves are apparently still delivered correctly (hover reactions of the player still work as expected).
(Reporter)

Comment 4

6 years ago
(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?
(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).
(Reporter)

Comment 6

6 years ago
> 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.
(Reporter)

Comment 7

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

I meant alternate _point_

Must have been a Freudian slip. :-)

Updated

6 years ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.