Closed Bug 504922 Opened 15 years ago Closed 15 years ago

black iframe screens when flash player has focus

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
1.9.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: rbarajas, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; IEMB3; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; IEMB3)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)

When the flash player has focus and there are iframes being refreshed the browser blacks-out the iframes for about a second or two. It makes hard to use a flash app.

Reproducible: Always

Steps to Reproduce:
1.Open a web page containning iframes that refresh and flash objects with text input.
2.Start typing in the flash text input.
3.
Actual Results:  
The broswer blacks out the refreshing iframes until flash player loses focus.

Expected Results:  
Well the broswer should not black out the iframes. The steps above work fine in all other broswers.
Can you please give a link to an URL with the problem? Thanks.
Version: unspecified → 3.5 Branch
Unfortunately, the link is behind a login so the request will not be possible. I do have a screen shot of the issue that I could post somewhere.
At least a link is needed, or better, a minimal testcase:
http://developer.mozilla.org/en/docs/Reducing_testcases
I have just encountered this issue and I've posted a demo here: 

http://rocketon.com/sandbox/TextInputBug.html

View source is enabled in the Flash app so you'll be able to see everything.  This is a rather crippling issue and I've reported it to Adobe as well.  In case Adobe has any input on the matter, I've included the bug report I filed for reference:

https://bugs.adobe.com/jira/browse/FP-2407

Thank you,

-Tristan Swadell
Lead Client Engineer at Rocketon Inc.
tristan@rocketon.com
Wow, that is ugly! Impressing. But there is also a positive message: it is fixed on trunk. Very recently, and that increases the chance that it will also go into Firefox 3.5.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Version: 3.5 Branch → 1.9.1 Branch
(In reply to comment #5)
> Very recently, and that increases the chance that it will also
> go into Firefox 3.5.

Nope, the bug that fixed this says nothing about blocking or wanting 3.5, but at least the bug will be fixed in Firefox 3.6, that is for sure.
As of 3.5.3 this is still occurring.
Can you post a link to the bug that fixes this in 3.6?
Fixed by the compositor changes. These are not meant for Firefox 3.5.
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=941a73f2fc21&tochange=5b0d9f36c0b3
Resolving WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Does the status mean that the issue has been resolved for 3.6 or that the issue could not be reproduced on 3.5.3?
Yes, the bug can be reproduced with Firefox 3.5 and is fixed now, but only for the next milestone. Won't be fixed for Firefox 3.5.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.