[Core][Left sidebar]: The left sidebar will move up if there are space lines in the html file.

[julieyuan]

Steps:

1. Launch Brackets and new a html file.
2. Input some contents into the body tag. Make sure there are some space lines in the content.
3. Right click the content to bring up the context menu to select all.
4. Right click the content again.

Results:
The left sidebar will move up a little bit.

Expected:
The sidebar should not move.

ENV: MAC10.8.3 and Win8.1 English OS
Build: 0.32.0-9618

Snapshots:
Please refer to snapshots for details:
After Step3:

Step4:

[ghost]

I can't reproduce this on OSX:

[njx]

I've seen this issue of the left sidebar moving up before (even on Mac). It might be an intermittent thing, or there might be multiple causes.

[julieyuan]

I checked this issue with latest build 0.32.0-9660 on MAC today，at beginning it not reproduces with above steps, then I tried to live preview this html file and close twice. Then repeat step3~4, this issue will reproduce. Since then, it will happen each time with above steps.

[njx]

Low pri to me.

[njx]

Marking F General UI - we've seen this in a few guises.

[redmunds]

FYI, this happens for me even if there are on empty lines.

Also see issue #3376

[lkcampbell]

I'm not sure if this is relevant to this bug since it is an extension bug, but peterflynn/svg-preview#6 reproduces the side bar shifting problem in an extreme way. Might provide some insight into why this problem is occurring.

[jayther]

TL;DR: My findings suggest it is a scroll issue (browser shell content might be scrolled down a little bit), and it might be an issue with the browser shell itself.

The longer story:

I use Brackets everyday for work and for personal projects, and this bug pops up everyday. At work, the gap is small, but at home, the gap is big and hides the "Configure Working Set" and "Split-view" buttons due to an extension that I have at home that I do not have at work.

I've finally gotten around to playing with the Developer Tools with and without extensions to try to figure out what's causing that gap at the bottom, and found out a lot of things. I've been busy with this bug because combined with a certain extension, the sidebar up-shift actually hides the Configure and Split-View buttons in the top.

I am able to reproduce the bug in a few ways in Brackets without extensions in Win 7 64-bit, all of which involves selecting with the mouse. Selecting with keyboard does not reproduce the bug until you right-click the selection.

Here is what I found while trying to reproduce the bug:

• Reproducing the bug is a little more predictable when extensions are disabled.
• In an HTML file, you must select 20 or more lines for the bug to happen. No right-click needed, indentation does not matter. If selected with keyboard, you must select 24 lines and then right-click.
• Other file types such as JavaScript are less predictable with what number of lines trigger the bug. In a JavaScript file, sometimes 3 lines triggers the bug, or 17 lines. The gap isn't always the same size either.
• If you reload Brackets while you still have the lines selected that triggered the bug, the bug appears when Brackets loads.
• If you scroll while you're selecting (whether with scroll wheel or edge-scroll), the bug does NOT happen, regardless of how many lines you select.
• When an extension injects some SVG in the Brackets' HTML body then you take the steps above to reproduce the bug, the gap gets bigger. Weirdly enough, adding a "display: block" on the style of the SVG tag in Development tools makes the gap smaller (to the usual gap size without extensions). When you disable the "display: block" line, you can reproduce the bug again and then re-enable the "display: block" line.

These are what I found while trying to go through the style properties of each element in Brackets in Development Tools:

• While the gap is showing, disabling "overflow: hidden" on the body element eliminates the gap. However, with an extension that inserts SVG, disabling "overflow: hidden" adds a system vertical scrollbar, presumably because of the extra space added by the SVG at the bottom.
• Adding "position: relative" to the body element (or the main-view element) also makes the editor (content element) shift up, matching the bottom of the editor with the sidebar's bottom.
• The content element (the editor) has "position: absolute", while the sidebar element has "position: relative". None of the content element's parents have a position value set.
• When hovering over the body element in Development Tools while the gap is showing, the highlight is in the right dimensions, but when hovering over the main-view element, the highlight is slightly higher than it should be (the bottom of the sidebar matches the highlight).

The three things above suggests that the issue may be a scroll issue, where the content in the browser shell is slightly scrolled down (and the "overflow: hidden" rule in the body element would prevent the scroll, since it would think there's nothing to scroll). Why mouse interaction (at mouse-up) triggers the browser shell to scroll down, I don't know. I don't know how much about how the browser shell works, but it may be an issue with the browser shell, since simply disabling "overflow: hidden" almost fixes the problem. There doesn't seem to be any other CSS style rules that would cause the gap.

So, I don't know what the fix is, really, nor do I know what's causing the bug. Disabling "overflow: hidden" doesn't seem to be the ideal fix. Adding "position: relative" to the body element or the main-view element definitely points out where the problem might be. So, I hope my findings will help figure out what's actually causing this bug (and hopefully the fix).

[redmunds]

@jayther Thanks for researching this and the detailed report! Which release of Brackets are you running?

I think this was fixed in pull request #9376 which was merged shortly after 0.44 was released, so you should see it in the latest master branch. If you're using installer builds, the test-45 build should have this fix in it. Is this fixed for you in those builds?

I think this bug is fixed, but it was not linked from #9248, so I was not aware of it. Looks like #9499 is also fixed.

Note that #3376 is not fixed because UI still "Jiggles", but at least it doesn't stick any longer.

[jayther]

Ah, I didn't search for closed issues, I probably should have searched for that. I was running 0.44 release. The 0.45 test build does fix the gap. I've tried all the ways to reproduce the bug and the gap doesn't appear (and yes, the jiggle is still there). I see the fix in the Development Tools of changing sidebar position rule to absolute.

It's still a little odd how "position: relative" causes the sidebar to shift up a bit. I just looked at the Development Tools again for 0.45 test build and while the sidebar position is fine, the .main-view highlight is still shifted up after taking the steps to reproduce the bug. It's not really an issue, but definitely something to take note of when a bug like this appears again.

Thanks for fixing this bug!

[redmunds]

@jayther I'm not exactly sure of the difference between the rendering modes for relative and absolute positioning that would cause that problem.

... the .main-view highlight is still shifted up after taking the steps to reproduce the bug

Not sure what you mean here. Can you provide a recipe to reproduce it and maybe a screen shot of what you're seeing?

[jayther]

@redmunds When using absolute positioning, an element's coordinates will be relative to a parent element (as in, any parent element of the hierarchy) that has relative positioning. In this case, none of the parent elements of the sidebar has positioning defined (defaulted to static), so the coordinates will be relative to the top html tag. When using relative positioning, the element's coordinates will be relative to its immediate immediate parent.

So, with that in mind, none of the sidebar's parents in the hierarchy has position defined, and the sidebar's immediate parent is the .main-view element, which is the element that gets shifted up when the bug is reproduced. In the previous release build, when using relative positioning, the sidebar's coordinates is relative to the .main-view element, so it shifts up the sidebar because the .main-view element is shifted up. With absolute positioning, it doesn't shift up the sidebar because its coordinate is relative to the top html tag.

Anyway, here are the steps I took to reproduce the bug in the test build 0.45 with extensions disabled:

1. Reload without extensions.
2. Open (or create) an HTML file with more than 20 lines to select.
3. Select 20 or more lines with the mouse.
4. Right-click the selection.

This is a little tricker if you have the latest test build because you would have to check the Developer Tools and the highlight capability to actually see an issue.

Here are some screenshots:

Pre-bug:

Bug:

The size of the .main-vew element is the correct size (same size as the body tag and the html tag), so the gap at the bottom of the highlight suggests it's shifted up.

In the Developer Tools, when I add position: relative in the body tag, it shifts everything up, reshowing the gap:

When I change the overflow property to auto in the body tag, it adds a system scrollbar and does show it's scrolled down:

Funnily enough, when I scroll back up and remove the added overflow property, the scrollbar disappears and the gap is gone.

So, yeah, that's why I think the content is scrolled down after doing certain mouse interactions. I don't know why certain mouse interactions would scroll the content down, that issue may lie within the browser shell.

[redmunds]

@jayther Thanks for the added info.

With absolute positioning, it doesn't shift up the sidebar because its coordinate is relative to the top html tag.

Actually, position: absolute elements with no top/right/bottom/left are positioned at the current flow position so that does shift. It must be because they do not take up any space in the flow that it no longer causes the height of it's container to shift.

When I open Dev Tools I am seeing the gap for the div.main-view highlighting as shown in your second screenshot, but rendering in Brackets is correct. When you said ".main-view highlight is still shifted up" I thought you were referring to a highlight in Brackets. That's a bit concerning, but unless I see a visual glitch in Brackets, then I don't want to make any changes.

The remaining quirks come from you tweaking CSS in Dev Tools, correct?

Thanks again for digging into this -- it's a nasty bug that we'd love to fix once and for all. FYI, I am running the latest master branch of Brackets. You can clone Brackets if you care to try the master branch, otherwise we'll be posting some release candidate builds within the next week so you can try latest code with an installer.

[jayther]

@redmunds You're right about position: absolute, but I don't think I was clear haha. I meant that with position: absolute elements with left/top/right/bottom defined (such as the fix for the sidebar), it will position the elements with whatever parent in the hierarchy that has position: absolute, or the top HTML tag. The top HTML tag seems to be in the right position so the fix for the sidebar works.

But yes, I wouldn't want to make any changes if there are no visual glitches. It's just something to take note of for future changes when the gap reappears for some reason, or if there's a related glitch.

And yes, the remaining quirks came from tweaking the CSS in Development Tools.

[redmunds]

FBNC to @julieyuan

[JeffryBooher]

Closing as fixed. CC: @redmunds

[julieyuan]

Confirm this issue is fixed. Thank you all and please refer to the screenshot: