601094 - Silverlight under two nested iframes catches keyboard input instead of inner iframe

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Sander Saares]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

When the main page contains a Silverlight application Z-ordered below an iframe, which in turn contains an iframe, input focus goes away from the inner iframe in certain scenarios.

In my sceanrio, the inner iframe is a tinyMce editor. It is a fairly complicated thing, which may mean that this bug only surfaces in very special circumstances. I have not tried it with something else as the inner iframe.

Switching between tabs seems to direct input focus back to the correct location, until the next click.

Reproducible: Always

Steps to Reproduce:
Steps 0-2 are completed for you in the attached repro case.
The attached repro case includes a blank Silverlight 4 application (just a compiled empty project as created by Visual Studio).

0. Prerequisite: simple.html from tinyMce examples (I used 3.3.9 to repro)
1. Create an HTML page which has a Silverlight application covering the entire page. The Silverlight application can be anything, even the default blank project generated by Visual Studio.
2. Add the simple.html as an iframe that will be visible on top of the Silverlight application.
3. Upload this page to a web-accessible location.
4. Open this page in browser.
5. Click on the tinyMce text editor. Type a few words to verify all is OK.
6. Click on the tinyMce text editor again. Try to type.
Actual Results:  
Nothing happens - the tinyMce editor does not receive any text input.

Expected Results:  
My keystrokes reach the tinyMce editor iframe and the letters appear.

This only seems to happen on Mac OS X.

The windowless parameter of the Silverlight application is set to true in my case, but as I understand this parameter is always interpreted as true on Mac OS X by Silverlight, so it is probably irrelevant.

Switching between tabs seems to direct input focus back to the correct location, until the next click.

Comment 1

[Sander Saares]

Attachment: Files to easily reproduce the bug

Comment 2

[Sander Saares]

I have done further testing and it appears that the Silverlight app does not actually receive the keyboard input - its presence in this scenario just causes input to disappear to a black hope, apparently.

Comment 3

[Ioana (away)]

WFM on the 01/28 Nightly.

If anyone can reproduce this issue on current builds, please reopen this bug.