[Bug] InfoWindow anchor not working
Description
I have set an anchor on InfoWindow as per the docs...
<AdvancedMarker
position={center}
onClick={toggleInfoWindow}
ref={markerRef}
>
<Pin
scale={2}
background="#ff9200"
borderColor="#000000"
glyphColor="#000000"
/>
</AdvancedMarker>
{infowindowShown && (
<InfoWindow anchor={marker} onCloseClick={closeInfoWindow}>
{infoWindowContent}
</InfoWindow>
)}
The InfoWindow is placed directly on top on the Pin (z axis) and completely obscures it. This same code was previously working. Whenevener next.js hot-reloads, it appears to sort itself out and the InfoWindow is shifted up into the correct position.
Steps to Reproduce
Load a page that has a gmap on it.
Environment
"@vis.gl/react-google-maps": "^1.2.0", "next": "14.2.14",
Logs
No response
Having this exact issue as well. Did you figure out any work arounds yet?
Best I've come up with is a manual pixel offset to make the InfoWindow float higher so it doesn't obscure/cover the marker, but if you drag it or place another marker with an InfoWindow near it, then the popup goes even higher (too high).
This feature needs fixing.
Still have the issue as well. Haven't yet figured out a workaround that works for me. Manual pixel offset break on page reload or hydration when the anchor starts to work.
Is this only happening while developing/ hot reloading using NextJs? Or does it somehow also translate to production build?
I'm not using NextJS personally. Seeing this issue both on CRA and Vite
@mrMetalWood This is happening in dev and production.
I have the same problem.
"next": "14.2.14", "@vis.gl/react-google-maps": "^1.3.0"
My workaround is creating a hidden state and delayed setState 500ms so that it would rerender the component, and the InfoWindow would bounce to the correct position.
I was able to reproduce the bug and I am working on a fix.
@dante-blitz @georgekolasa @Tataro We published 1.4.0 which should fix this issue. Can you check and see if that is the case for you? Would appreciate a short feedback if the issue is solved.
Looks like the issue's gone after updating to 1.4.0. Thanks for the fix!
@mrMetalWood LGTM so far, thank you!