Comment 1 by briang1 on 2011-06-28 22:34
I can confirm this is also an issue in later versions of Firefox 5 and 4. It also affects the system menu as fiddling with the options here, to say minimise Firefox, in fact does not do this.

It can be flakey though, as if sometimes, if you time it right, it will work.

Also agree that if you shut and relaunch nvda then most of the time at least, it will work to get you back.

I have confirmed this also is in snap 504.

The log seems to be of little help here, as nothing much is sent to it other than the keypresses. Also noted is that nvda/f5 and f5 on its own can be very hit and miss when this scenario is encounterd. Switching tasks to another window or desktop makes no difference to the current state when you return. Is IE supposed to go into the same type of mode? I still see menus when f11 is pressed, but it may be another hot key in this browser.

Comment 2 by jteh on 2011-06-29 00:15
Can't reproduce here with Firefox 7pre on Windows 7 64 bit. Pressing f11 again correctly disables full screen mode.

I can't see how NVDA could cause this. We don't override the f11 key, nor do we hook anything related to full screen mode.

One hypothesis is that it isn't actually NVDA causing the problem. It's possible that restarting NVDA causes the window to be minimised, which drops it out of full screen mode. Please confirm that this issue is definitely not present with NVDA unloaded. You'll probably need sighted assistance to do this.

Comment 3 by briang1 on 2011-06-29 08:12
OK, armed with your possible explanation I think you are right, there is something funny about ff 3.6 through 5. I booted up narrator, and unloaded nvda, then launched ff4. The same syymptoms are there. its almost as if the pushing of f11 does not work all the time when in full screen mode. Same goes for the menu of course and you can clearly see the state of the menu options have changed but still the menu won't work. I did the same on Hal with the same result as well. No sighted help around, so it looks like this is a mozilla bug of some sort related to keyboard entry under certain circumstances.
If the original reporter can find any other evidence, it would be useful. Howevr I'm sure this never used to happen on ff 3.5, don't have it here though.

Comment 4 by Palacee_hun on 2011-06-29 21:19
I could get sighted assistance to do some tests.

For the first time NVDA 2011.1.1 was loaded and the issue could be reproduced in the manner I had described. Then I unloaded NVDA, hit F11 which immediately put FF back to normal mode, it could be seen without doubt. Then I repeated the mode switch several times, it went smoothly back and forth. The only interesting thing to notice was that FF performed the switch to fullscreen in multiple steps, these stages could be distinguished visually. One part of the normal view disappeared much earlier than others when going to fullscreen. This may have some significance as it had been shown earlier that timing of the mode switch could have importance in triggering the issue.

After some mode switches without any problem, I reloaded NVDA 2011.1.1 when in fullscreen (launching NVDA did not alter the view mode in any way) to normal and tried to reproduce the problem. But then came the surprise, it wouldn't trigger! Mode switches went on smoothly without any disturbance. I tried unloading NVDA, then changing to 2011.2 beta1 or to Narrator,nothing seemed to interfere with normal operation.

Then after some time, the problem reappeared. FF wouldn't go back to normal view after a lot of tries. No sooner had I wanted to unload NVDA to remedy the problem, the final try succeeded and normal mode returned.

This issue seems extremely messy. I wouldn't say now that this is definitely NVDA specific, now I say that screen readers increase the probability of this problem being triggered. FF behaviour was most regular without any screen reader loaded. Furthermore doing mode switches without a screen reader definitely seem to improve the situation for screen readers at least for a while.

It seems very hard to suspect which component initiates this issue; screen reading under FF is a multiplayer game, many software components interact in very complex ways to produce the needed accessibility. The only thing I know for sure from my long experience in computer programming is that uninitialised variables can produce such nasty situations which are so unpredictable and hard to reproduce because behaviour depends on the values currently found at the memory address of the uninitialised variable and those values can (and should) be considered random. This is especially true with C like languages.

Comment 5 by briang1 on 2011-06-30 07:13
Yes, I got a similar result after reading this. Indeed with Hal, whn I closed Hal I ended up with a mozilla crash report. Seems a bit flaky. anothe interesting aspect is on the multi stage effect. When running narrator,you can actually often hear differences when f11 is pressed several times, as if part of the screen is changing then going back. The menu problem is less often in Narator as well, but can be induced.

How on earth you go about finding the problem here I'd have noidea, as this sounds like its a Mozilla issue.

Comment 6 by Palacee_hun on 2011-07-07 14:05
I think I have put pieces together and have found out the cause and nature of this issue and I seem to be able to prove my findings by the tests below. This issue is not screen reader or accessibility related, but caused by a seemingly aimless, sort of buggy behaviour of FF in menus. However sighted users would never notice this, so screen reader usage in fact helps to discover this peculiarity. The behaviourseems entirely predictable and reproducible, nothing sort of random.

Test 1:

1. Switch to fullscreen.
2. Test the fullscreen state by only querying the status bar (which won't be found in fullscreen mode). Don't even try to invoke any menu now.
3. Switch back to normal view.
4. Retest the view mode by the status bar method.

This seems to always work properly, and in step 4. you'll notice that normal view is returned.

Test 2:

1. Switch to fullscreen.

2. Press Alt+F to invoke File menu. Nothing would be spoken and nothing visible would happen on the screen. The menu bar and menu system are invisible in fullscreen view.

3. Work with the document for a while.

4. Try switching back to normal view by hitting F11and test the view mode by the status bar method.
   At this point you won't be able to return to normal mode! Actually this was the issue I had opened this ticket for.

5. Press a single Alt key, Esc or F10. These keypresses quit FF menus.

6. Repeat step 4. Now it will succeed!

   Test 3:

7. Do steps 1 to 3 in Test 2.

8. Switch off browse mode (NVDA+Space).

9. Press two down arrow keys. You won't hear anything when doing this with NVDA running.

10. Press Enter now. You'll land in address bar!

These tests work the same with any screen reader or without one being loaded.

Test 2 gives the explanation. If you invoke any FF menu, FF routes the focus to it, and normally MVDA tracks it and reads menu items. Obviously it isn't possible to switch view modes while in a menu, FF doesn't react to any of its global shortcut keys while in the menu system. The trick occurs when in fullscreen view. The menu bar disappears, but FF still lets you activate it by shortcut keys! When activated nothing happens on screen, but FF still places its invisible internal focus on the activated menu, and behaves as if menus were visible. Test 3 proves this clearly; the third item in File menu (two arrows down) is Open Location, which puts you in address bar when activated. However as menus are invisible in fullscreen, NVDA can't track the focus of FF then and doesn't indicate where FF wanders. In browse mode, nothing strange appears as NVDA does the processing of e.g. the cursoring keys itself. But in focus mode, FF is in play, and cursoring keys move in the menu system, but NVDA won't track it and it isn't seen on screen either, however menu items can still be activated with Enter key! So seemingly mysterious things can happen. And of course F11 won't work in the invisible fullscreen menu either, which results in the reported issue.

Quitting NVDA helps because this makes FF quit and collapse its menu system, and F11 works afterwards because FF focus is not in any menu any more.

Workaround: if you are stuck in fullscreen, the safest way out is pressing F10 that quits that invisible menu then hit F11 and everything will be fine. And beware not to mix up F10 and F11 which is quite easy!

Please try out these tests yourself and report back results. If I get the same or otherwise confirming results, I'll close this ticket as "can't fix" as this is not an NVDA bug.

Comment 7 by jteh on 2011-07-08 01:05
Confirmed. Nice work.

I did discover the invisible menu focus bug a little while ago, but didn't connect the fact that f11 won't work while in menus.

Are you comfortable filing a bug with Mozilla via bugzilla.mozilla.org? If not, I will do it when I have some time.

Comment 8 by briang1 on 2011-07-08 07:33
I wonder if the ramifications of this might explain a recent ticket I saw regarding strange behaviour of nvda when using the mouse on its menus. Certainly if you invoke a windows menu, like the system one, it works, but ff ones are flakey.

Comment 9 by Palacee_hun (in reply to comment 7) on 2011-07-08 20:21
Please file this bug to Mozilla. I have never submitted a bug there, though I have collaborated in other open source projects, so I am generally familiar with bug tracking systems. However I know that each bug tracking environment has its specialities, so I trust you are much more proficient in filing a bug to Mozilla bugzilla. Anyway it's not time-critical, because I described the workaround which is very simple.

Replying to jteh:

Confirmed. Nice work.

I did discover the invisible menu focus bug a little while ago, but didn't connect the fact that f11 won't work while in menus.

Are you comfortable filing a bug with Mozilla via bugzilla.mozilla.org? If not, I will do it when I have some time.

Comment 10 by jteh on 2011-07-11 03:27
A bug has already been filed: MozillaBug:648504.

Comment 11 by jteh on 2012-01-25 08:29
Changes:
Changed title from "NVDA seems to prevent Firefox 3.6 from switching back from fullscreen mode to normal mode with F11 key" to "Firefox menus activate but are invisible in full screen mode"

Comment 12 by bdorer on 2015-02-24 23:14
so, this bug hasn't been fixed by mozilla since 3 years now. I'm able to reproduce this with FF 35.0.1

@jcsteh Could you please mention the URL of MozillaBug:648504 that you had filed? Googling 'MozillaBug:648504' leads me only to this NVDA Github ticket thus preventing me and possibly others from tracking the progress of this issue on the Firefox tracker.

The URL is MozillaBug:648504. The issue is still new and appears to not have any activity in the past year.

This was fixed in Mozilla bug 1192655. Now, it's no longer possible to activate menus in full screen mode at all, which means that f11 will always work to switch off full screen. Bug 648504 is still open because some users want the menus to work even in full screen mode. However, the original concern discussed here (the confusion of f11 not working) is fixed, so I'm closing this.