738335 - [10.7] Showing menubar covers firefox window in fullscreen mode (chrome should slide with the menu bar)

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect, P2)

Description

[beingalink]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120322 Firefox/14.0a1
Build ID: 20120322031220

Steps to reproduce:

Enter fullscreen mode, move mouse to the top border of the screen.


Actual results:

The menu bar appeared and covered the top of firefox so that tabs got covered.


Expected results:

When the menu bar appears, the firefox window should size down so nothing gets covered. Basically the same behavior as Safari.

Comment 1

[Nickolay_Ponomarev]

Confirming. Looks like other fullscreen follow-up bugs are tracked as depending *on* 639705 and blocking the lion tracking bug, changing this bug's dependencies to match.

Comment 2

[beingalink]

In my opinion there's a deeper design decision to make. Even if this problem gets fixed, there still remains the fact that in full screen mode the tabs are very close to the top screen border and every time you accidentally touch the screen border with your mouse, the menu slides in. This might be quite annoying.

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to beingalink from comment #2)
> In my opinion there's a deeper design decision to make. Even if this problem
> gets fixed, there still remains the fact that in full screen mode the tabs
> are very close to the top screen border and every time you accidentally
> touch the screen border with your mouse, the menu slides in. This might be
> quite annoying.

Yea, bug 714186 is about adding some padding. I was considering combining these 2 bugs, but I think making this one about any sort of animation while the other is purely about padding is a good trade off.

Comment 4

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

For future reference, NSApplicationPresentationAutoHideToolbar doesn't seem to be exactly what we want, but might be a good starting point.

Comment 6

[Marcia Knous [:marcia]]

As discussed in the channel meeting, adding Asa to the bug.

Comment 7

[Asa Dotzler [:asa]]

Steven, this is a pretty glaring issue with our full-screen implementation. Can you put this somewhere in your list so we can call this feature complete?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #7)

I think this bug is just a minor annoyance.  Though it'd become a little less minor if we implemented a combination of the "old" presentation mode and the Lion fullscreen mode (as per choice #2 in bug 740148 comment #4).

But the "old" (non-Lion-specific) presentation mode does support shrinking or expanding the rest of the page when you unhide or hide the toolbars.  So presumably there's already support in the tree for what needs to be done here (or for part of it).

I'm on vacation next week.  I'll look further into this when I get back.

Comment 9

[u450638]

(In reply to Steven Michaud from comment #8)
> I think this bug is just a minor annoyance.

How many users are buying a new macbook with mountain lion and while playing around with the features of the os (including the fullscreen button) they find out that their favorite browser, firefox, is more annoying to use in fullscreen (a feature they really enjoy) than that other browser?  it completely covers up the tabs... it's a problem :)

Comment 10

[André Reinald]

Looking at Safari, I notice that the shortcut bar also disappears when in fullscreen mode. Then both menubar and shortcut bar appear simultaneously when the pointer touches the upper edge of the screen, but they disappear only when the mouse pointer is back into the web page, which is much lower on the screen (tabs bar + shortcut bar height). Quite a complicated behavior !

Comment 11

[André Reinald]

Please note that actually no Mac application (Safari included) changes the size of the full-screen window, nor scrolls down its content : what happens is that the window's tab bar (and any tool bars) will move down when the menu bar appears, and that will cover the top of the content. My guess is that other applications probably use NSToolbar and NSTabView to handle those, and Cocoa takes care of everything.

I'm now looking for a hook to sync ourselves with the menu bar animations, and I can use help here.

Comment 12

[Markus Stange [:mstange]]

(In reply to André Reinald from comment #11)
> I'm now looking for a hook to sync ourselves with the menu bar animations,
> and I can use help here.

In normal Cocoa apps with a proper NSToolbar, this method is called on every animation step:
-[NSToolbarFullScreenWindowManager updateContentViewWithEffectiveReveal:auxMinHeight:auxMaxHeight:]

with the following callstack:

> frame #1: 0x00007fff864bfc5d AppKit`-[NSToolbarFullScreenWindowManager updateContentViewWithEffectiveReveal:auxMinHeight:auxMaxHeight:] + 1159
> frame #2: 0x00007fff864bf2f7 AppKit`NSToolbarFullScreenWindowEventHandler + 199
> frame #3: 0x00007fff8d2f4f0a HIToolbox`DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1206
> frame #4: 0x00007fff8d2f43d9 HIToolbox`SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 410
> frame #5: 0x00007fff8d30a1bd HIToolbox`SendEventToEventTarget + 40
> frame #6: 0x00007fff8d31acae HIToolbox`MenuBarInstance::SetServerBounds() + 388
> frame #7: 0x00007fff8d31a646 HIToolbox`FlushWindowObject(WindowData*, void**, unsigned char) + 957
> frame #8: 0x00007fff8d31a270 HIToolbox`_FlushWindow + 74
> frame #9: 0x00007fff8d31a21e HIToolbox`HIWindowFlush + 27
> frame #10: 0x00007fff8d31a1b9 HIToolbox`MBarDraw() + 39
> frame #11: 0x00007fff8d2fdf76 HIToolbox`MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, unsigned char) + 388
> frame #12: 0x00007fff8d329144 HIToolbox`SetMenuBarObscured + 221
> frame #13: 0x00007fff8d328e0f HIToolbox`HIApplication::HandleActivated(OpaqueEventRef*, unsigned char, OpaqueWindowPtr*) + 177
> frame #14: 0x00007fff8d326407 HIToolbox`HIApplication::EventObserver(unsigned int, OpaqueEventRef*, void*) + 193
> frame #15: 0x00007fff8d2f46e0 HIToolbox`_NotifyEventLoopObservers + 155
> frame #16: 0x00007fff8d325f8f HIToolbox`AcquireEventFromQueue + 561
> frame #17: 0x00007fff8d31be67 HIToolbox`ReceiveNextEventCommon + 393
> frame #18: 0x00007fff8d31bcd3 HIToolbox`BlockUntilNextEventMatchingListInMode + 62
> frame #19: 0x00007fff85da5613 AppKit`_DPSNextEvent + 685
> frame #20: 0x00007fff85da4ed2 AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
> frame #21: 0x00007fff85d9c283 AppKit`-[NSApplication run] + 517
> frame #22: 0x00007fff85d40cb6 AppKit`NSApplicationMain + 869
> frame #23: 0x0000000100001522 FullScreenToolbarTest`main(argc=3, argv=0x00007fff5fbff7a8) + 34 at main.m:13
> frame #24: 0x00007fff86e087e1 libdyld.dylib`start + 1

You can create a basic app with an NSToolbar an full screen capability in XCode and then add the following code for example to AppDelegate.m:

@interface NSToolbarFullScreenWindowManager @end
@implementation NSToolbarFullScreenWindowManager(CoolOverride)
- (void)updateContentViewWithEffectiveReveal:(double)arg1 auxMinHeight:(double)arg2 auxMaxHeight:(double)arg3
{
    printf("progress: %f\n", arg1);
}
@end

Then you'll see the right values printed during the animation.

Do you have an AppKit class dump? If not, download class-dump and do
>$ /Volumes/class-dump-3.4/class-dump /System/Library/Frameworks/AppKit.framework > ~/Desktop/AppKit108.txt

You'll see undocumented methods in the resulting text file.

I think the way to get updateContentViewWithEffectiveReveal called in a way that Firefox can detect is: Create mock implementations for NSToolbar, NSToolbarFullScreenContentView (if needed), NSToolbarFullScreenWindowManager and any other things that Cocoa requires and make them play in such a way that Cocoa understands us, e.g. hook them up using -[NSWindow setToolbar:], -[NSToolbar _fullScreenWindowManager] etc.

This is going to be hard.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Attachment: Example of interpose library

> I'm now looking for a hook to sync ourselves with the menu bar
> animations, and I can use help here.

I agree with Markus that this is going to be hard.  But it's a
fascinating problem ... at least for those who are interested in
reverse engineering.

Markus has given you some good leads.  Here's another one.

You may end up having to write a test app with fullscreen capability.
But that may be a lot of work, and you can learn a lot by observing
apps that already have them (like Safari and (I think) Chrome).

One way to do this is with gdb.  But that's clumsy and slow.  Another
way is to use what I call an interpose library, which will let you
hook any Objective-C method (using method swizzling), and also any
C/C++ method that's linked from an external library.

Here's an example of an interpose library that I used recently to help
figure out bug 740923.  It plays several interesting tricks, which you
should be able to figure out by reading the source code.  (If you have
any questions, though, please let me know offline.)

Once you've got the library compiled, get a command-line prompt
(e.g. in Terminal), set the DYLD_INSERT_LIBRARIES environment variable
to the path to the library, and then run your target program
(e.g. Safari or Chrome) from the same command-line.  Note that the
interpose library will be inserted in each of Safari/Chrome's
processes.

Comment 14

[Robert Sesek]

I was looking into this for Chromium and ran into this bug. I disassembled pieces of AppKit and found that there's an undocumented Carbon event that Apple uses to track the fraction of the menu bar that has been revealed. That's what NSToolbarFullScreenWindowManager uses. The event class/code is { kEventClassMenu, 2004 }. And then the event parameter holding the fraction is { FOUR_CHAR_CODE('rvlf'), typeCGFloat }. Here's a WIP patch that I'm working on to get our animation better:

https://codereview.chromium.org/12328161/diff/1/chrome/browser/ui/cocoa/presentation_mode_controller.mm

Thought I'd share the knowledge!

Comment 15

[Markus Stange [:mstange]]

Oh cool, thank you!

Then I think the only remaining question is how to prevent the menubar from sliding back up before the mouse cursor has left the exposed toolbar. Do you have a solution for that, too?

Comment 16

[Robert Sesek]

No, I haven't found a way to do that, unfortunately. It seems as if NSApplicationPresentationFullScreen implies menu bar behavior automatically, and since there isn't a NSApplicationPresentationOptions to force the menu bar visible, it may not be possible. We may let the menu bar recede after it's made visible and just use this event to bring down the toolbar in-sync with the menu bar.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Attachment: Initial groundwork for Safari-like approach (using fake NSToolbar)

Here's a start on Markus' suggestion from comment #12.  Turns out we can accomplish a lot just using a fake NSToolbar (plus a couple of additional small hacks).

The work is by no means complete.  But it does show how we might be able to get a Safari-like fullscreen mode in Firefox (or in Chrome, for that matter).  Specifically it shows how we can arrange for an NSView to be attached just below the menubar when, in fullscreen mode, you mouse up to show the menubar.

I'd like for this NSView to display a copy of the top part of the browser window's contents, and for events to be passed from it to Gecko.  The event-passing wouldn't be hard.  But cloning the top part of the browser window would (I think) be very tricky, and might not be possible to do in a reasonably efficient way.

I'm not sure when (or if) I'll have the time to finish this work myself.  So I'm posting it as suggestion for how we might approach this bug.

I've started a tryserver build, which should follow in a few hours.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Attachment: Interpose library for reverse-engineering Safari's fullscreen mode

Most of what I needed to know to write my patch from comment #17 I learned by using an interpose library to reverse-engineer how Safari uses an NSToolbar to implement it's handling of Apple's fullscreen mode.  Here's a copy that logs the most important information.

Unfortunately you can only use it to debug Safari on OS X 10.7 (Lion).  On 10.8 (Mountain Lion) Safari prevents DYLD_INSERT_LIBRARIES from being used on it.  There are a number of ways one might be able to get around this -- including making a copy of Safari, deleting its signature, and signing it yourself.  But it was easier for me just to do my debugging on OS X Lion.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #14)

Are these Carbon events only sent when the window being made fullscreen has an NSToolbar?  I suspect the answer is "yes", because I don't see an NSToolbarFullScreenWindowManager being created or used except when an NSToolbar is present.

Comment 20

[Jorge Luis Mendez [:jlmendezbonini]]

FWIW...Xcode4.6 behaves like Safari.

Comment 21

[Robert Sesek]

(In reply to Steven Michaud from comment #19)
> (In reply to comment #14)
> 
> Are these Carbon events only sent when the window being made fullscreen has
> an NSToolbar?  I suspect the answer is "yes", because I don't see an
> NSToolbarFullScreenWindowManager being created or used except when an
> NSToolbar is present.

That may be what Safari does (because it only cares about the events when in fullscreen), but no, these events are delivered without an NSToolbar being present.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #21)

Thanks.  I'll create another interpose library to track when those events are created, and maybe also when they're consumed.  Hopefully that'll give us a better idea of exactly how the OS uses them.

Comment 23

[Robert Sesek]

(In reply to Steven Michaud from comment #22)
> (In reply to comment #21)
> 
> Thanks.  I'll create another interpose library to track when those events
> are created, and maybe also when they're consumed.  Hopefully that'll give
> us a better idea of exactly how the OS uses them.

I can tell you that :).

They're consumed in NSToolbarFullScreenWindowEventHandler, which is the UPP installed in -[NSToolbarFullScreenWindowManager _makeWindowIfNecessary]:

(gdb) bt
#0  0x00007fff8b3de9f5 in InstallEventHandler ()
#1  0x00007fff940401f7 in -[NSToolbarFullScreenWindowManager _makeWindowIfNecessary] ()
#2  0x00007fff940433c0 in -[NSToolbarFullScreenWindowManager setToolbar:] ()
#3  0x00007fff93eb5573 in -[NSToolbar _installFullScreenToolbar] ()
#4  0x00007fff9382d26c in -[NSWindow setStyleMask:] ()
#5  0x00007fff93ef93cc in -[NSWindow _makeFullScreenWindow] ()
#6  0x00007fff9404ced3 in -[_NSWindowFullScreenTransition setWindowToHaveFullScreenSize] ()
#7  0x00007fff9404af7d in -[_NSFullScreenTransition enterFullScreenTransitionWithOptions:animated:activatingIt:] ()
#8  0x00007fff93ef9afc in -[NSWindow _enterFullScreenMode:animating:activating:] ()
#9  0x00007fff93a16a59 in -[NSApplication sendAction:to:from:] ()
#10 0x0000000100050c76 in -[BrowserApplication sendAction:to:from:] ()
#11 0x00007fff93a168b7 in -[NSControl sendAction:to:] ()
#12 0x00007fff93a167eb in -[NSCell _sendActionFrom:] ()
#13 0x00007fff93a14cd3 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#14 0x00007fff93a14521 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] ()
#15 0x0000000100015f1e in safari_NSButtonCell_trackMouse ()
#16 0x00007fff93a13c9c in -[NSControl mouseDown:] ()
#17 0x00007fff93a0b60e in -[NSWindow sendEvent:] ()
#18 0x00000001002c2fdc in -[Window sendEvent:] ()
#19 0x00000001000b3b3b in -[BrowserWindow sendEvent:] ()
#20 0x00007fff93a07744 in -[NSApplication sendEvent:] ()
#21 0x0000000100050e2e in -[BrowserApplication sendEvent:] ()
#22 0x00007fff9391d2fa in -[NSApplication run] ()
#23 0x00007fff938c1cb6 in NSApplicationMain ()
#24 0x0000000100224d54 in SafariMain ()
#25 0x00007fff88cbd7e1 in start ()

The MenuBarInstance in HIToolbox sends them synchronously as it's animating.

Comment 24

[Markus Stange [:mstange]]

This is looking good, Steven.

(In reply to Steven Michaud from comment #18)
> Unfortunately you can only use it to debug Safari on OS X 10.7 (Lion).

I'm not sure why you're testing with Safari. The toolbar functionality is common to all native Cocoa apps with toolbars, isn't it? In case it helps, I made a quick screencast that shows how simple it is to create a small fullscreenable app with a toolbar: http://tests.themasta.com/screencast-fullscreen-toolbar-app.webm

Comment 25

[Steven Michaud [:smichaud] (Retired)]

Attachment: Interpose library to hook rvlf events

> these events are delivered without an NSToolbar being present

As best I can tell, Robert, this is wrong.

I used this interpose library to test with Safari, Chrome, Opera and Firefox.  Only in Safari did any of these events get sent (when in fullscreen mode).  And only in Safari does an NSToolbar get created and attached to an NSWindow.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

(In response to comment #24)

> I'm not sure why you're testing with Safari.

I know Safari is a good example of the behavior I want to examine.  But my interpose library could easily be used with other apps -- including your test app.

What we need to know is how "native-Cocoa" fullscreen mode works under the hood.  It's not too hard to find that out using a test app.  But it's even easier to do it using an interpose library (at least I think so).  And you have the advantage that you catch any special tricks a particular app (like Safari) might play.

Comment 27

[Steven Michaud [:smichaud] (Retired)]

> I'd like for this NSView to display a copy of the top part of the
> browser window's contents, and for events to be passed from it to
> Gecko.  The event-passing wouldn't be hard.  But cloning the top
> part of the browser window would (I think) be very tricky, and might
> not be possible to do in a reasonably efficient way.

Markus, do you have any ideas about cloning the	top part of the
browser window into the fake NSToolbar's accessory view?

Comment 28

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #26)

Interestingly, Apple's DVD Player (which has a well-designed fullscreen mode) doesn't use an NSToolbar, and doesn't send/process any of the rvlf events.

I tested on OS X 10.7.5.

Comment 29

[Steven Michaud [:smichaud] (Retired)]

XCode, which Jorge said in comment #20 has a fullscreen mode like Safari's, and which does have an NSToolbar, does send/process the rvlf events.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

Two more Apple apps that have fullscreen modes but no NSToolbars, and which don't send/process rvlf events:  iMovie and iPhoto.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 726815 [details] [diff] [review]
Initial groundwork for Safari-like approach (using fake NSToolbar)

Here's a tryserver build made from my patch from comment #17:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f371718300d5/try-macosx64/firefox-22.0a1.en-US.mac.dmg

Comment 32

[Markus Stange [:mstange]]

(In reply to Steven Michaud from comment #27)
> > I'd like for this NSView to display a copy of the top part of the
> > browser window's contents, and for events to be passed from it to
> > Gecko.  The event-passing wouldn't be hard.  But cloning the top
> > part of the browser window would (I think) be very tricky, and might
> > not be possible to do in a reasonably efficient way.
> 
> Markus, do you have any ideas about cloning the	top part of the
> browser window into the fake NSToolbar's accessory view?

We could do something like we do for drawing in the titlebar, i.e. set up a toolbar-sized buffer which we update when necessary, and then just draw the buffer into the toolbar accessory view. But a better solution would be not to have a separate toolbar view and instead only update the real window behind it. But for that we'd have to make the toolbar view completely transparent.

This seems to do the job:

@interface NSToolbarFullScreenContentView @end

@implementation NSToolbarFullScreenContentView(Override)
- (void)drawRect:(NSRect)rect
{
  [[NSColor clearColor] set];
  NSRectFill(rect);
}
@end

Just drawing nothing in the ToolbarAccessoryView isn't enough; the view that's actually visible is an NSToolbarFullScreenContentView which paints gray window chrome behind what we paint in the ToolbarAccessoryView. (Actually, it looks like the ToolbarAccessoryView's drawing is only captured once in updateAuxViewSnapshot, and then NSToolbarFullScreenContentView repeatedly draws the snapshot on top of the gray chrome background.)

Comment 33

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #25, comment #28 and comment #30)

Actually, now that I think about it, the rvlf events *aren't* necessarily tied to the presence of an NSToolbar (and the consequent presence of an NSToolbarFullScreenWindowManager).  If you install a handler for them, you'll start receiving them.

-[NSToolbarFullScreenWindowManager _makeWindowIfNecessary] does this.  But so does Robert's patch from comment #14.

Comment 34

[Robert Sesek]

(In reply to Steven Michaud from comment #33)
> (Following up comment #25, comment #28 and comment #30)
> 
> Actually, now that I think about it, the rvlf events *aren't* necessarily
> tied to the presence of an NSToolbar (and the consequent presence of an
> NSToolbarFullScreenWindowManager).  If you install a handler for them,
> you'll start receiving them.
> 
> -[NSToolbarFullScreenWindowManager _makeWindowIfNecessary] does this.  But
> so does Robert's patch from comment #14.

Yes, that's what I was getting at. -_makeWindowIfNecessary is what installs it normally in AppKit as part of NSToolbar, but you can install your own Carbon event handler to receive this event and perform any UI updates yourself. The code review link shows an example of how I did this in Chromium.

Comment 35

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #32)

> But a better solution would be not to have a separate toolbar view
> and instead only update the real window behind it.

I don't understand.

I think there needs to be a separate ToolbarAccessoryView, because its
contents are displayed lower down than the contents of the original
browser window (lower down by the width of the menu bar -- presumably
22 pixels).  This is necessary in order to stop the top part of the
browser window from being obscured by the menu bar, when the user
mouses up and causes it to be unhidden.

Of course we could take a different approach, and use rvlf events to
"animate" pushing the browser window's contents down by the width of
the menu bar.  Our "non-native" fullscreen mode (used on OS X 10.6)
already does something like this.

> We could do something like we do for drawing in the titlebar,
> i.e. set up a toolbar-sized buffer which we update when necessary,
> and then just draw the buffer into the toolbar accessory view.

I'll look into this, and dig around for possible alternatives.  I
don't want to give up the fake NSToolbar approach just yet.  But we
may very well end up falling back to using rvlf events.

Comment 36

[Markus Stange [:mstange]]

(In reply to Steven Michaud from comment #35)
> Of course we could take a different approach, and use rvlf events to
> "animate" pushing the browser window's contents down by the width of
> the menu bar.  Our "non-native" fullscreen mode (used on OS X 10.6)
> already does something like this.

Exactly, that's what I was thinking of. Some browser JS could move the toolbar in response to the rvlf events, for example. (This doesn't necessarily mean that we'd still push the browser viewport down. We can change the animation so that it looks just like the native animation.)

The advantage of the NSToolbar / accessory view approach is that it keeps the menubar visible while the mouse is over the toolbar. That's the only part that was missing before, I think, so I think we should combine both approaches.

> > We could do something like we do for drawing in the titlebar,
> > i.e. set up a toolbar-sized buffer which we update when necessary,
> > and then just draw the buffer into the toolbar accessory view.
> 
> I'll look into this, and dig around for possible alternatives.  I
> don't want to give up the fake NSToolbar approach just yet.  But we
> may very well end up falling back to using rvlf events.

The problem with the drawintitlebar buffer approach is that it requires significant complexity behind the scenes, see bug 625989 comment 60. We want to be able to get rid of the code that lets us support two different layer managers on the same window. At the moment, titlebar drawing is the only thing that needs that complexity, and bug 676241 would get rid of that requirement.

Comment 39

[Dario]

I don't think that this a "minor annoyance". Two weeks after switching to a mac, I already think about switching to another browser, even though I use and like Firefox for many years.
I can't believe that this bug is listed for three years already!

Comment 40

[Mike de Boer [:mikedeboer]]

Markus, is there a chance to find a new owner for this work?

Comment 41

[Markus Stange [:mstange]]

I don't know of anybody, sorry. And I'm pretty busy fixing scrolling at the moment.

If somebody wants to step up and throw themselves at the problem, I'll be happy to mentor them.

Comment 42

[mistry.1]

Dear Markus,
I would want to take up this bug and work on it.

Actually I am a fresher but am keenly interested in helping out. So if you guide me, I would surely be of some help.

Regards.

Comment 43

[mistry.1]

(In reply to Markus Stange [:mstange] from comment #41)
> I don't know of anybody, sorry. And I'm pretty busy fixing scrolling at the
> moment.
> 
> If somebody wants to step up and throw themselves at the problem, I'll be
> happy to mentor them.

Dear Markus,
I would want to take up this bug and work on it.

Actually I am a fresher but am keenly interested in helping out. So if you guide me, I would surely be of some help.

Regards.

Comment 44

[Markus Stange [:mstange]]

Great! I'll send you an email.

Comment 45

[mistry.1]

(In reply to Markus Stange [:mstange] from comment #41)
> I don't know of anybody, sorry. And I'm pretty busy fixing scrolling at the
> moment.
> 
> If somebody wants to step up and throw themselves at the problem, I'll be
> happy to mentor them.

Hi Markus,
I think that my emails are getting into your spam folder and thus not reaching out to you. So as said earlier, I have compiled the source code and also know how to submit a patch. 

I now just need some guidance. Looking to hear from you soon.

Comment 46

[Markus Stange [:mstange]]

It took me a while to wrap my head back around this bug. I've written down some instructions on https://public.etherpad-mozilla.org/p/osx-fullscreen-menubar .

Comment 50

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 55

[milesseventh]

Will it ever be fixed? It may sound minor, but in fact it is significant usability issue on Mac OS.

Comment 57

[sheelgautam995]

Vivaldi has done what Safari does.

Comment 58

[sheelgautam995]

https://bugs.chromium.org/p/chromium/issues/detail?id=868398#c14

Comment 59

[arnav]

Seriously?

Comment 60

[Anthony Ramine [:nox]]

As a temporary workaround, I tried making an extension that would use the content's fullscreen API to put the root element in fullscreen, after I observed that putting a Youtube video in fullscreen correctly hides all the bars (albeit you can't see them anymore until you quit the fullscreen mode).

Unfortunately, that idea is currently blocked on bug 1638659.

As a temporary workaround for the temporary workaround, I ended up doing a bookmarklet:

javascript:div=document.createElement('div');div.style="position:fixed;z-index:100000;top:10px;left:10px;background:red;height:10px;width:10px";div.onclick=()=>{document.documentElement.requestFullscreen();div.remove()};document.body.append(div);

This will add a red square in the top left corner of the page, which will make the root element go fullscreen when clicked on.

Comment 62

[Nye Liu]

Even worse, now in BigSur the macos menu bar gets stuck down.

Steps to reproduce:

1. fullscreen a firefox window with only one tab
2. ctrl click top of firefox menubar not in the tab (to the right of the last tab)
3. toggle "Hide Toolbars" (on or off)
4. move mouse to top of screen to have the apple menu bar scroll down

now it should be stuck down, and will not roll up. To get it to roll up, do one of the following:

1. switch to a non-fullscreen normal desktop, and back to firefox (should always work)
2. CMD-H or Firefox->Hide firefox (doesn't always work)

If you switch to a full-screen app and back, the menubar will stay rolled down.

it seems to be related to the browser.fullscreen.autohide option.

"Open all in tabs" will also trigger this behavior if you mouse to the top of the screen and the menubar comes down while tabs are still loading.

Comment 65

[barrywcook]

This also reported as Bug 1677299 - which was closed today because this thread predates it. By several years, by the looks of it.

Current status suggests that -

• when in Full Screen, you can open and left-click tabs without issue. The (blank white) Firefox tab (with the 'traffic lights') and the Menu tab will appear if cursor taken to top of screen, and retract when cursor pulled away. As it should be.

The problem appears (at least here) -

• if you right-click any tab and then later use cursor at top of screen to access Firefox and Menu bars. These bars slide into place and then freeze - partially blocking the Firefox toolbar. They will not retract when cursor moved away.

The only sure way to regain control of Firefox is as noted above - to use Menu bar > View > Exit Full Screen, and allow it to return to default size.

Currently on Firefox 84.0.1 with Big Sur 11.1. No issue with this prior to installing Firefox 82, several days after the install of Big Sur 11.0.1

Comment 66

[barrywcook]

ADDENDUM to above:

Neither Safari nor Microsoft Edge for Mac experiencing this freezing issue with Firefox and Menu bar while in Full Screen .
In case of Edge, near identical Add-ons included as with Firefox.

Comment 67

[Nye Liu]

Updated to BigSur 11.2, same issue.

Comment 68

[Nye Liu]

I think the priority of this bug should be bumped. It's been sitting here for 9 years and the current incarnation of the ticket makes ff unusable in full screen mode.

Comment 69

[Nye Liu]

Updated to BigSur 11.2.1, same issue

Comment 70

[Jmicro]

Same issues here as well, BigSur 11.2.1.

Would be nice if this get finally fixed, Firefox is the only Application i don´t use in Fullscreen because its uncomfortable to use if you lide up with ethe Mouse and the Menue Bar hide the Tabs.

Comment 71

[barrywcook]

Firefox 86.0 (running on MacOS 11.2.1) - issue still there.
Sigh. Seriously?

Comment 72

[Harry Twyford]

Attachment: Bug 738335 - Part 1 - Add a NSTitlebarAccessoryViewController to ToolbarWindow to track when the titlebar is shown in fullscreen. r?#mac-reviewers

Comment 73

[Harry Twyford]

Attachment: Bug 738335 - Part 2 - Add CSS rules to shift the toolbar over the content when the macOS menubar is shown. r?#mac-reviewers,#desktop-theme-reviewers

Depends on D106846

Comment 74

[Phabricator Automation]

Comment on attachment 9206211 [details]
Bug 738335 - Part 1 - Add a NSTitlebarAccessoryViewController to ToolbarWindow to track when the titlebar is shown in fullscreen. r?#mac-reviewers

Revision D106846 was moved to bug 1699506. Setting attachment 9206211 [details] to obsolete.

Comment 75

[Phabricator Automation]

Comment on attachment 9206212 [details]
Bug 738335 - Part 2 - Add CSS rules to shift the toolbar over the content when the macOS menubar is shown. r?#mac-reviewers,#desktop-theme-reviewers

Revision D106847 was moved to bug 1699506. Setting attachment 9206212 [details] to obsolete.

Comment 76

[barrywcook]

Now on MacOS 11.2.3, running Firefox 87.0 - issue still there.

Apple menubar in full-screen continues to freeze-up over Firefox menubar if beckoned, though consistent replication of the issue seems to depend on nothing in particular now.
View > Exit Full Screen remains escape out of frozen state - no access to Firefox menubar.

Like others above, disappointed that this is only browser (and maybe app) with this issue, and we're again at a new Firefox with no resolution. If I'm multi-tasking on my Mac requiring browser to be open and quickly accessible by a swipe, I end up using another browser.

Comment 77

[Harry Twyford]

This feature will be enabled in the next Nightly for macOS <11 (bug 1701107). It is disabled on macOS 11 due to bug 1700211. macOS 11 users can enable the pref full-screen-api.macos.shiftToolbar if they want to try this behaviour out early.

Comment 78

[barrywcook]

Harry -
re: about: config pref setting noted above for MacOS 11 - enabled - no change. Apple menubar eventually freezes if beckoned.
BTW, I was not aware of issue as per bug 1700211.

Comment 79

[Harry Twyford]

Are you on a recent Nightly? And did you restart Firefox after changing the pref?

Comment 80

[barrywcook]

(In reply to Harry Twyford [:harry] from comment #79)

Are you on a recent Nightly? And did you restart Firefox after changing the pref?

Not on the Nightly - your note above suggests that is only applicable for < MacOS 11; disabled but for the setting you provided for MacOS 11. Did I read that wrong? Did you mean use the Nightly AND try this setting?
Restarted Firefox (87.0) after enabling. No change.

Comment 81

[Harry Twyford]

Sorry that I wasn't clear. The feature is only available on Firefox 89+, which is current Nightly. It's enabled by default for macOS <11 and (currently) disabled for macOS 11. It can be optionally enabled on macOS 11 by setting the pref full-screen-api.macos.shiftToolbar to true and restarting Firefox. We're hoping to fix bug 1700211 soon and get it enabled by default on macOS 11 as well.

Comment 82

[Harry Twyford]

Attachment: Bug 738335 - Enable toolbar shifting for all users. r?#mac-reviewers

Depends on D109988

Comment 83

[barrywcook]

(In reply to Harry Twyford [:harry] from comment #81)

Sorry that I wasn't clear. The feature is only available on Firefox 89+, which is current Nightly. It's enabled by default for macOS <11 and (currently) disabled for macOS 11. It can be optionally enabled on macOS 11 by setting the pref full-screen-api.macos.shiftToolbar to true and restarting Firefox. We're hoping to fix bug 1700211 soon and get it enabled by default on macOS 11 as well.

Ah, thanks for the clarification, Harry. Though I've tried Nightly in the past, I'm sticking with regular consumer version at the present. Just one less 'Adventures in Appland' to concern myself with in MacOS.

I guess I'll just hang back and see how long it takes for the fix to make its way down the food chain to the regular rabble. And / or put FF on the backburner and use one that gets along with MacOS 11 until then. 😢

Comment 84

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b9387e9e623
Enable toolbar shifting for all users. r=mac-reviewers,bradwerth

Comment 85

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/0b9387e9e623

Comment 86

[Alexandru Trif, Desktop QA [:atrif]]

Confirming that toolbar shifting is enabled by default on macOS 11.2.3, 10.15, 10.14, 10.13, and 10.12.

Comment 87

[beingalink]

(In reply to barrywcook from comment #78)

Harry -
re: about: config pref setting noted above for MacOS 11 - enabled - no change. Apple menubar eventually freezes if beckoned.
BTW, I was not aware of issue as per bug 1700211.

This is still happening here on current nightly 89.0a1 (2021-04-18) (64-Bit). Is there a separate bug for this?

Comment 88

[Nye Liu]

Toolbar shifting seems almost entirely unrelated to the bug described in this ticket. The menu bar freezing is an independent bug.

Comment 89

[Harry Twyford]

(In reply to beingalink from comment #87)

(In reply to barrywcook from comment #78)

Harry -
re: about: config pref setting noted above for MacOS 11 - enabled - no change. Apple menubar eventually freezes if beckoned.
BTW, I was not aware of issue as per bug 1700211.

This is still happening here on current nightly 89.0a1 (2021-04-18) (64-Bit). Is there a separate bug for this?

Yes, the menu bar/title bar freezing is tracked in bug 1687055.

Comment 90

[izak723]

This is just as bad

Can we just have the option to use tabs on the bottom of the screen where the status bar is? (make it optional of course)