Closed Bug 248054 Opened 20 years ago Closed 18 years ago

flash loses interactivity inside a div with overflow: auto; property

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8

The page http://karljayne.com/flash/test.html is an example of a Transparent
Windowless Flash swf placed within a DIV with a style of overflow: auto;. With
that property the swf loses it's interactivity in FireFox. Here is an example of
the same swf in a div with no overflow property. As you can see the
interactivity has returned.

This problem seems to relate to the way Mozilla handles Windowless Transparent
and the CSS property overflow. The problem exists in FireFox as well as Mozilla 1.7.

Interestingly enough, overflow works fine without a swf inside it AND
interactive swfs work fine inside divs as long as overflow is not set.

This seems like a layer ordering issue, as if the swf gets pushed backward (?)
if overflow is set. Works fine on IE.


Reproducible: Always
Steps to Reproduce:
1.build an interactive flash swf and publish it as windowless transparent
2.put a <div style="">around the swf source</div>
3.open in mozilla or firefox

Actual Results:  
Mozilla and FireFox lose the Flash interactive hooks.

Expected Results:  
The flash swf should be interactive. You can open it with Explorer and it works,
for example.

This is not a crash bug, but does appear to be a compliancy issue.
*** Bug 248059 has been marked as a duplicate of this bug. ***
*** Bug 248061 has been marked as a duplicate of this bug. ***
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: firefox.general → general
Version: unspecified → Trunk
Depends on: 261780
Product: Browser → Seamonkey
I'm seeing the same bug in a slightly different situation.  I have a flash
popdown menu in <div>1 on layer 10.  I have <div>2 in the body of my content on
layer 2 with overflow:auto set.  If one of the flash menu popdowns overlaps
<div>2 I lose flash interactivity when the cursor crosses over <div>2 while
navigating the flash menu.

I'm seeing this behaviour on Firefox 1.0 PC, Netscape 7.2 PC.  Firefox 1.0 and
Netscape 7.2 on OSX work correctly.
Product: Mozilla Application Suite → Firefox
I have observed this same issue. Check the following link on my web site for a 
further demonstration of this bug: http://www.fromthefall.com/flash_bug.htm.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
I browsed Karl Jayne's tests with Firefox 1.0.7 and can confirm that the bug
still persists.
Also seing this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5)
Gecko/20050925 Firefox/1.4
Keywords: testcase
Component: General → Plug-ins
Product: Firefox → Core
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8
> 
> The page http://karljayne.com/flash/test.html is an example of a Transparent
> Windowless Flash swf placed within a DIV with a style of overflow: auto;. With
> that property the swf loses it's interactivity in FireFox. Here is an example of
> the same swf in a div with no overflow property. As you can see the
> interactivity has returned.
> 
> This problem seems to relate to the way Mozilla handles Windowless Transparent
> and the CSS property overflow. The problem exists in FireFox as well as
Mozilla 1.7.
> 
> Interestingly enough, overflow works fine without a swf inside it AND
> interactive swfs work fine inside divs as long as overflow is not set.
> 
> This seems like a layer ordering issue, as if the swf gets pushed backward (?)
> if overflow is set. Works fine on IE.
> 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.build an interactive flash swf and publish it as windowless transparent
> 2.put a <div style="">around the swf source</div>
> 3.open in mozilla or firefox
> 
> Actual Results:  
> Mozilla and FireFox lose the Flash interactive hooks.
> 
> Expected Results:  
> The flash swf should be interactive. You can open it with Explorer and it works,
> for example.
> 
> This is not a crash bug, but does appear to be a compliancy issue.

(In reply to comment #8)
> Also seing this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5)
> Gecko/20050925 Firefox/1.4

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8
> 
> The page http://karljayne.com/flash/test.html is an example of a Transparent
> Windowless Flash swf placed within a DIV with a style of overflow: auto;. With
> that property the swf loses it's interactivity in FireFox. Here is an example of
> the same swf in a div with no overflow property. As you can see the
> interactivity has returned.
> 
> This problem seems to relate to the way Mozilla handles Windowless Transparent
> and the CSS property overflow. The problem exists in FireFox as well as
Mozilla 1.7.
> 
> Interestingly enough, overflow works fine without a swf inside it AND
> interactive swfs work fine inside divs as long as overflow is not set.
> 
> This seems like a layer ordering issue, as if the swf gets pushed backward (?)
> if overflow is set. Works fine on IE.
> 
> 
> Reproducible: Always
> Steps to Reproduce:
> 1.build an interactive flash swf and publish it as windowless transparent
> 2.put a <div style="">around the swf source</div>
> 3.open in mozilla or firefox
> 
> Actual Results:  
> Mozilla and FireFox lose the Flash interactive hooks.
> 
> Expected Results:  
> The flash swf should be interactive. You can open it with Explorer and it works,
> for example.
> 
> This is not a crash bug, but does appear to be a compliancy issue.

(In reply to comment #1)
> http://karljayne.com/flash/test-no_overflow.html

Ii appears window.overflow:auto sensing is a bit of a hyperactive child in FF,
in effect overriding Flashes ability to handle interactivity. This is still an
issue as of FF 1dotoh7 AND never worked in the moz engine as expected. I have
not tested this behavior in DeerPark. Your vote counts if you want this resolved.

-karl
Related to bug 246340?
Depends on: 246340
(In reply to comment #10)
> Related to bug 246340?
> 

yes, same bug.

flash inside a div with overflow:auto, mozilla engine chokes out the flash

I have the same problem as well.
Please test with Firefox2.0 RC1 to see if you still can see the bug.
YES - bug has been fixed in Firefox2.0 RC1.  Thank you very much!
tried to dl he RC but the page http://www.mozilla.com/products/download.html?product=firefox-2.0rc1&os=win&lang=en-US
downloads v1.5.0.7 

with a little dir browsing I found (for PC)
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0rc1/win32/en-US/

great job! bug appears squashed!

-karl
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
I can still see this bug in Firefox 2.0. See the attached testcase and click on "toggle overflow".

Suggest reopening.
Thanks for the testcase, Nathar!
However, I think it is better to keep this bug closed, so I filed a new bug for the issue that can be seen with your testcase, bug 362193.
Interesting. This is actually a slightly different bug; note that if you put the transparent flash INSIDE the scrollable/non-scrollable DIV it now works correctly which as of Firefox 2;

Mouse coordinates are messed up in the flash at any point over the scrolling DIV (if you move the flash to the right so that half of the blue rectangle is not over the scrolling DIV then that part works fine).

This makes pefect sense as a bug, since Firefox receives mouse events relative to window the mouse is over, and a scrolling DIV means a new window. They are being translated relative to the window the flash is in, which of course is not right in this case.

This may be hard to fix, because given the current plugin interface, it is not sufficient just to fix the translation for mouse events when passing them into flash; flash also wants to be able to determine coordinates from within its own internal events (which it does by offseting from the HWND firefox provides)... since we wouldn't know the context in which they were asking (i.e. we'd need to give them a different answer based on what they wanted it for - which they cant't say), to fix this probably requires.

either
a) an update to the plugin API
b) the advent of a single HWND per browser window - which I think might be coming - not sure if this would even work then for a windowless flash over a windowed one!
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: