[Core][Inline editors]: The close button on code inline editors is misaligned when increase or decrease font size.

[julieyuan]

Steps:

1. Launch Brackets and open default sample folder.
2. Open index.html file and put the cursor on a tag, like: <h1>
3. Press Ctrl+E to invoke inline editor.
4. Press Ctrl++ to increase font size.
5. Press Ctrl+- to decrease font size.

Result:
At step4, the close button is upper than the file name.
At step5, the close button is not changed with the font size.

Expected:
It should not be misaligned on the inline editor.

Notes:
This issue not reproduces for color inline editor.

ENV: MAC10.7.5 and Win8 English OS
Build: 0.33.0-9858

Snapshots:
Please refer to snapshots for details:
Increase font size:

Decrease font size:

[gruehle]

Low priority to @larz0. Hopefully this is a simple fix, bump it back if it's not.

[larz0]

@gruehle I can't reproduce this on Mavericks, any ideas?

[njx]

I suspect it's the same behavior--it's just that @julieyuan bumped the font size up a lot larger.

Would it make sense for the "x" and the dirty dot to increase in size with the text? That's kind of what we were thinking.

[gruehle]

@larz0 You need to go to extremely large (or small) text sizes to see the mis-alignment. This is caused by the bootstrap .close class, which sets font-size: 20px. Changing this to an em value makes the close button size change relative to the font size.

[larz0]

It needs to be in the context of the entire app. I think it's fine. Check out these screenshots:

[njx]

It sounds like your argument is that other parts of the UI don't change size when we do "Increase Font Size", which I think is as currently designed--Increase Font Size only affects the size of code and nothing else. (Some have argued that Increase Font Size should increase text sizes everywhere in the UI, but that's a separate issue.)

However, if that's the case, then it seems like we shouldn't change the size of the filename either, given that we don't change the size of other text elements in the UI outside of code (even in the rule list on the right). So maybe the real bug (given the current design) is that the filename changes size when you do Increase Font Size, and we should fix that. What do you think?

[peterflynn]

I think someone (maybe even you NJ :-) argued that we should make an exception and explicitly scale the filename header too since it's sandwiched between two code editors that both scale. But we already don't scale the rule list, so I think that argument is inconsistently applied, at best. So I too am in favor of changing it back so only actual code scales :-)

[larz0]

Sounds good. I'll give it a shot now.

[larz0]

Here's the PR #5680

[redmunds]

Closing. @julieyuan Let us know if this is not fixed for you.

[julieyuan]

Thanks. Fixed with build 0.34.0-10242. Here are snapshots for reference:

[peterflynn]

@larz0 Does that "dirty" bullet look off-center toward the bottom to you? I feel like it used to be a little higher up relative to the text...

[larz0]

@peterflynn pull request is up at #5859. Nice catch. It may look slightly raised because filenames are in lowercase.