Maybe it is correct, but it looks weird. In official docs is it possible to see between left Go! button and input.

I assume you meant "Weird" rather than "Wired"?
What OS and browser are you using?
Can you post a screenshot?

Of course, soory. Win 8.1 latest Chrome (36).

The vertical line has 2px width, just one pixel is I thing better.

Unable to reproduce with Chrome v36.0.1985.125 on Win 8.1 on Sauce:

And yes, the divider line is exactly 1px (I measured it in GIMP):

(Added 1px red and black lines in GIMP to help visually clarify this.)

I should be the Sauce mistake. The reality is, that there is not hidden one of the borders. This situation makes visible both of them. So it looks like 2 pixes border.

Chrome 36 Mac. No double line. Check to see if your zoom level is 100%.

Chrome v37.0.2062.44 beta on OS X 10.9.4, zoom level 100% using latest master: double border.

No double border on the segmented buttons though:

The reality is, that there is not hidden one of the borders. This situation makes visible both of them.

Both of the elements have 1px borders, true, but the negative padding is supposed to make the borders overlap...

The double border continues to exist in 38.0.2103.0 canary (64-bit), as well. Same version of OSX, as @hnrch02.

Setting .input-group-btn:first-child>.btn, .input-group-btn:first-child>.btn-group's margin-right to -2px seems to resolve it without immediately apparent side-effects, but boy is it weird. The margin-left on the other group is also set to -1px and appears fine.

The problem doesn't occur in Safari 7.0.5 or Firefox 31 though, so changing margin-right wouldn't work.

Chrome browser bug perhaps?
CC: @mdo

Looks like it. Can't reproduce in Opera 23.0.1522.60. What's strange though is that not everybody is able to reproduce this.

@hnrch02 It does work but it's obviously a hack. You'll gain a pixel on the input, while appearing to lose one on the button. Try it out. Still only displays the single pixel border.

Here it is in the extreme on FF 31 with a -10px margin.

@zacechola Sorry, I wasn't implying that using -2px wouldn't fix the problem. I was trying to say that it's not really an acceptable solution.

Understandable, @hnrch02. I wasn't suggesting it as a great fix either, merely as a curiosity that it works fine in the last-child with margin-left, but not first-child with margin-right.

Definitely a browser thing when one variation of a component behaves well, but the other doesn't. Not sure we can do much about it in v3.x.

@mdo Care to file a Chrome bug then, maestro?

Given it's changed back and forth, I'm inclined to see if this works itself out. Also, I want to revisit the structure of these in v4. The extra wrapper around buttons and addons is rather necessary given the behavior of inputs and buttons across browsers.

Since this hasn't worked itself out in the intervening year, I filed a Chrome bug:

https://code.google.com/p/chromium/issues/detail?id=534750

Seems to be fixed in Chrome Canary 47.0.2517.0 !

Seems to be broken again as of Chrome Canary 48.0.2530.0 😞

This is still an issue with Chrome 48.0.2564.109 m (Windows 7).

I found a work around that seems to fix it in chrome and not negatively affect other browsers.

CSS:

.input-group-btn .btn {
display: block;
}

@crazyjat Yep, that's why https://code.google.com/p/chromium/issues/detail?id=534750 is still open.

Yes I am aware, but I wanted to convey my work around to anyone suffering with this issue.

I doubt that the Chrome issue will be fixed any time soon as this is a direct result of the fact that Chrome does not "render" table cells with fractional pixel sizes. In the case above, the width of the button is a decimal value (IE: 102.4343px) because it is an inline-block element and the width is calculated based on the width of the text and the cell width is a whole pixel size (IE: 103px;).

It might be possible to also work around this issue by turning off subpixel font rendering, but I'm not sure.