Follow up from bug 688082 comment 10: On desktop we also show the warning whenever there's alpha-numeric key input as a safeguard against password phishing. I guess it makes sense to show the warning on text input on mobile too; the bad guys could still fake the fennec UI going to paypal.com or whatever and phish for passwords.

Following the logic for desktop, it looks like we just need to listen for the MozShowFullScreenWarning event. Chris, is this the right idea? Also, I couldn't figure out how to test this without a hard keyboard, so I'll probably have to ask someone with a different phone to test.

Comment on attachment 574470 [details] [diff] [review] patch Yup, that's the idea. If there are android specific key code that you want whitelisted (like volume change perhaps?) you can add them to the whitelist in IsFullScreenAndRestrictedKeyEvent() in nsPresShell.cpp.

Comment on attachment 574470 [details] [diff] [review] patch Can I just ask someone from QA to verify that this works with a hard keyboard?

(In reply to Margaret Leibovic [:margaret] from comment #3) > Comment on attachment 574470 [details] [diff] [review] [diff] [details] [review] > patch > > Can I just ask someone from QA to verify that this works with a hard > keyboard? Which site?

(In reply to Aaron Train [:aaronmt] from comment #5) > > Can I just ask someone from QA to verify that this works with a hard > > keyboard? > > Which site? http://pearce.org.nz/full-screen/ Any site that causes the full-screen mode to appear. Using "full screen" on a video should work too.

Retested with: Mozilla/5.0 (Android; Linux armv7l; rv:11.0a1) Gecko/20111209 Firefox/11.0a1 Fennec/11.0a1 Device: HTC Desire Z (Android 2.3) Warning "Press back to leave full-screen mode" is displayed when full screen is requested using HKb. Verifying bug.

Can you please reconsider this behavior? It is severely limiting the use cases where this feature is useful. For instance, it is now completely unpractical to build a "zen mode" text editor or any HTML app that involves a distraction free UI. Games are a also a good example. Most gamers are using the "w" "a" "s" "d" "x" key combos to navigate, not the arrow keys. Chrome has done a good job about not being obtrusive with this behavior and real life usage proved their approach is the right one for the end user, without posing security risks. A permission/whitelist based approach would definitely be more useful than nagging the user on each alphanumeric keypress.

(In reply to Emil Tamas from comment #8) > Can you please reconsider this behavior? > > It is severely limiting the use cases where this feature is useful. For > instance, it is now completely unpractical to build a "zen mode" text editor > or any HTML app that involves a distraction free UI. Games are a also a good > example. Most gamers are using the "w" "a" "s" "d" "x" key combos to > navigate, not the arrow keys. > > Chrome has done a good job about not being obtrusive with this behavior and > real life usage proved their approach is the right one for the end user, > without posing security risks. > > A permission/whitelist based approach would definitely be more useful than > nagging the user on each alphanumeric keypress. Thanks for your input. After a bug had been marked fixed, we like to continue work in new bugs. Could you file a new bug that describes the approach you would like us to take? If you cc me I'll make sure the appropriate UX folks get included.

Test case created in the Full Functional Tests testsuite in MozTrap: https://moztrap.mozilla.org/manage/cases/_detail/6341/