Google Maps API v3: InfoWindow not sizing correctly

javascript html css google-maps

102,378

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

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 infoWindow regardless 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.

Solution 5

.gm-style-iw{
    height: 100% !important;
    overflow: hidden !important;
}

it works for me

View more solutions

102,378

JacobT

Updated on April 19, 2020

Comments

JacobT about 4 years
It appears my InfoWindow, when you click on the home icon on my Google Maps v3, is not properly auto-sizing to the content of the InfoWindow.

It gives scrollbars when it should not. The InfoWindow should be properly auto-sizing.

Any ideas on why?

Per request, the relevant JavaScript which injects the HTML for the InfoWindow:
```
listing = '<div>Content goes here</div>';
```
UPDATE

This bug was handled by Google in issue

https://issuetracker.google.com/issues/35823659

The fix was implemented in February 2015 in version 3.19 of Maps JavaScript API.
- Pradeep Kumar over 14 years
  
  better to copy the relevant code into your question. Otherwise this question becomes meaningless when the code on your site changes.
- JacobT over 14 years
  
  Well, that's the whole point actually. It's my understanding that the Google Maps v3 API is suppose to auto-size regardless of my CSS ... and it is not. But I'll post the code anyways
- Cassie over 12 years
  
  I know this is old, but in case someone gets here and tries everything and still has a problem (like I did): The infowindows have a max height proportionate to your map dimensions. This is smaller than v2. So if you are upgrading from v2 to v3 and have this issue, it could be because of this. Either make your content shorter, or your map longer, or downgrade back to v2.
Ilya Saunkin over 13 years

Exactly. Same size or you create enough classes in your css with different dimensions.
bret almost 13 years

thanks, it wasn't until i set my font to comic-sans that this started working.
Ian Dunn almost 13 years

I was having this issue and none of the other fixes worked, but this one did. Thanks :)
ZMorek over 12 years

This applies to all margins used inside the window.
ZMorek over 12 years

I still had problems, but just wrapped everything in <div style='overflow:hidden;'></div> Looks good now.
Jeremy F. almost 12 years

Ok this is working just fine, many thanks ... Now I wanna know why :)
clockworked247 almost 12 years

You're on the right track. The min-height of infoWindow won't help you, as that DIV is contained within out DIV that's overflowing. So setting a min-height will make it scroll every time.
clockworked247 almost 12 years

Looking at the structure of the DOM, it's actually the GRANDPARENT of the infoWindow class that needs the overflow removed on. My code looks something like: infoCallBack = function infoCallback(infowindow, marker) { return function () { /* code for displaying window goes here, then my overflow fix next */ setTimeout(function() { $('.infowindow').parent().parent().css('overflow',''); },25); } } Which basically triggers the fix of the infoWindow after 25ms, enough time for it to render.
spuas over 11 years

Exactly, I dont think is any fixed size, but the point is that if the map is not big enough (height in this case) then the infowindow won't resize to wrap our content. Try making the map bigger and check again
Jakob Jingleheimer over 11 years

In case anyone else is trying to set maxWidth to a percentage, google maps will recognise a float as a percentage of the parent, and convert it to the pixel-equivalent: declare {"maxWidth":0.25}, parent element is 1000px wide, InfoWindow will have a width: 250px. I don't think it's possible to force InfoWindow's width to remain a percentage (the value of maxWidth must be a number, so {"maxWidth":"25%"} will not work and {"maxWidth":25%} is treated a 25 modulus undefined and triggers a syntax error).
fortboise over 11 years

Interesting. The current Google documentation says the google.maps.InfoWindowOptions.maxWidth property is "a number", and we have inferred units of pixels. There's no reason why the parser couldn't also accept a decimal number and interpret it as a fraction... and that be left as an undocumented "feature." Except maybe good sense.
Bill Blankenship over 11 years

Ok, +1 for working great, but why do I always end up on that sail page when researching gMap functionality.
Jakob Jingleheimer over 11 years

After a bit of poking around the divitis that is googlemaps, it is not possible for the infowindow's width to remain a percent because of where infowindow actually sits in the DOM. Also, {"maxWidth":0.25} appears to be a bit flaky (some percentages work, others don't), so use with caution.
Mark Parnell almost 11 years

Setting a min-width on the content was the only thing that worked for me too. Didn't have to set the maxWidth on the infoWindow though.
Jen almost 11 years

@MarkParnell = make sure to test thoroughly. I was running into issues when i had more than a certain amount of text at a given width! If you know what the content is going to be, then no biggie :)
tbradley22 over 10 years

yes! line height is what fixed it for me too. nothing else worked. specifically, i had line height set in my stylesheet to { line-height: 1.3; }. i changed it to { line-height: 1.3em } and it resolved the issue.
tbradley22 over 10 years

or alternately you can just set the line height of the map container div to normal as indicated above.
StackExchange What The Heck over 10 years

depending on how you are working with your infowindows, it might well be safer to use a class rather than an ID, to avoid duplicate IDs floating around on the same page, eg <div class=\"mydiv\">YourContent</div> and .mydiv{ width:500px; height:100px; }
Xavier Holt over 10 years

This one! Worked my way down through all the answers without success until I got here. In my case, it was the white-space: nowrap that had the magic - the other styles were unnecessary. Cheers!
monoceres over 10 years

This is among the weirdest fixes I have ever seen. None of the other hacks for this question worked for me except this. Unbelievable.
Imaginary about 10 years

this solution works for me. Also hiding scroll works: .gm-style-iw{ overflow: hidden !important;} but this will hide part of content in infoWindow
Auguste Van Nieuwenhuyzen about 10 years

I have a vertically narrow map, and maxWidth makes no difference for me :( I've had to set the height in the CSS. Would be nice if I could specify a maximum, but Google won't let me!
Sparky about 10 years

+1 yes! But I combined this answer with user2656824's.
Sparky about 10 years

This does indeed seem to work, however, some of the infowindows had to be clicked more than once though... my final solution was to combine this answer with Concept211's by adding font-family: sans-serif !important; font-weight: normal !important; to the CSS.
user151496 about 10 years

+1 because it is the only answer that seems to finally acknowledge the fact that this is due to the Roboto font issues. i wouldn't be surprised if other fonts rendered wrongly as well. the problem is that .gm-style-iw calculates a tiny bit lesser height than necessary, probably because of the float rounding. the really only reasonable option is unfortunate .gm-style-iw{overflow: hidden !important;}. of course, this becomes useless once you really do have to scroll though
pim almost 10 years

THIS is the most correct answer here. Too small a map is typically the cause of the infowindow sizing issues. If you want to test the theory out just inspect the map container and increase the width and height.
Simon East over 9 years

This will hide any information that is too big for the info window.
Simon East over 9 years

That will remove the wrapping on long lines. I don't think that's a suitable solution for many people.
Simon East over 9 years

This may have worked in 2010, but does not help as of 2014.
Simon East over 9 years

This is not a great solution as any content that is larger than the info window will be cut off and hidden.
Simon East over 9 years

For some reason, the maps API appears not to put overflow: auto on the InfoWindow DIV when you pass in DOM nodes instead of a string. This solves the problem if the content is only out by 1-2px. Unfortunately this means that longer content actually hangs out of the InfoWindow instead of having scrollbars added.
Simon East over 9 years

Unfortunately if you have any long lines, the lines will get cut off instead of wrapping. Not an ideal solution unless you know all your lines are short.
Simon East over 9 years

There is no #map_canvas in Google Maps v3 that I can see. This must be from the old v2.
Simon East over 9 years

Unfortunately there are still issues even with a suitably large map.
Simon East over 9 years

This sets a fixed width to the InfoWindow (no longer fluid), which is one solution, but not ideal.
fortboise over 9 years

It doesn't surprise me that a not-quite-sensible workaround wasn't persistent. Looking at my sailing spots map again, I noticed ONE of the info windows got a scroll bar, and that it wasn't one with most content. I see that LONGER or SHORTER text in one of the components that are rolled into the infowindow will make the scrollbar go away. Quirky, huh? Try ADDING characters to the contents maybe?!
Nick over 9 years

@Simon #map_canvas is the div you use for the map. It can be whatever name you want it to be.
Phil Cooper over 9 years

@Simon new year, new problems... any solutions on the fix this time round?
Simon East over 9 years

Unfortunately it doesn't help. This fiddle still displays a scrollbar in Chrome: jsfiddle.net/simoneast/dckxp62o
Simon East over 9 years

The Roboto font does appear to trigger this issue sometimes, but it happens also with Arial and default fonts. If you look at this fiddle with your suggested fix in Chrome 38 on Windows it still has a nasty scrollbar: jsfiddle.net/simoneast/dckxp62o/2
Simon East over 9 years

It helps sometimes, but doesn't reliably fix the problem. If you view this fiddle in Chrome 38 on Windows it still has an ugly scrollbar: jsfiddle.net/simoneast/dckxp62o/3
Simon East over 9 years

This cuts content off in some cases. :-( In this fiddle on Chrome 38 on Windows the "dddd" is cut off completely: jsfiddle.net/simoneast/dckxp62o/4
Nate Bunney over 9 years

I think my problem was caused by an h4 tag wrapping. When I added your suggestion it removed the scroll bars but there was a tiny bit off the bottom of the window. When I added white-space: nowrap; to the h4 it all got better. Thanks!
Adam over 9 years

While this does work, it's pretty nasty to ask people to include jQuery on the page simply so infoWindow's display correct. The complete answer as to why this works is listed in my answer - jQuery creates a detached DOM tree which forces the content to be correctly rendered and it's size accurately determined before google attempts to place the infoWindow on the map
Simon East over 9 years

Unfortunately this isn't a reliable fix. The issue has been known to occur with Arial and other standard fonts too.
Simon East over 9 years

Unfortunately the issue still sometimes occurs with default line-heights.
Simon East over 9 years

Unfortunately your answer doesn't really offer anything additional to other answers here, and is not a very reliable fix. It will cause content to get cut off instead of wrapping and scrolling.
Simon East over 9 years

Some great detail there Adam, and yes I discovered similar things to you. However, the bug as reported to Google does actually appear to still occur even with system fonts and no descendent CSS selectors. See this example (has a scrollbar in Chrome 40 Win).
Adam over 9 years

@Simon - you are correct, the link you submitted is a bug (extremely edge case, but a bug nonetheless). I would imagine that >98% of the time, when people report their infoWindows have and they don't know why - it's because of the issues addressed in this answer.
Paul over 9 years

This is the closest answer that worked for me. Instead of auto height, I added a minimum height instead.
Jimbo Jones over 9 years

Not perfect for varying length content, but my content is pretty much the same for each pointer applying a width !important and height !important was enough of a solution for me!
Abram about 9 years

Adam. Thanks so much for providing this answer. You saved me a bunch of unnecessary hacking!
Diederik about 9 years

I have had more success with the poup window size in version 3.19 (released 15 Feb 2015) of Google maps . Perhaps try that?
DShah almost 7 years

Thank you so much.. this helped me too. In mobile view i gave maxWidth: 350. still it was taking some random value. with the help of min-width it works fine.
user2060451 almost 5 years

It works on desktop, but not on mobile devices (Android)/