Google Maps API v3: InfoWindow not sizing correctly
Solution 1:
Add a div inside your infowindow
<div id=\"mydiv\">YourContent</div>
Then set the size using css. works for me. This asumes all infowindows are the same size!
#mydiv{
width:500px;
height:100px;
}
Solution 2:
Short answer: set the maxWidth options property in the constructor. Yes, even if setting the maximum width was not what you wanted to do.
Longer story: Migrating a v2 map to v3, I saw exactly the problem described. Windows varied in width and height, and some had vertical scrollbars and some didn't. Some had <br /> embedded in the data, but at least one with that sized OK.
I didn't think the InfoWindowsOptions.maxWidth property was relevant, since I didn't care to constrain the width... but by setting it with the InfoWindow constructor, I got what I wanted, and the windows now autosize (vertically) and show the full content without a vertical scrollbar. Doesn't make a lot of sense to me, but it works!
See: http://fortboise.org/maps/sailing-spots.html
Solution 3:
You should give the content to InfoWindow from jQuery object.
var $infoWindowContent = $("<div class='infowin-content'>Content goes here</div>");
var infoWindow = new google.maps.InfoWindow();
infowindow.setContent($infoWindowContent[0]);
Solution 4:
.gm-style-iw{
height: 100% !important;
overflow: hidden !important;
}
it works for me
Solution 5:
EDITED (to standout): Trust me, out of the hundred other answers to this question, this is the only correct one that also explains WHY it's happening
Ok, so I know this thread is old, and has a thousand answers, but none of them is correct and I feel the need to post the correct answer.
Firstly, you do not ever need to specify width's or height's on anything in order to get your infoWindow to display without scrollbars, although sometimes you may accidentally get it working by doing this (but it's will eventually fail).
Second, Google Maps API infoWindow's do not have a scrolling bug, it's just very difficult to find the correct information on how they work. Well, here it is:
When you tell the Google Maps API to open in infoWindow like this:
var infoWindow = new google.maps.InfoWindow({...});
....
infoWindow.setContent('<h1>Hello!</h1><p>And welcome to my infoWindow!</p>');
infoWindow.open(map);
For all intents and purposes, google maps temporarily places a div at the end of your page (actually it creates a detached DOM tree - but it's conceptually easier to understand if I say you imagine a div being places at the end of your page) with the HTML content that you specified. It then measures that div (which means that, in this example, whatever CSS rules in my document apply to h1 and p tags will be applied to it) to get it's width and height. Google then takes that div, assigns the measurements to it that it got when it was appended to your page, and places it on the map at the location you specified.
Here's where the problem happens for a lot of people - they may have HTML that looks like this:
<body>
<div id="map-canvas"><!-- google map goes here --></div>
</body>
and, for whatever reason, CSS that looks like this:
h1 { font-size: 18px; }
#map-canvas h1 { font-size: 32px; }
Can you see the problem? When the API tries to take the measurements for your infoWindow (immediately before displaying it), the h1 part of the content will have a size of 18px (because the temporary "measuring div" is appended to the body), but when the API actually places the infoWindow on the map, the #map-canvas h1 selector will take precedence causing the font size to be much different than what it was when the API measured the size of the infoWindow and in this circumstance you will always get scrollbars.
There may be more slightly different nuances for the specific reason why you have scrollbars in your infoWindow, but the reason behind it is because of this:
The same CSS rules must apply to the content inside your
infoWindowregardless of where the actual HTML element appears in the markup. If they do not, then you will be guaranteed to get scrollbars in your infoWindow
So what I always do, is something like this:
infoWindow.setContent('<div class="info-window-content">...your content here...</div>');
and in my CSS:
.info-window-content { ... }
.info-window-content h1 { .... }
.info-window-content p { ... }
etc...
So no matter where the API appends it's measurement div - before the closing body or inside a #map-canvas, the CSS rules applied to it will always be the same.
EDIT RE: Font Families
Google seems to be actively working on the font loading issue (described below) and functionality has changed very recently so you may or may not see the Roboto font load when your infoWindow opens the first time, depending on the version of the API you are using. There is an open bug report (even though in the changelog this bug report was already marked as fixed) that illustrates that google is still having difficulty with this problem.
ONE MORE THING: WATCH YOUR FONT FAMILIES!!!
In the latest incarnation of the API, google tried to be clever and wrap it's infoWindow content in something that could be targeted with a CSS selector - .gm-style-iw. For people that didn't understand the rules that I explained above, this didn't really help, and in some cases made it even worse. Scrollbars would almost always appear the first time an infoWindow was opened, but if you opened any infoWindow again, even with the exact same content the scrollbars would be gone. Seriously, if you weren't confused before this would make you lose your mind. Here's what was happening:
If you look at the styles that google loads on the page when it's API loads, you'll be able to see this:
.gm-style {
font-family: Roboto,Arial,sans-serif
...
}
Ok, so Google wanted to make it's maps a bit more consistent by always making them use the Roboto font-family. The problem is, for the majority of people, the before you opened an infoWindow, the browser hadn't yet downloaded the Roboto font (because nothing else on your page used it so the browser is smart enough to know that it doesn't need to download this font). Downloading this font isn't instantaneous, even though it is very fast. The first time you open an infoWindow and the API appends the div with your infoWindow content to the body to take it's measurements, it starts downloading the Roboto font, but your infoWindow's measurements are taken and the window is placed on the map before Roboto finishes downloading. The result, quite often, was an infoWindow whose measurements were taken when it's content was rendered using Arial or a sans-serif font, but when it was displayed on the map (and Roboto had finished downloading) it's content was being displayed in a font that was a different size - and voila - scrollbars appear the first time you open the infoWindow. Open the exact same infoWindow a second time - at which point the Roboto has been downloaded and will be used when the API is taking it's measurements of infoWindow content and you won't see any scrollbars.