black iframe screens when flash player has focus

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: rbarajas, Unassigned)

Tracking

1.9.1 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 2

9 years ago
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

Comment 4

9 years ago
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.

Comment 7

9 years ago
As of 3.5.3 this is still occurring.

Comment 8

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 10

9 years ago
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.
You need to log in before you can comment on or make changes to this bug.