Closed Bug 127244 Opened 19 years ago Closed 13 years ago

When in full screen mode, Alt+letter keystokes permanently kill menu

Categories

(Firefox :: Menus, defect)

x86
All
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME
Firefox 3

People

(Reporter: neil, Assigned: seairth)

References

Details

Attachments

(2 files, 5 obsolete files)

Using Build ID: 2002022103
Steps to reproduce problem:
1. Press F11
2. Press Alt+F, Alt+E, Alt+V, Alt+S, Alt+G, Alt+B, Alt+T, Alt+H, Alt+D, Alt+Q
3. Pesss F11
4. As 2.

Expected results: can open all the menus when back in normal mode.

Actual results: cannot open any menus, even with the mouse.
works for me in a trunk build pulled about 2 hours ago on win2k.
Assignee: hyatt → hewitt
Okay, I lied (or something). The first time I tried this, while in fullscreen
mode, Alt-[FEV] would show the menu popup for the respective key. And then when 
I F-11'd back to normal mode, the menu popups would still show for each key.

Then I tried it again, and the popups do not show (not sure what changed). 
Curiously, the keybindings work correctly (e.g.., Alt-E, E will bring up pref 
dialog) even though the popups do not show.
Right, so as long as I can remember the accelerators I'm OK :-)
Severity: normal → minor
*** Bug 132094 has been marked as a duplicate of this bug. ***
*** Bug 149315 has been marked as a duplicate of this bug. ***
I can reproduce this, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1)
Gecko/20021130; 

1. Start Mozilla. Press F11 immediately to put it into full screen mode
2. Press Alt + b , Alt + f, etc. This should make menus appear, but doesn't. 
3. Make Mozilla non-fullscreen (i.e., F11 again.). Click on the menu bar 
   items; the items for which we have pressed the shortcut keys in 
   fullscreen don't work (that is, don't produce menus), whereas the others 
   do.
4. Make Mozilla fullscreen again. Now, the Alt + %c keys work (produce menus) 
   for the other menu bar items, but don't for the items which had their keys
   pressed earlier in full screen mode. 

I, also, can reproduce this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.3a) Gecko/20021212

This bug also exists if you press F10 and return/spacebar in fullscreenmode
instead of ALT+[F, E, V etc]

This bug is not reproducible if you press ALT+[F, E, V etc] while in normal mode
and then press F11.
I've also noticed this problem for quite some time (since Moz .96 I believe up
through 1.3) on WinXP/Win2000/Linux.

I just noticed some interesting behavior in regards to this bug.
Each menu that I bring up once (ex. Alt-b to bring up bookmarks) will be
available to me when I go F11 to full screen.  All the menus I didn't bring up
before going F11 (in this case, Alt-f,e,v,g,t,w,h,u,q) will not come up in full
screen mode and will be permanently broken (i.e., won't come up w/the
appropriate Alt key) even after turning full screen off. 

I personally love the full screen mode, so one quick (albeit dumb) user fix for
this is to bring up each menu once (i.e., Alt-f, then left arrow key ~9 times)
BEFORE hitting F11, then I can safely F11 and pull up all the menus in full
screen mode.  Of course, this is just a quick fix and not a real solution.

Thanks for reading,
Eric Pierce

eric_wmaker
at
yahoo.com

*** Bug 216966 has been marked as a duplicate of this bug. ***
*** Bug 216518 has been marked as a duplicate of this bug. ***
I see this bug off and on. The other day I tried and it worked as expected. Then
the next day it did not.

A not verified thing is that I seem to have this only when I'm in tabbed mode.
With that I mean when I have two or more pages open i tabbed mode.
Actually Eric Pierce in comment #8 seem to be very good description on how this
problem works. I've done some more testing. And his description seem to be right
on spot.

I did these test on trunk released 2003-08-22. So it's still there.
*** Bug 221799 has been marked as a duplicate of this bug. ***
*** Bug 257364 has been marked as a duplicate of this bug. ***
This bug is still visible in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.2) Gecko/20040816 Firefox/0.9.1+

From comment 8 setting OS => ALL 
OS: Windows 95 → All
Assignee: hewitt → nobody
Severity: minor → normal
Component: XP Toolkit/Widgets: Menus → Menus
Flags: blocking-aviary1.1?
Product: Core → Firefox
QA Contact: jrgmorrison → menus
Target Milestone: --- → Firefox1.1
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6

I cannot reproduce this behavior.  As there has been no activity on this for the
past year, can we get a few more confirmations and then close this?
I still get this when I run Deer Park alpha 2 nightly builds.

If you have not opened the menu and then go into fullscreen and try to open.
Then the menu is not available any longer. You have to restart Firefox to get it
back. So I would say it's till there. Same thing happens in 1.0.6.
I just downloaded the latest available version (Firefox 1.06, {for
MicrosoftWindoze}),
and the bug is still there. Try the following:
1)start Firefox.
2)press F11 to get into full screen mode.
3)press Alt B to pull down the Bookmark menu.
result:nothing happens, i.e. the menue doesn't come down
       as it does when you are not in full screen mode.
 This is the main problem as far as I'm concerned,
 since the program must be usable with keyboard input
 be it in full screen mode or not.
 However, the problem with that bug goes further:
4)press Esc to enable keystroke input again
 (without Esc Firefox does not react to anything exept F4 or AltF4).
5)press F11 again to get back into non-full screen mode.
6)try to access the bookmark menue with either the keyboard or the mouse.
result:nothing. It is impossible to access the bookmark menu anymore.
       You have to close down Firefox and start it again.
Ahh!  Got it this time.  Okay, I looked around in the code and here is what I
have found so far:

When entering fullscreen, non-fullscreen toolbars are collapsed (via
setAttribute("moz-collapsed", "true"), which in turn matches a CSS style setting
"visibility:collapsed").  As a result of this, I venture to guess that the
problem isn't that the keyboard accelkeys don't work, but rather that sometimes
they do work when they shouldn't.  In otherwords, since the XUL <toolbar>
element is collapsed, then all of its children (including the <menupopup>
elements) are also effectively collapsed.

As a result, the proper behavior (as currently implemented) is to not display
the popups.  Of course, it's not proper behavior to break the popups when you
come out of fullscreen mode.

So... which way do we go with this:

1) Fix the actual bugs as currently designed (no popups during fullscreen, but
working at all other times).
2) Treat this as an enhancement and change the actual design (fixing the bugs
along the way).
I would say fix the bugs. If it as the moment is designed that when the menu bar
is collapsed the keybord shortcuts for the menubar should not be available. And
by that not destroying normal work. Then fine.

The menu item I try to choose every time I get this problem is bookmarks. And
bookmarks you can get with another keyboars shortcut. So I can learn that way of
getting to the bookmarks when in fullscreen.

If there are things needed in fullscreen and only available in the menues now.
Maybe add new shortcuts. The menu is not available with the mouse. So you use
the keyboard anyway. And I guess that the people who have this problem are
probably like me. Use the keyboard as often as possible. Not use the mouse.
Okay, here is an initial patch (applied to "Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6"), which I can redo for the
current build once people confirm this is how we want to handle things.

To explain, when the browser goes to fullscreen, I temporarily move the
"accesskey" attribute of the menus to "saved-accesskey".  When returning from
fullscreen, the attribute values are put back.	The net effect is that the
<menu> elements do not react to their Alt+Letter until they are visible again.
I've never done any development on firefox, or mozilla. So I do not know if this
is a good solution. I manually applied it to my copy of Deer Park Alpha 2 from
2005-08-07. And it works. And I think this is a great first step. And as I said
before. You can still access most things with there normal shortcut so the menus
is not nessecery for the non-mouse user.

Thank you for making the patch. Just one question. Isn't the patch made in the
wrong direction?? The patch utility can be run to handle that. But I think it
should be the other way arount with + instead of -.
Attached patch correct patch (still for 1.0.6) (obsolete) — Splinter Review
You are right.	How careless of me.  Here is an updated copy going the right
direction.

I tried to make an updated version from the nightly build, but I seem to be
having problems getting my hands on it.
Comment on attachment 192455 [details] [diff] [review]
patch to keep collapsed menus from breaking

see corrected patch
Attachment #192455 - Attachment is obsolete: true
Flags: blocking-aviary1.0.7?
Please don't nominate bugs for blocking 1.0.7 unless they are security issues or
regressions from security fixes on that branch.
Severity: normal → minor
Flags: blocking-aviary1.0.7?
Assignee: nobody → seairth
Attached patch Updated for FF 1.5 Beta 1 (obsolete) — Splinter Review
Attachment #192601 - Attachment is obsolete: true
Attachment #195824 - Flags: review?(mconnor)
Status: NEW → ASSIGNED
I don't know why this was denied for 1.5 but IMHO it should be renominated once
we have a patch reviewed and ready to go. This definitely should be fixed for
Firefox 1.5, it drives me nuts when I run into it.
In fairness, I had set the wrong flag to get the patch reviewed.  Now that I
better understand the process, I got the new patch updated and have requested
review on it.  Whether it should be a 1.5 blocking issue, that's up to others. 
I'm not touching that flag again!  :)
I've no idea if this technique even applies to Firefox's customizable toolbars,
and it is a bit of a hack, since I can't seem to get zero height to work in
CSS, so I've set it in the XUL and relied on the minimum height to override it
(except when hiding the menu of course), but it does mean the menus are useable
and open in their expected positions even when using F10 and arrow keys.

I could use <content height="0" align="end"> instead of the -moz-box-align
style.
Attachment #195824 - Flags: review?(mconnor) → review?(mconnor)
Attachment #196032 - Attachment is obsolete: true
The bug can be reproduced on Firefox 1.7.12 (Polish).
Menus don't appear in Fullscreen mode (F11), pressing F11 again to return to normal mode doesn't work either - one has to either press Esc (as if closing the open albeit invisible menu) or click the restore icon (right upper corner). But then the menus don't work anymore, as in the bug description.
*** Bug 316329 has been marked as a duplicate of this bug. ***
I reproduced this bug in FF 1.5.0 RC2

RE post 8: opening menus prior to going into full screen will not nessesaraly make them accesable in F11 mode, but will stop them from being broken; ie:


                          possible behaviors

alt+key prior to F11      acessable in F11; innacessable in F11 and still               
                          accessable after exiting fullscreen

no alt+key prior to F11   accessable in F11; innaccesable in F11 and then 
                          inaccessable after exiting fullscreen


'Innaccessable' menus can still be accessed, in both fullscreen and normal mode, by using alt+key, then the down arrow a few times and then enter (will, for example, take you to one of your bookmarked sites); but no graphics will be displayed for that menu.

RE post 11: I have experienced it with no tabs open, ie just viewing one webpage.
(In reply to comment #28)
> In fairness, I had set the wrong flag to get the patch reviewed.  Now that I
> better understand the process, I got the new patch updated and have requested
> review on it.  Whether it should be a 1.5 blocking issue, that's up to others. 
> I'm not touching that flag again!  :)

I can reproduce that bug with Firefox 1.5 on Windows and GNU/Linux.
Since I am a heavy keyboard user this is the most annoying bug in FF.
Please touch that flag again! :)
I reproduced this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4.

I found the despription in comment #8 the most concise.
Yes, it's unbelievable that this bug is still around (about 3 years or more).
I remember that seairth@seairth.com worked at it and fixed it (or in collaboration with some others who I forgot), and that was around one year ago.
Why does this not translate into all these numerous updates ?????
All they seem to be about is bloody "security" but not about improvements that matter. I am desperate as far as often now using the Microsoft product out of sheer frustration.

Carsten
*** Bug 344035 has been marked as a duplicate of this bug. ***
This bug was reported 4.5 years ago and it is still present in Firefox 2.0 beta1.
Can reproduce bug still in

Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

.
(In reply to comment #39)
> Can reproduce bug still in
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.6) Gecko/20060728
> Firefox/1.5.0.6
> 
> .
> 

Downloaded latest FF2.0 release and hit the keystrokes.
Even in the release version it still exist. In full screen
(after F11) no hotkeys to the menu.

After restore to non-full-screen the File, Edit, View, History and Help
menu cannot be opened with the mouse or KB anymore. Only Bookmarks and
Tools menu options are working.
(In reply to comment #40)
> (In reply to comment #39)
> > Can reproduce bug still in
> > 
> > Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.6) Gecko/20060728
> > Firefox/1.5.0.6
> > 
> > .
> > 
> 
> Downloaded latest FF2.0 release and hit the keystrokes.
> Even in the release version it still exist. In full screen
> (after F11) no hotkeys to the menu.
> 
> After restore to non-full-screen the File, Edit, View, History and Help
> menu cannot be opened with the mouse or KB anymore. Only Bookmarks and
> Tools menu options are working.
> 

Tested again and found that the problem is not consistent. After retest the
File, Edit and View menu do not open with mouse anymore. 
common guys... still present in FF 2.0.0.0 for ubuntu...
(In reply to comment #42)
> common guys... still present in FF 2.0.0.0 for ubuntu...
> 

Oh, sorry... we thought the bug status of "ASSIGNED" means it is fixed, and the status is set to "FIXED" when it's known to be broken.  We'll get right on it!</sarcasm>
:D

well, now you know better, dont you.

i'm 'sorry' if you think that 'common guys' is too harsh, but the bug's been around since early 2002 -- about 4.5, 5ish years -- and the last patch was, afaict, submitted a year ago, so you can call it a 'bump' if you want.

</facetiousness>

you've had a reports that confirm that the bug is still present in FF2 for windows, now you have one that confirms it's still present in FF2 for linux. if there's any more info that'd be useful, just ask.

just to clarify: i do appreciate the work you guys do, which is why i go to the effort of submitting bug reports :-p
Comment on attachment 198252 [details] [diff] [review]
Better suite hack

For SeaMonkey 1.1 only.
Attachment #198252 - Flags: superreview?(jag)
Attachment #198252 - Flags: superreview?(jag) → superreview+
Reproduced on Ubuntu Edgy with Firefox 2.0.0.2!
Sigh! :(

Attached patch Updated for FF 2.0.0.2 (obsolete) — Splinter Review
Let's try this one more time...  I have updated the patch to work with FF 2.0.0.2, which will hopefully be close enough to apply to the trunk. (I have had problems fetching a trunk copy, hence the patch against the current release.)

If no one reviews the patch this time, I give up on the whole endeavor...
Attachment #195824 - Attachment is obsolete: true
Attachment #256992 - Flags: review?(gavin.sharp)
Attachment #195824 - Flags: review?(mconnor)
Ok, I downloaded and built Firefox 2.0.0.2.
Your patch didn't apply for two reasons:
1. The directory isn't "browser/content/browser" but
"browser/base/content/"
2. Patching gets me "Hunk #1 FAILED at 3120"
Manually editing browser.js at line 3527 works.

I can confirm that your patch works, or at least does what it is intended to do.
1. Go Fullscreen with F11
2. Press Alt-b (no menu since keystrokes are disabled)
3. Return from Fullscreen with F11
4. Press Alt-b, the menu is available *and* visible!
!
As far as this bug is concerned the patch works.
One thing remains: Is it possible to get the keystrokes working in fullscreen mode, too?
Thanks for the good work.
> Your patch didn't apply for two reasons:
> 1. The directory isn't "browser/content/browser" but "browser/base/content/"
> 2. Patching gets me "Hunk #1 FAILED at 3120"

Hmm... I'll have to see about fixing the patch (maybe even basing it on the trunk version).  [Note to reviewer: don't let this stop you from reviewing it or even applying it to trunk.]

> One thing remains: Is it possible to get the keystrokes working in
> fullscreen mode, too?

I think it would be require some pretty serious reworking of the code.  The problem is that the toolbars (which includes toolbar-menubar) have the attribute "moz-collapse" set.  Since the menu element (and associated menupopup element) are contained within the toolbar, they are effectively collapsed as well.  Either the menupopups would have to be moved out of the collapsed toolbar or toolbar-menubar would have to be pseudo-hidden instead of collapsed.
Attached patch Toolkit CSS hackSplinter Review
Basically this uses CSS so that any of the four ways of hiding the menubar don't; instead the menubar is shrunk to zero height and the menuitems are aligned at the bottom so that the menus drop down from the right place.

The hacky bit is that only that way of specifying zero height works.
Attachment #278129 - Flags: review?(gavin.sharp)
Not aware this still existed. Did some tests and able to restore the 
menu's after full screen.

1: F11 for full screen
2: Alt+F Alt+E (only)
3: F11 restore to normal
4: File and Edit menu do not show up anymore, the rest does
5: Try Alt+F then O - the keystroke for Open File still works
6: Right click the empty space in the menu bar and click Customize...
7: Without changing anything, press Done
8: All menu's work as normal again

I am not coding for Firefox, but this might help to find the cause.
Can if be possible that after full-screen the affected menu's are 
behind all the other bars ? Thus that the menu is there but you don't
see it, as all keystrokes function normally even though the menu is 
not visible.


Forgot in my previous post:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Attachment #278129 - Flags: review?(gavin.sharp) → review+
Attachment #278129 - Flags: approval1.9?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091004 Minefield/3.0a8pre

This bug does not happen, but in full screen mode, the menus work from keyboard, but stay invisible.
Attachment #278129 - Flags: approval1.9? → approval1.9+
Comment on attachment 278129 [details] [diff] [review]
Toolkit CSS hack

This patch caused bug 396562 and bug 396565.
This causes problems in my themes (LittleFox, Walnut, Nautipolis and others) because of the following statement in toolbar.xml:
    <content height="0">
      <xul:hbox flex="1">
        <children/>
      </xul:hbox>
    </content>

The menubar itself has now height 0 and is therefor placed strangely...
Can one of the maintainers please explain why the CSS hack approach was prefered over the JS hack approach?  I am not arguing that one is better than the other, rather wondering why there appears to be a preference.  I say this because the JS version (and prior versions of it) sat unreviewed for long periods of time while the CSS one seems to have gotten actual (and relatively quick) attention.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Retested with the just released version. All menu's now work in normal and
full screen mode for me. Also after restore from full screen to normal the
menu's work as normal.

Tested with respect to the menu-bar height. Both in default and walnut theme
the menu bar is displayed normally.
That is FF2.0.0.7. The problem is in FF3.0/Nightlies
Could reproduce bug in 

Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7.

Additionally, after typing e.g. F11 - alt+x (for "extras"), somehow the focus went away from FF with the effect, that F11 didn't work until putting the focus back (by either clicking into the FF window or changing focus to another application and back).

Actually, the focus issue comes from putting the focus into the menu by typing the first shortcut letter and then not typing the appropriate 2nd letter to proceed to the item I wanted to get to. If I type e.g. alt+x - e (for extras - eingabe), the action I intend takes place, but I have to know the second shortcut by heart, because the drop down menu isn't displayed.

Back in normal mode, the respective dropdown menu remains broken in the sense, that it isn't displayed, but it works, when I remember the second shortcut letter and type it.
Comment on attachment 278129 [details] [diff] [review]
Toolkit CSS hack

Resetting approval flags on bugs that have not been checked in by Oct 22, 11:59PM PDT.  Please re-request approval if needed.
Attachment #278129 - Flags: approval1.9+ → approval1.9-
Comment on attachment 278129 [details] [diff] [review]
Toolkit CSS hack

This was already checked-in as rev 1.110 of xul.css on 2007-09-17 15:12.
Attachment #278129 - Flags: approval1.9- → approval1.9?
Comment on attachment 278129 [details] [diff] [review]
Toolkit CSS hack

Setting approval flag (+'ing) as it was already checked in.
Attachment #278129 - Flags: approval1.9? → approval1.9+
Should this be marked FIXED?
(In reply to comment #64)
> Should this be marked FIXED?

Pretty sure it isn't completely fixed yet.
IMO it's really buggy at the moment. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110705 Minefield/3.0a9pre ID:2007110705 shows no submenu anymore when I'm in fullscreen mode. But pressing 'Alt'+S and 'S' afterwards opens the history sidebar as expected. So the submenu seems to open but it's not visible. The user will even be unable to switch back to normal mode with F11 after he hit one of that combinations once.

It's definitely not fixed yet.
It seems to me, that this bug consists out of two problems:

1. that the drop down menus inherit somehow invisibility from the toolbar, when going to full screen mode. 
2. that they don't inherit visibility when going back to normal mode.

When the first issue will be changed, i.e. the toolbar becomes invisible when going to full screen mode, but the drop down menus stay visible, the second issue wouldn't apply and everything would be o.k.
Can reproduce bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9.
Still present in 2.0.0.11...nearly 6 years on, and this bug still isn't fixed.  The priority should be increased, it's really unacceptable that this hasn't been dealt with sooner.  I run into this problem all the time.  The only solution is to restart my browser.  This is definitely not a "minor" inconvenience.
this bug has been fixed in Firefox 3
(In reply to comment #70)
> this bug has been fixed in Firefox 3

At least the not working and killed menu. But what about showing the menus when running Firefox in fullscreen mode? Is there an already existing bug about? 
Target Milestone: Firefox1.5 → ---
I think a new bug should be opened for showing the menu in fullscreen mode.
I filed bug 428981 for the mentioned issue. Lets mark this bug as WFM.

Anyone who can also verify this on Linux?
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-litmus?
Keywords: verifyme
Resolution: --- → WORKSFORME
Target Milestone: --- → Firefox 3
Attachment #256992 - Attachment is obsolete: true
Attachment #256992 - Flags: review?(gavin.sharp)
https://litmus.mozilla.org/show_test.cgi?id=5307 added.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.