[ACCEPTED]-Google Maps API v3: InfoWindow not sizing correctly-google-maps
Add a div inside your infowindow
<div id=\"mydiv\">YourContent</div>
Then set 2 the size using css. works for me. This asumes 1 all infowindows are the same size!
#mydiv{
width:500px;
height:100px;
}
Short answer: set the maxWidth options property in the constructor. Yes, even if setting the 14 maximum width was not what you wanted to 13 do.
Longer story: Migrating a v2 map to v3, I 12 saw exactly the problem described. Windows 11 varied in width and height, and some had 10 vertical scrollbars and some didn't. Some 9 had <br /> embedded in the data, but 8 at least one with that sized OK.
I didn't 7 think the InfoWindowsOptions.maxWidth property 6 was relevant, since I didn't care to constrain the 5 width... but by setting it with the InfoWindow 4 constructor, I got what I wanted, and the 3 windows now autosize (vertically) and show 2 the full content without a vertical scrollbar. Doesn't 1 make a lot of sense to me, but it works!
You should give the content to InfoWindow 1 from jQuery object.
var $infoWindowContent = $("<div class='infowin-content'>Content goes here</div>");
var infoWindow = new google.maps.InfoWindow();
infowindow.setContent($infoWindowContent[0]);
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 99 a thousand answers, but none of them is correct and I feel the 98 need to post the correct answer.
Firstly, you 97 do not ever need to specify width's or height's on anything in 96 order to get your infoWindow to display 95 without scrollbars, although sometimes you 94 may accidentally get it working by doing 93 this (but it's will eventually fail).
Second, Google 92 Maps API infoWindow's do not have a scrolling bug, it's just 91 very difficult to find the correct information 90 on how they work. Well, here it is:
When 89 you tell the Google Maps API to open in 88 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 87 purposes, google maps temporarily places 86 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 85 content that you specified. It then measures 84 that div (which means that, in this example, whatever 83 CSS rules in my document apply to h1 and p tags 82 will be applied to it) to get it's width and 81 height. Google then takes that div, assigns the measurements 80 to it that it got when it was appended to 79 your page, and places it on the map at the 78 location you specified.
Here's where the 77 problem happens for a lot of people - they 76 may have HTML that looks like this:
<body>
<div id="map-canvas"><!-- google map goes here --></div>
</body>
and, for 75 whatever reason, CSS that looks like this:
h1 { font-size: 18px; }
#map-canvas h1 { font-size: 32px; }
Can 74 you see the problem? When the API tries 73 to take the measurements for your infoWindow (immediately 72 before displaying it), the h1 part of the 71 content will have a size of 18px (because the 70 temporary "measuring div" is appended 69 to the body), but when the API actually 68 places the infoWindow on the map, the #map-canvas h1 selector will 67 take precedence causing the font size to 66 be much different than what it was when 65 the API measured the size of the infoWindow and in 64 this circumstance you will always get scrollbars.
There 63 may be more slightly different nuances for 62 the specific reason why you have scrollbars 61 in your infoWindow, but the reason behind it is because 60 of this:
The same CSS rules must apply to 59 the content inside your
infoWindowregardless of 58 where the actual HTML element appears in 57 the markup. If they do not, then you will 56 be guaranteed to get scrollbars in your infoWindow
So 55 what I always do, is something like this:
infoWindow.setContent('<div class="info-window-content">...your content here...</div>');
and 54 in my CSS:
.info-window-content { ... }
.info-window-content h1 { .... }
.info-window-content p { ... }
etc...
So no matter where the API appends 53 it's measurement div - before the closing body or 52 inside a #map-canvas, the CSS rules applied to it will 51 always be the same.
EDIT RE: Font Families
Google seems to be actively 50 working on the font loading issue (described 49 below) and functionality has changed very 48 recently so you may or may not see the Roboto 47 font load when your infoWindow opens the first time, depending 46 on the version of the API you are using. There 45 is an open bug report (even though in the 44 changelog this bug report was already marked as fixed) that 43 illustrates that google is still having 42 difficulty with this problem.
ONE MORE THING: WATCH YOUR FONT FAMILIES!!!
In the latest 41 incarnation of the API, google tried to 40 be clever and wrap it's infoWindow content 39 in something that could be targeted with 38 a CSS selector - .gm-style-iw. For people that didn't 37 understand the rules that I explained above, this 36 didn't really help, and in some cases made 35 it even worse. Scrollbars would almost always 34 appear the first time an infoWindow was opened, but 33 if you opened any infoWindow again, even with the 32 exact same content the scrollbars would be gone. Seriously, if 31 you weren't confused before this would make 30 you lose your mind. Here's what was happening:
If 29 you look at the styles that google loads 28 on the page when it's API loads, you'll 27 be able to see this:
.gm-style {
font-family: Roboto,Arial,sans-serif
...
}
Ok, so Google wanted 26 to make it's maps a bit more consistent 25 by always making them use the Roboto font-family. The 24 problem is, for the majority of people, the 23 before you opened an infoWindow, the browser hadn't 22 yet downloaded the Roboto font (because nothing 21 else on your page used it so the browser 20 is smart enough to know that it doesn't 19 need to download this font). Downloading 18 this font isn't instantaneous, even though 17 it is very fast. The first time you open 16 an infoWindow and the API appends the div with your infoWindow content 15 to the body to take it's measurements, it 14 starts downloading the Roboto font, but your infoWindow's measurements 13 are taken and the window is placed on the 12 map before Roboto finishes downloading. The result, quite 11 often, was an infoWindow whose measurements were taken 10 when it's content was rendered using Arial or 9 a sans-serif font, but when it was displayed on the 8 map (and Roboto had finished downloading) it's 7 content was being displayed in a font that 6 was a different size - and voila - scrollbars 5 appear the first time you open the infoWindow. Open 4 the exact same infoWindow a second time - at which 3 point the Roboto has been downloaded and will 2 be used when the API is taking it's measurements 1 of infoWindow content and you won't see any scrollbars.
.gm-style-iw{
height: 100% !important;
overflow: hidden !important;
}
it works for me
0
I tried each one of the answers listed. None 9 worked for me.
This finally fixed it PERMANENTLY.
The 8 code I inherited had a DIV wrapper around all 7 the <h#> and <p> entries. I simply forced some 6 "style" in the same DIV, taking into account 5 a desired max width, threw in the line height 4 change just in case (someone else's fix) and 3 my own white-space: nowrap, which then made the auto overflow 2 make the correct adjustments. No scroll 1 bar, no truncation and no problems!
html = '<div class="map-overlay" style="max-width: 400px;
line-height: normal;
white-space: nowrap;
overflow: auto;
">';
I know this is an old thread, but I just 7 encountered the same problem. I had <h2> and 6 <p> elements in the InfoWindow, and these both 5 had bottom margins. I removed the margins, and 4 InfoWindow sized correctly. None of the 3 other suggested fixes worked. I suspect 2 that the InfoWindow size calculation doesn't 1 take the margins into account.
Going to add my answer to the list, since 8 NONE of these fixed my problem. I ended 7 up wrapping my content in a div, giving 6 that div a class, and specifying the min-width on 5 the div, AND specifying the maxWidth on the infoWindow, AND 4 they both needed to be the same size, otherwise 3 either the width or the height would be 2 overflowing on boxes with just the wrong 1 amount of content.
Javascript:
// Set up the content for the info box
var content = "<div class='infowindow-content'>" + content + "</div>";
// create a map info box
var infoWindow = new google.maps.InfoWindow({
maxWidth: 350,
content: content
});
CSS:
div.infowindow-content {
min-width: 350px;
}
I have tried all of these solutions and 3 none worked. After some trial and error 2 I figured it out.
<style type="text/css">
#map_canvas {
line-height:normal;
}
</style>
Set line-height:normal 1 for the map canvas div.
It appears that the issue is with the Roboto 11 webfont.
The infowindow is rendered with 10 inline width and height properties based 9 on the content provided. However, it is 8 not calculated with the webfont already 7 rendered/loaded. Once the font is rendered 6 AFTER the entire map is printed to the screen, then 5 it causes the scrollbars to appear due to 4 the "overflow:auto" properties inline inside 3 the window's DIVs.
The solution I found to 2 work is to wrap the content in a DIV and 1 then apply CSS to override the webfont:
.gmap_infowin {
font-family: sans-serif !important;
font-weight: normal !important;
}
<div class="gmap_infowin">Your info window content here.</div>
Funny enough, while the following code will correct the WIDTH scroll bar:
.gm-style-iw
{
overflow: hidden !important;
line-height: 1.35;
}
It took this to correct the HEIGHT scroll bar:
.gm-style-iw div
{
overflow: hidden !important;
}
EDIT: Adding white-space: nowrap; to either style 3 might correct the spacing issue that seems 2 to linger when the scroll bars are removed. Great 1 point Nathan.
This works for me.
Put a div in the setContent
sh_map.infoWindow.setContent([
'<div id=\"mydiv\">',
'Your content goes here',
].join(''));
Then add 3 this CSS to your page:
<style type="text/css">
#map-canvas {
text-align: center;
vertical-align: middle;
}
#mydiv {
font-family: "Comic Sans MS", cursive;
font-size: 10px;
border-top-width: 0px;
border-right-width: 0px;
border-bottom-width: 0px;
border-left-width: 0px;
border-top-style: none;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
letter-spacing: normal;
text-align: center;
vertical-align: middle;
word-spacing: normal;
}
</style>
For example, see http://www.student-homes-northampton.co.uk; click 2 the links under the house pics to display 1 the Google map.
This solved my problem completely:
.gm-style-iw {
overflow: visible !important;
height: auto !important;
width: auto !important;
}
0
I was having the same problem with IE and 9 tried many of the fixes detailed in these 8 responses, but was unable to remove the 7 vertical scrollbars in IE reliably.
What 6 worked best for me was to switch to fixed 5 font sizes inside the infowindow -- 'px'... I 4 was using ems. By fixing the font size 3 I no longer needed to explicitly declare 2 the infowindow width or height and the scrollbars 1 were gone for good.
Also important is height of the map container. If 3 to small infoWindow always will be on 80px 2 height. Otherwise maxWidth and #innerDiv fix works like a 1 charm.
If nothing else, try adding the content 2 after the window has been opened. This 1 should force it to resize.
infoWindow = new google.maps.InfoWindow()
infoWindow.open(map, marker)
infoWindow.setContent(content)
Use the domready event and reopen the info 7 window and show the hidden content after 6 the domready event fires twice to ensure 5 all of the dom elements have been loaded.
// map is created using google.maps.Map()
// marker is created using google.maps.Marker()
// set the css for the content div .infowin-content { visibility: hidden; }
infowindow = new google.maps.InfoWindow();
infowindow.setContent("<div class='infowin-content'>Content goes here</div>");
infowindow.setPosition(marker.getPosition());
infowindow.set("isdomready", false);
infowindow.open(map);
// On Dom Ready
google.maps.event.addListener(infowindow, 'domready', function () {
if (infowindow.get("isdomready")) {
// show the infowindow by setting css
jQuery('.infowin-content').css('visibility', 'visible');
}
else {
// trigger a domready event again.
google.maps.event.trigger(infowindow, 'content_changed');
infowindow.set("isdomready", true);
}
}
I 4 tried just doing a setTimeout(/* show infowin 3 callback */, 100), but sometimes that didn't 2 work still if the content (ie: images) took 1 too long to load.
Hope this works for you.
I was having the same issue, particularly 6 noticeable when my <h2> element wrapped to a 5 second line.
I applied a class to a <div> in the 4 infoWindow, and changed the fonts to a generic 3 system font (in my case, Helvetica) versus 2 an @font-face web font which it had been 1 using. Issue solved.
//infowindow.setContent(response);
var infowindowopts = {
maxWidth: 274,
content: response
};
infowindow.setOptions(infowindowopts);
0
My answer is to add a listener (using addListenerOnce) to 3 check if the infoWindow has been added to 2 the DOM, then opening the infoWindow again 1 (no need to close it).
// map, marker and infoWindow code, we'll call them
// myMap, myMarker and myInfoWindow
myInfoWindow.open(myMap, myMarker);
google.maps.event.addListenerOnce(myInfoWindow, 'domready', function(){
myInfoWindow.open(myMap, myMarker);
});
Add a min-height to your infoWindow class element.
That 4 will resolve the issue if your infoWindows 3 are all the same size.
If not, add this line 2 of jQuery to your click function for the 1 infoWindow:
//remove overflow scrollbars
$('#myDiv').parent().css('overflow','');
I couldnt get it to work in any way shape 13 or form, I was including 3 divs into the 12 box. I wrapped them in an outer div, with 11 widths and heights all set correctly, and 10 nothing worked.
In the end I fixed it by 9 setting the div as absolute top left, and 8 then before the div, I set two images, one 7 300px wide and 1px high, one 120px high 6 and 1px wide, of a transparent gif.
It scaled 5 properly then!
Its ugly but it works.
You 4 could also do one image and set a zindex 3 I expect, or even just one image if your 2 window has no interaction, but this was 1 containing a form, so, that wasn't an option...
I think that this behavior is because of 5 some css styling in an outer container, I 4 had the same problem but I solved it using 3 an inner div an adding some padding to it, I 2 know it's weird but it solved the problem
<div id="fix_height">
<h2>Title</h2>
<p>Something</p>
</div>
And 1 in my style.css
div#fix_height{
padding: 5px;
}
I had an inline element (an a tag) directly 4 inside of the div with style="overflow:auto"[... wrapped that in a p tag 3 and fixed it.
Looks like any inline element 2 that is not nested in a block element directly 1 inside of the infowindow will cause this.
Adding the following to my CSS did the trick 1 for me:
white-space: nowrap;
Just to summarize all the solutions that 6 worked for me in all browsers:
- Don't use margins inside the infowindow, only padding.
Set a max-width 5 for the infowindow:
this.infowindow = new google.maps.InfoWindow({ maxWidth: 200 });Wrap the contents of 4 the infowindow with
<div style="overflow:hidden;line-height:1.35;min-width:200px;">*CONTENT*</div>(change the min-width 3 for the value you set on the infowindow 2 maxWidth)
I have tested it and it worked 1 on every browser, and I had over 400 markers...
I know that lots of other people have found 31 solutions that worked for their particular 30 case, but since none of them worked for 29 my particular case, I thought this might be 28 helpful to someone else.
Some details:
I'm 27 using google maps API v3 on a project where 26 inline CSS is something we really, really 25 want to avoid. My infowindows were working 24 for everything except for IE11, where the 23 width was not calculated correctly. This 22 resulted in div overflows, which triggered 21 scrollbars.
I had to do three things:
Remove 20 all display: inline-block style rules from 19 anything inside of the infowindow content 18 (I replaced with display: block) - I got 17 the idea to try this from a thread (which 16 I can't find anymore) where someone was 15 having the same problem with IE6.
Pass the 14 content as a DOM node instead of as a string. I 13 am using jQuery, so I could do this by replacing:
infowindow.setContent(infoWindowDiv.html());with 12infowindow.setContent($(infoWindowDiv.html())[0]);This turned out to be easiest for me, but 11 there are lots of other ways to get the 10 same result.Use the "setMaxWidth" hack - set 9 the MaxWidth option in the constructor - setting the option 8 later doesn't work. If you don't really 7 want a max width, just set it to a very 6 large number.
I don't know why these worked, and 5 I'm not sure if a subset of them would work. I 4 know that none of them work for all of my 3 use cases individually, and that 2 + 3 doesn't 2 work. I didn't have time to test 1 + 2 or 1 1 + 3.
It wasn't acceptable for me to hard code 14 the width and height of the info window, or 13 to set white-space: nowrap, the maxWidth solution didn't help me and 12 everything else either didn't work or was 11 otherwise inappropriate for my use case.
My 10 solution was to set the content, open the 9 window and then when the domready event is fired, set 8 the height CSS property on the content to whatever 7 the height is, and then force Google Maps 6 to resize the InfoWindow accordingly.
infoWindow is 5 the InfoWindow object, $infoWindowContents is a Jquery object 4 of the contents I want to put in there, map is 3 my Map object. marker is a marker which was clicked.
infoWindow.setContent($infoWindowContents.get(0));
var listener = google.maps.event.addListener(infoWindow, 'domready', function() {
// Stop listening, otherwise the listeners stack up if the window is opened again
google.maps.event.removeListener(listener);
// Set the height on the container to however tall the browser is currently rendering it
$infoWindowContents.height($infoWindowContents.height());
// Force Google Maps to recalculate the InfoWindow height
infoWindow.setContent($infoWindowContents.get(0));
});
infoWindow.open(map, marker);
(I 2 posted the same solution over on a similar 1 question How do I get a google-maps InfoWindow to resize to fit the content that is placed inside of it?)
After losing time and reading for a while, I 5 just wanted something simple, this css worked 4 for my requirements.
.gm-style-iw > div { overflow: hidden !important; }
Also is not an instant 3 solution but starring/commenting on the 2 issue might make them fix it, as they believe 1 it is fixed: http://code.google.com/p/gmaps-api-issues/issues/detail?id=5713
Well this is the one that did the trick 8 for me:
.gm-style-iw>div {
overflow: visible !important;
}
Only setting overflow: visible on .gm-style-iw actually made the 7 problem worse! I noticed in the Chrome developer 6 tools inspector that there are two divs 5 inside the .gm-style-iw element, both which have overflow: auto set 4 by default.
I'm displaying quite a lot of 3 HTML-formatted text in my InfoWindows, that 2 might be why the other solutions didn't 1 work at all for me.
As of mid-2014 there appears to be an InfoWindow sizing bug in Google Maps v3 that affects 17 multiple browsers.
It has been reported here:
https://code.google.com/p/gmaps-api-issues/issues/detail?id=5713
(and a demo JSFiddle here)
Please click the star on the issue above to vote for it to be fixed!
From 16 all my testing, it appears to be related to element size rounding errors, as it 15 only occurs at some font-sizes.
Bad workarounds:
Having toyed 14 with most suggestions on this page, the 13 following are NOT good solutions:
overflow: hidden(can potentially cut off content)white-space: nowrap(can potentially cut off content)- Passing a jQuery object or DOM nodes (content potentially overflows outside the InfoWindow)
- Setting the InfoWindow content after it is opened (on its own, does not help)
- Changing font away from Roboto (the issue can occur with any font)
One possible workaround is 12 giving your InfoWindow a fixed width (such 11 as those who've suggested setting max-width 10 and min-width), however when you have lots 9 of markers and the amount of content varies 8 fluctuates, this is not ideal. It's also 7 bad for mobile/responsive designs.
A reasonable workaround:
So until 6 Google fix this, I've had to build a workaround. After 5 about 12+ hours of testing and debugging 4 I came up with the following:
This does not have 3 the same drawbacks as other suggestions.
- Content should never be clipped (unless you have large images that exceed the width of the InfoWindow).
- Vertical scrollbars are added, but only when necessary.
- No content should overflow outside of the InfoWindow
- In most cases the InfoWindow is sized automatically to fit the content (not a fixed size)
- Should be suitable for mobiles and responsive layouts
- Margins, padding, fonts should all work OK
Downsides:
- My version requires jQuery, but it could probably be reworked to be pure JS
- It creates 20px of padding on the right of the content to make room for the scrollbar in case it is needed. You could skip this if you prefer, or do some more checking to only add padding when necessary.
- It's rather hacky, but without editing Google's javascript, it's possibly the only way.
View Code on Github
Please 2 submit improvements and corrections as you 1 find them.
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.