keyboard is not working with full screen RRS feed

  • Question

  • hello friends, i'm making a game using silverlight 1.1 and c#

    and i've to play that game in fullscreen mode with keyboard

    but the problem is that while fullscreen keyboard is not working only mouse is working there...

    can anybody plz help me in solving this problem


    naveen kushwaha

    Monday, August 27, 2007 2:25 AM

All replies

  • In the current releases, keyboard support is not enabled in full screen mode. This is supposedly a security feature so that someone couldn't be tricked (by say a spoof of your bank's web site) into entering sensitive information. Personally, I think that is going WAY overboard in regards to security paranoia. It basically makes fullscreen mode worthless with the exception of watching videos.

    Monday, August 27, 2007 2:43 AM
  • That's not a bug, that's a designed behavior in order to protect your user.

    Full-screen mode basicly "hides" the layer beneath it (if you set opacity to any other value then 1 you'll see that).
    Since we've got DOM element control and we can hide the entire screen with an overlay, an "evil" programmer would place an html <input type=text> on the HTML page, open a silverlight overlay in full-screen and re-focus the keyboard events on the <input> dom element.
    That way, the end user doesn't even know that's he typing data that will eventully be sent to the server. Now imagine that data is the end user's password or personal details.

    Here's the approprite SDK quote on this topic:

    Once a Silverlight control is displayed in full-screen mode, keyboard events are prevented from being passed on to keyboard event handlers in the application. The only valid keyboard input that is acted upon is the set of keystrokes that return the Silverlight control to embedded mode. This limitation of keyboard input during full-screen mode is a security feature, and is intended to minimize the possibility of unintended information being entered by a user.

    Returning to Embedded Mode

    A Silverlight control that is in full-screen mode can return to embedded mode in several different ways. The simplest way to leave full-screen mode is for the user to enter a keystroke or keystroke combination:

    • For Windows users, enter: Esc, Ctrl+W, or Alt+F4
    • For Macintosh users, enter: Esc



    Monday, August 27, 2007 2:46 AM
  • u r right dear

    is there any other way so that i can use my keyboard with full screen

    coz i've to play my game in full screen with keyboard only


    naveen kushwaha

    Monday, August 27, 2007 3:03 AM
  • I agree with Jack that keyboard support will not be a serious security risk, because Full screen mode can only be set in response of a user initiated event, and he will be presented with a clear message stating that he is in Silverlight full screen mode. Full Screen mode of silverlight is an interesting feature, especially for games, but disabling keyboard support will limit the capabilities of this feature.

    Monday, August 27, 2007 5:19 AM
  • Unfortunately, there is no around it, you have to not use full screen, or use the mouse instead of keyboard.
    Monday, August 27, 2007 5:20 AM
  • ok dear i'm agree with u...

    there must be some registry setting to block the keys when i'm doing my game in fullscreen

    can we trace the registry setting...

    and at the time of fullscreen we can set the registry according to our req..

    or is there any option for the full screen in c# so that i can play game with keyboard in full screen



    Monday, August 27, 2007 6:26 AM
  • Yasser is absolutely correct, there is NO keyboard support for full screen in Silverlight.
    There is no registry key, assembly hex hack or magic beans that will enable it.

    Here's the real security concern, you can accept it or not.

    Open up (right now) any website that asks for your login, let's say Windows Live ID, this forums login page or your gmail account login.
    Opened? Look at the screen. What do you see? Your browser (with address bar) and some HTML content.

    Problem with full screen is that any competent fishing expert can create the exact same screen you're seeing (including the browser facade). 
    So in stand of working against HTML in browser, you'll actually be seeing the EXACT same screen only you'll be using Silverlight Full-screen.
    Now, what's stopping you from giving me your username & password?

    This feature can easily be exploited by sending mass fishing emails to some "fake" link that looks like the original (the way eBay scammers are common to do), opening full screen Silverlight on any user mouse click and then changing the Silverlight fake "address bar" to show "www. ebay. com". so where does that leave the end user? completely unprotected and unaware.

    That's why there's no keyboard support in full-screen, because I can display whatever I want in there, your desktop, your outlook or any login page and It would look exactly like the real thing.

    You can take it or leave it, but that's just the way it is.   

    Monday, August 27, 2007 6:42 AM
  • I understand the threat, but you can only launch full screen in response to a user event on the silverlight control AFTER the silverlight control is loaded "you can not set full screen in the loaded event of Silverlight". And after that Silverlight shows an unoverridable banner stating that you are in Silverlight full screen mode. I believe that this is enough protection against phishing, keyboard mutation is not necessary in my opinion.
    Monday, August 27, 2007 7:20 AM
  • I think disabling keyboard support due to this type of threat is on par with disabling voice support because some web site might embed a sound file in their home page that reads "Delete c:\ntldr". Another option would be to let the user decide either on the global level(right click a silverlight app, Configuration..."Enable key support in full screen - Check") or on the first detected key event after going full screen("Do you wish to enable keyboard support for this Silverlight application in full screen mode?") I suspect/hope that Microsoft is already mulling these options, because it seems to me this really should be a user choice(and a fairly trivial thing to implement.)

    Monday, August 27, 2007 7:44 AM
  • hey yasser

    that is what i want to say...

    but justin is not ready to listen anything....

    after too many R&D i found that it is not possible in silverlight

    i's asking abt the alternate way to solve this problem

    coz anyhow i've to do it...

    whether i do it with c# or javascript...


    naveen kushwaha


    Monday, August 27, 2007 7:48 AM
  • hello guys,

    yes, i'm with Yasser on this one. it's too restrictive and we're just starting to get ridiculous with all this security thingy. after all, if we continue like this, then maybe it's safer if we just don't turn on our computer...

    Monday, August 27, 2007 4:05 PM
  • I just ran into this, it's pretty major, so basically we can't have any application that accepts text input in full screen mode. I was pretty shocked when I had this issue and read that it's by design.

    Thursday, September 13, 2007 1:14 AM
  • I know this thread has petered out, but I would like the opportunity to argue the case for adding keyboard support in full screen mode. 

    First, I want to make it clear that I recognize the clear value that disabling keyboard input brings.  It completely prevents a comprehensive phishing technique which would be particularly difficult for a reasonable person to detect and avoid.

    That being said, I urge the Silverlight development team to reconsider the many alternative solutions to this problems as the cost of the current solution may not yet be clear.  The gaming audience for Silverlight may well be the force that drives this product into mainstream usage as it touches nearly the entire internet audience.  Just look at a site like PopCap.com and you will see an increadibly popular site who's audience covers men and women of all ages.  It goes without saying that Silverlight brings many more things to the table for game developers than flash, yet to the end user the two tools may seem interchangable.  Fullscreen gaming support, ie keyboard support, can be an important tool in pushing Silverlight into the lead.

    As for the security threat, a number of users have suggested viable alternatives in this thread, all of which were ignored.  I respect your hesitance to commit to wild changes suggested by a handful of uninformed testers; however, that does not deny the inherent merits of the alternatives, and I would like to see them addressed.

    1. Rely on the current message shown when the site goes to full screen to inform users that they are no longer using a browser.
    2. Enhance the current message, possibly by requiring the user to click a button, thereby increasing the change they might realize something is amiss
    3. Add an option that can be turned on to support full screen.  This may be the strongest suggestion that was not addressed, as it caters to both needs.  The option could be available only by right clicking on the screen and following a context menu link, there by increasing the difficulty for phishers to "trick" users into mistakenly consenting.
    4. Add a built in prompt that asks the user how they would like to proceed.  This could be a great foundation for how to handle permissions around activating advanced networking, microphones, video cameras, file uploads and other advanced features that may be critical in the future.  You could even couple this with a certificate program to ensure the same trust and authenticity that have existed on the web.

    I understand that all of these options create the potential for abuse, but as some posters have already mentioned, security-functionality trade-offs are inevitable for any internet based application.  Simply saying that security will decrease is not a complete argument against adding functionality.  Instead, those increased risks must be contrasted to the gains, the ability for users to detect and avoid the risks and current assumptions as to the average users needs for the tool.  I hope that this can begin a more exploratory investigation towards the option of adding keyboard support to fullscreen.

     As testers, we always appreciate being included in the process, even in small ways.  Seeing an Silverlight rep post that there may be value in adding socket support was increadibly rewarding, and even if no action will be taken on this matter, hearing the same level of though put into responses is appreciated greatly.

     Thank you

    Friday, September 14, 2007 4:58 PM
  • i want to install silverlight on windows 2000.

    i search for it on the google...

    from there i got the answer on the following link... 


    but my problem is not solved by approaching according to their direction...

    they were telling about a dll i.e. agctrl.dll

    but i won't be able to find "agctrl.dll". 



    Monday, October 1, 2007 5:28 AM
  • I just started researching this subject as I just recently started diving in to Silverlight  1.1.

     I plan to make games on the platform using my Farseer Physics Engine.  I agree 150% with lameducks post above.  There must be a middle ground that would allow users the option of going fullscreen with keyboard support.

    Disabling keyboard support in fullscreen protects the few who might be fooled by a spoof site by punishing the many who would like to develop and play games (not to mention other apps) in full screen.

    Please rethink this Microsoft.

     Long time backer of MS Technologies,

    Sunday, October 21, 2007 8:50 PM
  • You can go full screen with the browser itself.  I'm not sure why that is considered secure, yet going full screen with Silverlight isn't.  I suppose a work around is to take the browser full screen, and resize the canvas accordingly.

    Tuesday, October 23, 2007 5:00 PM
  • Because if the browser is full screen, it will have focus, you wouldn't be able to have a hidden window behind it that is grabbing keypresses.

    As for a solution, how about allowing a way to specify whether to enable keyboard or not in full screen, and if set to true, Silverlight could pop up an extra prompt or warning as was suggested earlier, or even continuously display a banner at the top of the fullscreen control which alerts the user to the fact that they are in full screen mode and not to enter any sensitive information.

    Tuesday, October 23, 2007 5:11 PM
  • I'm not understanding.  Obviously a full screen silverlight application has the focus too.  Is it the silverlight / javascript interaction that would allow keyboard strokes to affect the covered browser page from which it was created?  Couldn't it use the same protection IFRAMEs employ when spawned from different sites?  In other words, so what if I can spoof (no pun intended) my own web page.  It is not like I can invoke my silverlight application to cover over bankofamerica.com, and then start vectoring keyboard input to it.  Any further clarification appreciated...


    Tuesday, October 23, 2007 5:35 PM
  • It seems the potential for abuse stems primarily from being able to set the root canvas transparent, and then capturing keystrokes. When going to full screen, why not just put a black background behind the root canvas? I can't really think of a scenario where I'd want to interact with non-silverlight elements(exposed via transparency) anyway. I'm not sure about other people's mileage, but the only silverlight/html interaction I've done was to read the contents of a textbox, and once silverlight has a textbox control, I'd be getting rid of that. Ultimately, I'm guessing that applications that want to go full screen, want to paint the full canvas, and wouldn't care if there was a black background underneath the visual root.

    Tuesday, October 23, 2007 5:38 PM
  • Thanks - that helps. How about just turning off the keyboard if the parent canvas is set to some level of transparency?  The development cost for that seems pretty low.

    Tuesday, October 23, 2007 6:24 PM
  •  hello friends

    i'm using httprequest/response to send xml data to the server


    the code i'm using is ...

    string _status="";
                        string _result="";
                        if (_requestPending)
                            _status = "busy";
                            _requestPending = true;
                            string symbol = "Naveen";// _textBox.GetAttribute("value");
                            // The target web service must be on the same server as this Silverlight application.
                            string serverUri = HtmlPage.DocumentUri.ToString();
                            int thisApp = serverUri.IndexOf("/TestPage.html");
                            // Create the web service Url with this server as its base.
                            serverUri = serverUri.Substring(0, thisApp) + "/SimpleWebService/SimpleWebService/WebService.asmx";
                            // Pass the input string to the EchoInput method in the web service.
                            System.Uri webServiceUri = new System.Uri(serverUri + "/EchoInput?input=" + symbol);
                            _status = String.Format("Calling {0}\r\n", webServiceUri.ToString());
                            _request = new BrowserHttpWebRequest(webServiceUri);
                            // Include the request object as the IAsyncResult.AsyncState property.
                            IAsyncResult iar = _request.BeginGetResponse(new AsyncCallback(OnResponseDownload),
                            // Simulate some activity while waiting for the response.

                        catch (Exception ex)
                            _status= ex.ToString();



    but it is giving error on the line

    IAsyncResult iar = _request.BeginGetResponse(new AsyncCallback(OnResponseDownload),  _request);

     "Operation is not valid due to the current state of the object."

    and i'm unable to find the solution of this error

    or is there any other way to communicate to the server to transfer data from page.xaml.cs page to server... 

    thanx & regards

    naveen kushwaha

    Wednesday, October 24, 2007 6:18 AM
  • This thread needs to stay alive.  Not having keyboard events is a HUGE handicap.  A simple prompt/confirmation when going full screen with keyboard would solve this problem.  The .Net model for security is simple, the user is aware of or is in control of anything potentially unsafe.  This is everywhere in .Net for web deployed apps, Vista, etc.  To simply disable this functionality without offering a work around is a cop out IMO.

    To be able to full screen your application and take full advantage of the entire resolution of whatever display you're running is one of the best features in Silverlight.   However to offer no input to your app other than a mouse makes this feature nearly useless to most real (non-flash oriented) apps.

    If they include a silverlight textbox control?  Will it not work in full screen either?!!

    Thursday, November 1, 2007 3:31 PM
  • I've read and understood the arguments for this design decision and have to say it's a rather paranoid stance. In my opinion NOT having keyboard support when in full screen mode is more of a "kludge" than figuring out an intelligent way of indicating to the user what is going on and if they accept the risk...

    i.e. "The Silverlight application you are using is currently in full screen mode. Due to potential security risks please verify that that any information you input is trusted with this application provided. Do you wish to enable full screen keyboard support?    OK | CANCEL". This could be displayed in the same way as the 'press ESC to exit' full screen reminder. Could someone present this idea/option to the Silverlight Program Manager and/or Development team? We really need full screen keyboard support in Silverlight in order to make RIA a true reality. PLEASE, make this happen... it's a win for users, developers, and Microsoft. If we don't address this now, think of all the time that ALL of us will be wasted explaining why this "can't be done"... at the end of the day any excuse as to why this can't be done is worthless. We have two paths before us...
    1.     Provide for, empower, and educate our users/developers.
    2.     Lower our expectations to engineer our way around this and live with the trade-off (which sucks). 
    Monday, April 28, 2008 11:19 AM
  • This thread has been open for eight months.  I know that many users participate, because they hope that they can shape the path of this new product.  Unfortunately, i have a strong suspicion that we're talking to ourselves.  It would be great to get a response from the Silverlight team of a MVP indicating that these suggestions are at least under consideration or specifically explaining the decision not to change.  Clearly there's not expectation that Silverlight will be created based on the whims of the developer community, but I'm sure the community has also provided critical insights and advice.  It would be very much appreciated to know that these comments are at least being read and considered.


    Monday, April 28, 2008 11:42 AM
  • Unfortunately, i have a strong suspicion that we're talking to ourselves.

    We're not. They may not respond directly, but if you read enough of their blogs and see their limited responses on other threads, it's pretty clear they are listening.

    Monday, April 28, 2008 3:48 PM
  • Any word on if this has been bubbled up the chain?

    Wednesday, April 30, 2008 6:50 PM
  • When will we have full screen keyboard support? ... Why hobble the platform out of fear? Are there no workable solutions? Should Microsoft hire me to solve the problem? Heck, I'd work on the problem for free if it meant we could all benefit. Can no one on the Silverlight Dev Team address this real business need? Please, let’s get this solved and out of the way!
    Saturday, July 26, 2008 3:53 PM
  • Going to have to agree to 'make it happen' with another solution.  The full-screen mode is awesome and I think one of the keys to developing a web-application (be it game or application), is for the end user to feel as though he is using a desktop application/game, not to mention the real-estate you gain.  I think several good solutions have been given on this thread and i am hoping these are to be addressed.   IMO, all avenues of protection have not been given weight. I would much rather lose the inability to use transparency on my canvas than lose keyboard events. I am going to have to think that there are more security problems associated with using keyboard events then what we have been made aware of. At least, that is what I am going to make myself believe for the time being. Wink

    Thursday, July 31, 2008 3:45 PM
  • Since it's been almost 3 months since the last post on this, I thought I'd add in my own vote to have keyboard input in full screen mode.  Surely there must be some solution that will protect end users without crippling a most basic feature of computing (the keyboard).

     Anybody hear word back from the Silverlight team?

    Sunday, September 28, 2008 7:58 PM
  • Unfortunately, no word as of yet. I’m beginning to think we’re not going to see full keyboard support in full screen in Silverlight 2… which is a real shame since it pretty much limits the entire Silverlight developer community. Trust me, developers are talking about this as a major drawback. I still fail to see what the huge security risk is that prevents this feature from being enabled. The risk of someone simply spoofing a site seems minimal to me. Since full screen mode HAS to be initiated by user action, could we not just warn in the text that shows along with the “Hit ESC to exit full screen mode”?

    PLEASE, someone from Microsoft respond to let us know what the deal is on this. I just don’t get why this is such a challenge. Is there a more fundamental security flaw in the plug-in that is has an attack vector associated with full keyboard support? That’s a legitimate reason for not supporting; it would just be nice to know why what is so very obvious to all on this thread is so difficult for the Silverlight Dev team to provide.

    Do not take these postings as an attack or a vote of no confidence in the Silverlight Dev team… they all have done a fantastic job. We just want to see this feature taken from the 5 yard line into the end zone. Please, let us know what the challenge is… perhaps we could help.


    Monday, September 29, 2008 12:47 AM
  • If someone can fish information from you by showing you a full screen display that looks like your browser, how come they can't fish information by showing you a page that is IN your browser? I think your argument is bogus. Disabling keyboard events when in full screen mode is a very naive solution in my opinion. Limiting user's interaction capability to an extent that NO keyboard input is allowed is fundamentally flawed.
    Wednesday, October 1, 2008 6:44 PM
  • So long as a user has to initiate full-screen mode themselves, and there is a notice about full-screen mode being entered, I don't see what the security hole actually is.

    What on earth is the point of trying to use Silverlight to mimic a standard web page for phishing, when using HTML/AJAX is the best way of mimicing a standard web page.

    The lack of keyboard support in full-screen mode seems like a very poorly thought out, knee-jerk reaction to a problem that doesn't seem to be real.

    Thursday, October 2, 2008 12:41 AM
  • Totally agree on the fact that keyboard entry being disabled during FullScreen is a huge limitation . I am using Silverlight to write Internet Applications, but wanted a greater user experience , instead I am stuck with a browser hanging around my application which consumes screen real-estate and potentially create confusion to the end user.

    Sunday, October 5, 2008 8:03 PM
  • I am afraid that MS policy is to avoid those idiots with a label 'I hate M$ and I will say anything to hurt them' stuck to their forehead :)

    Look at Vista - do you really need UAC? Has it helped you to stop any thread. Probably not, but nobody can accuse MS that they do not treat security seriously. And we all have to suffer with those pop-ups.

    Similar case is with SL - if one stupid journalist would find that you *can* create application which *might* be similar to other screens and in the hands of the stupid user it *can* be dangerous, it would cause a very long serious of attacks against SL and MS in total. Of course x% (where x>=100) would be incorrect or simply wrong, but it would decrease acceptance of SL between not so knowledgable users.


    Sunday, October 5, 2008 10:35 PM
  • I am adding my vote for fullscreen support too.  The message that pops up stating that you are in fullscreen is warning enough.  If Microsoft wants to be extra cautious they can take a piece of fullscreen to display a permanent warning to the user.

    Friday, October 24, 2008 11:46 AM
  •  I add a vote for full screen support. You cannot think to use SL for business applications without the use of full screen mode. Add a warning and if the user confirms let him use the keyboard in full screen mode



    Monday, November 17, 2008 8:43 AM
  • I like the fullscreen mode, but keyboard support so less, that disadvange of using fullscreen is far more than its advantage, After reading this article on features that has been enable of keyboard.


    Sharker Khaleed Mahmud (MCPD)

    Monday, November 17, 2008 9:03 AM
  •  I am also agree with Shamrat. There is a security risk in fullscreen but its not that much because it is user initiated action. In some game we really need keyboard support in fullscreen mode.

    Monday, November 17, 2008 9:13 AM
  • A solution for those of you who are trying to go full screen with keyboard support simply ask the user to click F11, that works for both firefox and internet explorer. This basically blows up the browser to take the whole screen. I tested it and it looks exactly like the regular silverlight full screen.

    I hope this helps, 


    I was really surprised to see both firefox and internet explorer use the same function button for full screen, I hope saffari does too

    Monday, November 17, 2008 3:56 PM
  • I like the F11 workaround. Not perfect, but at least inside a intranet this is a good way of dealing with this for now.

    This there a way to use Javascript to do that on a click event?


    Friday, January 2, 2009 5:07 PM
  • Exactly.

    It is nice MS is trying to save the whole world but advantage of the full screen of the Silverlight application is lost. The long showing message is sufficient security step. Don't restrict silverlight possibilities because of several inattentive users. Silverlight would not save them.




    Saturday, January 31, 2009 7:19 AM
  •  Folks,

    According to the Silverlight 2 docs there has been some limited support for keyboard interaction when in full-screen mode.

    Here is the link:


    bread crumb trail:

    MSDN > MSDN Library > Silverlight > Silverlight 2 > Visual Design > Full-Screen Support



    When a Silverlight plug-in is in full-screen mode, it disables most keyboard events. This limitation of keyboard input during full-screen mode is a security feature, and is intended to minimize the possibility of unintended information being entered by a user. In full-screen mode, the only input allowed is through the following keys.



    That all said... I still can't get any keyboard event messages to fire in my Silverlight applications.  Even after creating my own event delegates and so forth, i still cant get the keyboard events to fire in my application.  Any suggestions!!!!


    Wednesday, April 29, 2009 2:01 PM
  • Hi Me Again,

    Now im really confused.. in the same MSDN docs it appears to be contradictary to the full-screen info that i just posted.



    bread crumb:

    MSDN > MSDN Library > Silverlight > Silverlight 2 > Visual Design > Input > Keyboard Support



    Keyboard Events and Full-Screen Mode

    When a Silverlight plug-in is displayed in full-screen mode, keyboard events are prevented from being passed to keyboard event handlers in the application. The only keyboard input that is acted upon is the set of keystrokes that returns the Silverlight plug-in to embedded mode. This limitation of keyboard input during full-screen mode is a security feature. It is intended to minimize the possibility of unintended information being entered by a user into an application that is impersonating another application visually. See Full-Screen Support.


    UNFORTUNATELY, i have been making development and business decisions based upon the first post i made where limited keyboard support is advertised... I still cant get the keyboard events to fire... so either im not implementing correctly... or it is just not supported... Either way the docs on MSDN are inconsistent and misleading.


    Wednesday, April 29, 2009 2:33 PM
  • If your app fills the browser window 100%, you can use the web browsers full screen toggle(F11 in IE I think) to go full screen and you will have keyboard support.

    To put it bluntly, the "security concerns" are a load of crap. They also had "security concerns" about a FileSaveDialog, and yet they somehow magically disappeared, and now Silverlight 3 has a FileSaveDialog.

    Wednesday, April 29, 2009 6:47 PM
  • The one problem with your argument is that they actually had to add code to make keyboard not work in full screen mode, It is a legitimate security concern. Flash doesn't allow you access to the keyboard in full screen either from what I understand for the same reasons.

    Wednesday, April 29, 2009 6:57 PM
  • I also don't see a good enough reason to justify no-full screen mode. 

      1) You already get a notification that you are in full screen mode so it should be obvious that you are in the browser still.

       2) You can already full screen with F11.

      3) You can expand the screen beyond the dimensions of the monitor and reposition it so you can see the borders.

    Some possible solutions or compromises which the Silverlight team could implement are:

    i) On loading of the application of first use, the user could be promted for access to Full-Screen keyboard support as a more privleged level of access to a trusted site.

    ii) An ActiveX-style notification bar could be shown at the top allowing users to "close notification bar this one time",  "always close notification bar for this site"

    iii) A minimal silverlight branded bar could replace the browser UI.

    iv) Microsoft could charge for a special application license that provides heightened access to the client. With an entrance fee of $1000-$5000 this would probably disuade most phishing sites from trying this.

    Demand is there, and the security concearns as I see them seem spurious.

    Wednesday, July 1, 2009 7:14 PM
  •  Well, I really hope the charge thing not going to happen (it's impossible to test through every version of an application completely, also what could they base the pricing on? It obviously can be a lot cheaper to test through an application that has fewer user interaction features etc... very hard to measure by any exact property of a certain app), though it would still be better than no full-screen + full-keyboard support at all.


     While I still don't see why a seperate allowance for every domain would be so insecure, there is one thing in the post above that I really think could help a lot in the way towards solving this problem.

     iii) A minimal silverlight branded bar could replace the browser UI.

    This way, although we couldn't actually use the whole screen for display, at least we could get the mouse position from even the very corners of the screen, which I think is an important thing we need full-screen full-keyboard support for.


    One example:

    Imagine any application, where the user can scroll through the user interface by moving the mouse to the edge of the screen. If we can't actually catch the mouse position at every side of the screen, this scrolling method will perform very poorly, the user will have to move her mouse back and find the "sensitive spot" of the UI. Even if we put a relatively thick scroll-sensitive area at the side, it's never guaranteed that the user won't move her mouse too fast so that the pointer flies over the area, not to mention, a thick area will make the UI scroll, even if wasn't the user's intention at all.

    Moving the browsers full screen won't help this, because browser UIs still have frames at at least one side of the screen, from where we can't capture mouse position.


    So please, even if it really is such a huge security concern to allow users specify certain domains that they trust and are willing to give full-screen full-keyboard support to, at least let us capture the whole screen for mouse coordinates (with full-keyboard support).

    With a silverlight branded bar, or even frame, this could be possible.


    Thank you

    Thursday, July 2, 2009 6:34 AM
  • <p></p>

    If your goal is to rack up a bunch of points quickly, I can pretty much guarantee you your account is going to be deleted by Monday. Get a life.

    Friday, July 3, 2009 9:07 PM
  • This whole page was enlightening and I'm not any kind of programmer, just one of millions of frustrated Netflix users dealing with the forced Silverlight update and it's resulting screw up of my dual display living room HTPC. We're having a fun debate on why SL loses full screen when it loses focus over at http://silverlight.net/forums/p/99756/278248.aspx.
    Similar security concerns raised here were the explanation of "why" and some of us wondered "why not give me choice?". From what I read SL can't begin in full screen unless I click on something in the first place so can anyone explain why it can't stay that way?
    It's a cross - I know - sorry. I just thought some of the folks on this post knew more about what could be done than over at the other post. And I am the nut who opens a new browser to do online banking, closes it, opens another to check mail, closes it... some people aren't as careful. Still, programmatic security measures can't protect everyone.

    Saturday, August 29, 2009 12:21 AM
  • From a usability point of view, ignoring key strokes in full screen mode is horrible. Most normal users out there don't know about this fact and wonder what's wrong. At least, Microsoft should fade in some message, unobtrusively, say, at the bottom right as some transparent layer, informing the user that due to security reasons key input is disabled. Sure, I could handle that myself, but attaching event handlers to each and every input control is tedious. Best solution would of course be to enable keyboard input in certain scenarios like trusted zones in the intranet, and/or use a dialog box in administrator mode to unlock this feature once for every application.
    Tuesday, September 8, 2009 6:08 AM
  • There is a new official-like SL4 request tracker, you can vote for this feature there.


    Wednesday, September 9, 2009 5:23 AM
  • Thanks Herthoren!
    As of Oct. 10, 2009 that keyboard request is #14 (out of 260+ fet. req.) and my suggestion ranks # 19. We're not alone!

    Saturday, October 10, 2009 2:24 PM
  •  At least allow the arrow keys to work for games.  its not like people use those in their passwords!!!

    Maybe also Page Up, Page Down, Home, End etc. CTRL, ALT etc.

    Even without the A-Z 0-9 keys, that would be at least more useful.

    Wednesday, October 14, 2009 12:12 AM
  •  At least allow the arrow keys to work for games.  its not like people use those in their passwords!!!



    lol, yes there might be some truth in that.

    Wednesday, October 14, 2009 5:18 AM
  • Just adding my 2 cents...there MUST be a middle ground solution that maintains security without sacrificing keyboard input in full screen mode.  FIND IT.


    Wednesday, November 4, 2009 11:27 PM
  •  This isnt just about games, one of our software's exiting features is that users can work in fullscreen mode and have a much better user experience. We are developing a major application that users will be working in all day, having these limitations is a severe blow for us. I really hope full keyboard support will be supported in Silverlight 4.

    Friday, January 22, 2010 5:54 AM
  • The good news is that it is finally possible to use keyboard in FullScreen mode, but the application should be running with elevated trust, which seems not an issue from the scenario you are describing. Check Tim Heuer's blog about the new features of Silverlight 4 http://timheuer.com/blog/archive/2009/11/18/whats-new-in-silverlight-4-complete-guide-new-features.aspx#fullscreen
    Friday, January 22, 2010 6:35 AM
  • Ah great, thanks y_makram. Still it's not the most desired solution to confront the user with a message asking wether the application is trusted (Im assuming this is the case) but at least that's a nice solution.

    Friday, January 22, 2010 8:08 AM
  • Applications can only run with elevated trust when running outside the browser. When the application is first installed to enable out of browser mode the user is warned about the application requiring elevated trust.

    Friday, January 22, 2010 8:13 AM
  • hi naveen did u get keyboard working on full screen mode??
    Tuesday, February 2, 2010 2:51 AM
  • I hope MS follows suggestions from this thread.  Flash behaves in the same way during full-screen mode.  I wonder -- has anyone tried capturing keyboard input from the web browser via Javascript to feed this into the SL app?

    Thursday, June 17, 2010 1:12 AM
  • TextBox TextBox1 = new TextBox();

    TextBox1.KeyDown += (e, k) =>


    if (k.Key = Key.Enter)






    is Not Working?

    Thursday, June 17, 2010 1:44 AM
  • hi guys, just a bad idea: 

    why microsoft  does not protect the silverlight page that you need to show in full screen mode  just with the client access policy file? so if you need to perform a login, that file can protect it. right?

     Giovanni D'Arienzo


    Thursday, July 1, 2010 9:13 PM
  • wow

    i did not see that was possible to use the full keyboard when the application is full trust.

    I think is the best compromise!


    Friday, July 2, 2010 4:20 AM
  • This is a nice suggestion for MS to implemnt in the future version of the SL.

    Friday, July 2, 2010 8:06 AM
  • That's two entirely different things.


    With the client access policy XML files, a web service provider can protect himself from cross site scripting of external, untrusted origin.


    With the locked keyboard in fullscreen mode, Microsoft protects the user from you the developer, yes you who might publish evil applications that pretend to be a log-on screen.

    Friday, July 2, 2010 8:30 AM
  • This is hillarious. Protecting user from me (dev) with such a poor protection is like protecting a bank with a glass door.

    Im able to replace entire Microsoft login page with fake Silverlight one and I dont need full screen mode to do that - its easier without full screen. Security is almost not an argument in this case.

    From the other side lack of active full screen mode is a serious step back. Luckily there is something called Prism from Mozilla. I couldnt live without it.

    Could someone tell me why am I forced to use third party software to patch up crimpled SL plugin?

    Maybe someone has got access to cracked SL plugin that enables keyboard in full screen mode? I know, i know, not fully legal but im a desperate in this case.

    Monday, November 1, 2010 3:30 PM
  • Keeping this thread alive.

    Keybord still does not work in fullscree mode.

    Wednesday, September 7, 2011 2:34 PM
  • Well... granted the Silverlight fullscreen doesn't allow you to use keyboard input for obvious security reasons... you could always just fullscreen the host... not sure how to go about it in out-of-browser but it would be trivial to accomplish inside of a browser via the App.xaml codebehind... just throw some custom js into the header output.

    This is all just theory and conjecture, but I do know that pressing F11 in IE will effectively go full screen, however with taskbar still visible if not on auto-hide... but the application will still let you use the keyboard in that state.

    Wednesday, June 20, 2012 8:28 AM
  • An old thread but... I developed a silverlight 5 application.

    In regular non-fullscreen mode the keyboard is completely disabled. When i fullscreen the spacebar (the key im using) works. When I return to normal size, the keyboard functionality works for me, anyone else had anything similar?

    Wednesday, January 2, 2013 12:32 PM