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

[core-ai-bot]

Issue by kylobite
Tuesday Jun 26, 2012 at 05:21 GMT
Originally opened as adobe/brackets#1147

---

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.

[core-ai-bot]

Comment by jrowny
Tuesday Jun 26, 2012 at 17:50 GMT

---

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.

[core-ai-bot]

Comment by peterflynn
Tuesday Jun 26, 2012 at 22:07 GMT

---

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?

[core-ai-bot]

Comment by kylobite
Wednesday Jun 27, 2012 at 08:02 GMT

---

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).

[core-ai-bot]

Comment by kylobite
Wednesday Jun 27, 2012 at 08:13 GMT

---

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
}

[core-ai-bot]

Comment by keithschulze
Wednesday Sep 05, 2012 at 23:15 GMT

---

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.

[core-ai-bot]

Comment by njx
Wednesday Sep 05, 2012 at 23:46 GMT

---

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.

[core-ai-bot]

Comment by njx
Wednesday Sep 05, 2012 at 23:56 GMT

---

Marking medium priority.

[core-ai-bot]

Comment by peterflynn
Thursday Sep 06, 2012 at 00:46 GMT

---

@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).

[core-ai-bot]

Comment by njx
Thursday Sep 06, 2012 at 00:50 GMT

---

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.

[core-ai-bot]

Comment by keithschulze
Friday Sep 07, 2012 at 04:52 GMT

---

@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.

[core-ai-bot]

Comment by peterflynn
Monday Oct 01, 2012 at 18:46 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Wednesday Oct 03, 2012 at 13:51 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Wednesday Oct 03, 2012 at 17:23 GMT

---

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.

[core-ai-bot]

Comment by peterflynn
Saturday Oct 06, 2012 at 09:00 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Monday Oct 08, 2012 at 17:56 GMT

---

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?

[core-ai-bot]

Comment by jasonsanjose
Monday Oct 08, 2012 at 18:10 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Monday Oct 08, 2012 at 18:12 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Monday Oct 08, 2012 at 20:13 GMT

---

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

[core-ai-bot]

Comment by jasonsanjose
Monday Oct 08, 2012 at 20:15 GMT

---

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

[core-ai-bot]

Comment by DennisKehrig
Monday Oct 08, 2012 at 22:48 GMT

---

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

[core-ai-bot]

Comment by jasonsanjose
Wednesday Oct 10, 2012 at 18:44 GMT

---

@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.