Native Shell's Menu bar is only a thin line because it is placed too high up.

[kylobite]

It looks like this: http://i.imgur.com/NdVNt.png
You can tell it is the menu because when you mouse over it colors and drops down, but you can't see what tab is being selected. As you can see by the picture this is a on a Mac. Also, I followed the "setup guide" exactly and still got this.

[jrowny]

That's odd, I haven't seen that before. Would you mind pressing Cmd-Option-I and letting us know if there are any errors in the console? Maybe something with LESS didn't quite compile correctly.

[peterflynn]

It looks like all of the HTML content is being positioned too high up (the menu bar is not native UI). Maybe check in the DOM inspector to see where it thinks the top of the document/body is. Also, is the bottom getting clipped too? E.g. if you scroll all the way down in the code editor, can you see the last line of the file or is there still some hidden off the bottom of the window?

[kylobite]

There were no errors in the console and the bottom doesn't cut off, rather there seems to be an extra line in each bit of code it seems. The issue seems to be in the element #main-toolbar .toolbar (

@ line 87).

[kylobite]

What I ended up doing to fix this is going to style/brackets.less and editing the margin-top .toolbar as such:
.toolbar {
/* make sure the shadow goes above other items */
z-index: @z-index-brackets-toolbar;
margin-top:25px; !important
}

[keithschulze]

I'd like to have this issue re-opened because it's still happening and each time I update brackets, I have to apply the op's fix to get it to work. What I'd like to add though it that this only occurs on my macbook with a lower resolution screen (1280 x 800). I have no problem on my iMac (2560 x 1440 - from memory). I've just updated to bracket sprint 13 and installed using the new DMG installer. Cheers.

[njx]

Ah. It's probably because you have the dock at the bottom, and it's making the window open at a smaller size than we want. We increased the size in the latest installer and thought it was ok, but on a 1280x800 screen with the dock open it might just be a little too big. Reopening.

[njx]

Marking medium priority.

[peterflynn]

@njx, it seems unlikely that the window resizing could be causing the HTML content to lay out wrong. You can manually resize the window to be much less tall than that and the layout still works fine. If you look at the original screenshot above, it's like the entire tag has been shifted upwards (or like the CEF native control has gotten shifted up out of the window's client area).

[njx]

The problem is because the window is too small during the initial layout. We saw this in brackets-app as well--if we set the initial default window size to be large, and then ran it on a smaller screen (at least on the Mac), the window would open at a smaller size than what we had set for the default, and for some reason that would cause the top of the app to get cut off. (I'm not sure exactly why--we didn't dig into it; we just set the initial default to be smaller so it wouldn't get resized by the OS.) The problem doesn't occur during later resizes.

[keithschulze]

@njx I can confirm that moving the dock to side fixes the problem. Resizing of the window once the toolbar is obscured doesn't fix the problem though. Cheers.

[peterflynn]

I think Glenn's pull request adobe/brackets-shell#120 contains a side change that fixes this, so assigning to him

[DennisKehrig]

Reproduced with a more extreme result by changing the screen resolution to 800x600 before starting Brackets: http://i.imgur.com/9iwIf.png

[DennisKehrig]

The problem was actually in the shell.
I noticed that even with a screen resolution of 800x600, the HTML node has a height of 700px. This is the result of a CSS rule - height:100%. So I wondered how 100% of the height of a window that is obviously smaller than 600px is actually larger than that.
Basically we start out with a window that is told to be big enough to encompass content of the size 1000x700.
That window gets shrunk by the OS to fit the available screen space.
In that window there is a frame. This frame's size is set with the assumption that the window is as big as requested, which is incorrect for small resolutions.
This frame is used by Chromium for rendering. It is larger than the window and since in Cocoa the zero position is the bottom left corner, with positive values meaning "right" or "up", the top part of that frame just gets cut off.
The pull request corrects that.

[peterflynn]

Glenn's fix has already landed, so this should be fixed in master now. Marking FBNC.

[DennisKehrig]

Sadly, adobe/brackets-shell#120 is only a partial fix. When launching Brackets for the very first time (ever), the bug is still present. This can be simulated by uncommenting [mainWnd setFrameAutosaveName:APP_NAME @"MainWindow"]; in cefclient_mac.mm (then every launch is a first launch) or changing "MainWindow" to something that hasn't been used before (next launch is like the first launch).

Only subsequent launches will use the remembered (corrected) window size. Luckily this is true even when using a high resolution, enlarging the window, closing Brackets, switching to a low resolution and then starting Brackets again.

In addition, the window size is always too small (regardless of screen resolution) when uncommenting // #define SHOW_TOOLBAR_UI in config.h. What is that used for, BTW?

[jasonsanjose]

SHOW_TOOLBAR_UI is probably left over from the sample app that CEF uses for an API demo.

[DennisKehrig]

If we don't need that anymore, we could simplify the window size code a bit.

[DennisKehrig]

Please tell me if I should work on this, I don't want us to overlap

[jasonsanjose]

All yours! :) Let me know when the pull request is updated and I'll review. Thanks!

[DennisKehrig]

@jasonsanjose: Thank you :)
Here's the successor: adobe/brackets-shell#125

[jasonsanjose]

@kylobite The fix has landed from adobe/brackets-shell#125 but you'll either need to (a) wait for the sprint 15 build or (b) build brackets-shell on your own to confirm the fix. I've confirmed it myself, so I'll go ahead and close this issue.