IssueTracker

Oh and one more thing I forgot. Fragment A's child fragment is also part of the nested navigation controller, for which the Fragment A contains the root NavHostFragment, and not the root nav controller Fragment A is part of. So maybe it's not due to FragmentManager, maybe it's the nested navigation controller prematurely removing it's own fragment, when exitAnimation starts for it's root/parent fragment A.

Other than that, instanceState of the child fragment is preserved properly when navigating back and forth.. It's just that it's view is removed prematurely for some reason.

Ok I just tested it, and it is due to nested navigation graph. When I include a child fragment directly into Fragment A, without navigation, it's not removed prematurely and it's working as intended.

So where do we go from here, is this a bug for you to fix, or there's something wrong with my nested navigation graph implementation, in which case I'd like you to point me in the right direction how to fix it?

Here you go: https://drive.google.com/file/d/12Tz8YjCEbcs4LzxqL4352zUJyPvJ_GLt/view?usp=sharing

I slowed down the animations so you can see what's happening.

Root Fragment A is the one with BottomNavigationBar on the bottom.
GREEN - Fragment A's CHILD fragment (the one that's disappearing)
RED - Destination Fragment

Press "Settings" in the action menu on the upper right to start navigation. Observe how Root Fragment A is visible during the whole animation with it's BottomNavigationBar, but it's CHILD GREEN fragment disappears immediately, as it is part of the nested navigation graph hosted in the Fragment A itself.

On the way back, Fragment A is properly recreated with it's green child fragment, and both are visible properly (when going back in the direction A <- B).

I'm having trouble downloading your project from Google Drive for some reason. Would you mind attaching it here directly?

I suspect this is a Fragment issue and not something Navigation can control. I'd be interested to know if you run into the same issue if you have *any* Fragment, rather than a NavHostFragment, between your child of A and A itself.

I'll test that too when I have some time, though it might not be soon.

I'll attach the project directly so you can test it yourself, and if it is the problem with Fragments, then let's open the issue for Fragments..

Thanks, we've confirmed this is a problem with Fragments and have marked it as a duplicate of the relevant Fragment issue.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit c53170c58309d7370d63d5386e83fce4cee02ba2
Author: jbwoods <jbwoods@google.com>
Date:   Wed Jun 26 17:58:38 2019

    Avoid grandchild Fragment animations running during parent Fragment transactions
   
    Follow-up to aosp/951635. Child fragment views are not destroyed when the parent
    is animated, but grandchild fragment views are.
   
    This change checks up the ancestor hierarchy to ensure fragment views
    will not be destroyed if any of its ancestors are being removed.
   
    Test: Added unit Test
    BUG: 116675313
    Change-Id: Ie65ae2fb150340b51bb0362cfa84f320ee2e8c7e

M       fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimationTest.kt
M       fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java

https://android-review.googlesource.com/1001542
https://goto.google.com/android-sha1/c53170c58309d7370d63d5386e83fce4cee02ba2

This has been fixed internally and will be available in the Fragment  1.2.0-alpha01 release.

This actually just missed the 1.2.0-alpha01 cut off, so it'll actually be in 1.2.0-alpha02.

Can confirm fix in "androidx.fragment:fragment:1.2.0-alpha02". Thanks a lot!

I don't know guys if you found a solution, but this: http://www.canbike.ca/information-technology/2013/11/01/firefox-infowindow-scrollbar-fix-google-maps-api-v3.html helped me alot :)

I previously worked around this by specifying the use of version 3.13 of the api.  This does not appear to be working in Chrome anymore.

version 3.13 was retired with the release of 3.16 in February. When you request it you get 3.14.  See versioning in the documentation:
https://developers.google.com/maps/documentation/javascript/basics#Versioning

I'm seeing double scroll bars on my localhost dev. site, but not on the live site?

Getting all kinds of scrollbars in IE10. Would be good to get a status update on this one... it's a confirmed issue that's been open since August 2013.

Just to summarize all the solutions that worked for me in all browsers:

Don't use margins inside the infowindow, only padding.
Set a max-width for the infowindow:

this.infowindow = new google.maps.InfoWindow({
    maxWidth: 200
});

Wrap the contents of the infowindow with

<div style="overflow:hidden;line-height:1.35;min-width:200px;">*CONTENT*</div>

(change the min-width for the value you set on the infowindow maxWidth)

I have tested it and it worked on every browser, and I had over 400 markers...

Hi Team,

I have tried above solution but it will not worked with me.

Could you please confirm how can we use google class "gm-style-iw"

Currently its showing as :

<div class="gm-style-iw" style="left: 12px; top: 9px; width: 182px; height: 119px; overflow: auto; position: absolute;">

Thanks,
Mayank

Bcke / Google Team: could you let us know what version this is fixed in, and what was fixed?  

I tried my original jsFiddle (from the first comment) using version=3.exp but I get the same result - scrollbars.  

Here's the updated fiddle:
http://jsfiddle.net/67nQF/7/

I think there were two issues:
1.  Loading the Roboto webfont (which causes scrollbars only the first time the infoWindow is opened).  
2.  The infoWindow size is calculated wrong when it has fractional pixel width/height.

Hi Team,

I have tried above solution but it will not worked with me.

Could you please confirm how can we use google class "gm-style-iw"

Currently its showing as :

<div class="gm-style-iw" style="left: 12px; top: 9px; width: 182px; height: 119px; overflow: auto; position: absolute;">

Thanks,
Mayank

http://www.canbike.org/information-technology/2013/11/01/firefox-infowindow-scrollbar-fix-google-maps-api-v3.html

it work

I am having same / similar problem.
I would like to have info window of fixed width (200px), no scroll horizontal.  And fixed height WITH vertical scroll if content exceeds height.

It seems current version of API (July 2014) is setting wrapper div (class="gm-style-iw") width to exactly whatever my content sub wrapper/div width is - leaving no room for vertical scroll bar. Therefore overflow auto is giving me horizontal scroll bars whenever vertical bar is needed.
It is also doing this 'hard coded' in style in element code, not CSS.  So I can not override with my own CSS.

I assume / hope this is only a bug oversight in currnet version.

Meantime my workaround is:
1.   open info window.  
2.   get all the document.getElementsByClassName"gm-style-iw") divs (For some reason there are multiple ones even though only one infowodnow is open?)
3.   reseting their widths to 24 less than whatever API hard coded it to


function CCinfopop([passed arguement identifying marker & infowindow]) {
        if (typeof COinfowin == "object") {COinfowin.close()}
        COinfowin = [whatever infowin object]
        COinfowin.open([whatever associated mark]);
        xinwins = document.getElementsByClassName("gm-style-iw")
        xwide = xinwins[0].offsetWidth
        xwide = xwide + 24
        for (xz=0; xz<xinwins.length ; xz++) {
                xinwins[xz].style.width = xwide+"px"
        }
}

This is an ugly workaround, hope only temporary while Google fixes.

This is still a very noticable and difficult-to-work-around bug.  Here's a super-simple InfoWindow example with ugly and unnecessary scrolling in Chrome 37, Firefox 31 and IE 11.

EXAMPLE: http://jsfiddle.net/jj71gtj5/4/

What's interesting is that in Chrome it only occurs at some font sizes, not all (35px, 38px, 41px, 44px, 47px, etc.).  So it must be some kind of pixel-rounding bug when measuring the content's dimensions.

Simon.

I was looking for something not overcomplicated, this css worked for my requirements:

.gm-style-iw > div { overflow: hidden !important; }

I am experiencing same issue but only on chrome.
This also worked for me:

.gm-style-iw > div { overflow: hidden !important; }
.gm-style-iw { overflow: hidden !important; }

#29 Resolution fixed for me.

#29 is not a fix - it's just a workaround.  The InfoWindows are designed to add a scrollbar when the content is too large for the window.  That CSS code disables that functionality and just cuts off any excess content leaving it inaccessible.  

See here:  http://jsfiddle.net/simoneast/jj71gtj5/25/

While it may be OK if you know for sure that your content is small and will never be cut off, it doesn't work well for dynamic content from a CMS or on mobile devices where the map canvas may be smaller.

Simon.

I completely agree with #31, #29 does not solve the problem unless you know the content won't get cut off.

If you're still seeing problems with info windows and scroll bars, please add a link to your demo, and state which operating system and browser you're using. Thanks.

The demo posted with this bug report (http://jsfiddle.net/67nQF/embedded/result/) is still displayng the scroll bar. Running on Chrome Version 38.0.2125.104 m under an up-to-date Windows 8.1 64 bits.

Same with this demo: http://jsfiddle.net/jj71gtj5/4/ (also previously reported)

Both demos above also fail Chrome  38.0.2125.104 m, Win7/64

Also applies if you remove the CSS font size:

http://jsfiddle.net/1kduofzg/1/

...and if you remove the wrapper div...

http://jsfiddle.net/1kduofzg/2/

...and if you trim down to just 3 words...

http://jsfiddle.net/1kduofzg/3/

...but works if you drop the last character.

http://jsfiddle.net/1kduofzg/4/

Very easy to replicate this one.

Posts #34, #35, #37 also fail in:
- Chrome 39.0.2171.36 beta-m (latest beta) on Windows 8.1 64bit
- Firefox 32.0.3 on Windows 8.1 64bit (although no scrollbars are shown, content is simply clipped)
- Firefox 33.0.1 (latest) on Windows 8.1 64bit (although no scrollbars are shown, content is simply clipped)
- Opera 25.0.1614.50 (latest) on Windows 8.1 64bit

Posts #35 and #37 (but not #34) also fail in:
- Internet Explorer 11.0.9600.172239 on Windows 8.1 64bit

[Comment deleted]

I used CSS:

.gm-style-iw > div {
        overflow: visible !important;
}

seems to work for me for the time being.

So much anger on here for such a great resource given to us to use for free.

Hi Joel,

Unfortunately your code does not work well when the content is bigger than the InfoWindow.  

See: http://jsfiddle.net/1kduofzg/14/ and also comment #31.

Changing the font (back) to Arial seems to work for me.

Could it have something to do with the way the info window is created? Given the fact some people have reported the following to work (not including height/width/overflow):
- line-height: normal
- font-family: Arial
- white-space: nowrap
- ...

It seems that the info window does not have all the styles yet it will received once its injected into the DOM. This causes the dimensions to be incorrectly calculated and leads to an info window that is too small for its contents.

Hopefully you'll find the culprit soon. Seeing as the code is only available in a minified version, I can't properly debug it myself.

Also see http://stackoverflow.com/questions/1554893/google-maps-api-v3-infowindow-not-sizing-correctly for more complaints/solutions.

A bug with info windows displayed when using the signed-in feature of the Maps API may be related to this issue. The 'Save to Google Maps' link gets truncated instead of the info window getting resized. The issue is at https://code.google.com/p/gmaps-api-issues/issues/detail?id=7445 

Solved: Close and reopen the infoWindow to let the browser calculate the real dimension, do this using a 30 milliseconds timeout!

 google.maps.event.addListener(marker, 'click', function() {
   infoWindow.setContent(info);
   infoWindow.open(map,marker);
   setTimeout(
    function(){
     infoWindow.close();
     infoWindow.open(map,marker);
    },30);
  });

Best regards:

 the Informate.it Developer Team

#45 doesn't seem to resolve it. See the demo here:

http://jsfiddle.net/8upowkfq/

Ok, I _think_ this is finally fixed in 3.exp = 3.19

Let me know if it's not.

It's fixed for me indeed. Hooray!!

Some scrollbars just got re-introduced in my map :-\ Vertical scrollbars to be precise.

Some text content apparently had too long of a line length (too wide), forced to wrap to the next line, and the vertical space calculation doesn't account for that. So as a fix (for now) I'm forcing a slightly wider width.

For others, my workaround was to target the info window div and give it "min-width:XXXpx !important;"

FYI, the line of text causing the problem is a paragraph with bold font weight. Dunno if that's a factor or not.

Oddly enough, just afternoon in our app we had an issue introduced suddenly where our InfoWindow suddenly was three times larger than it needed to be (see attached).

Removing the "height: 100% !important" from our .gm-style-iw class seemed to alleviate the issue.

Appears to resolve the ones I was hitting.

The fix does remove the scroll bar problem in the maps which I've tried.

There is however a new problem which happens when the 'maxWidth' InfoWindowOption property is set. Then the info window displayed is totally blank.

Does anyone else get the same problem ?

Thanks for the feedback guys!

Re #49 Could you share a code sample that displays the issue?

Re #50 I'm glad that you could remove the css and resolve your issue. I don't know what "height: 100%" means in this situation... 100% of what?

Re #52 Could you share a code sample that displays the issue? maxWidth works correctly for me, in the cases I've tried so far.

Thanks by the way!

I checked my code and realised that my maxWidth property was being set to zero, so hiding the info window content is what should happen in this case.

Thanks for the fix!

#53, please send me a PM and I'll give you a link. Attached is a screenshot of the issue.

I also just got a FOUC that might shed some light. It seems before CSS styles are applied, the text is much smaller in the info window, and everything fits.

Attached is an mp4 that shows the FOUC at about the 14 second mark. I had to clear my browser first, to clear the cached CSS.

Apologies, last screenshot seems like it didn't attach. Trying again.

[Comment deleted]

I can also attest to some internal change recently.  Not sure when it began, but I noticed the infowindow was displaying differently yesterday.  I had not changed anything on my end.  My search led me here.

I also removed the css styles set for .gm-style-iw and removing them corrected the issue.  In my case I was using height: 100%; and width: 325px;.

Good to see someone at Google finally rectified this issue.  I remember when I was implementing this and was pulling my hair out until I found the css 'fix'.

When using 3.19 of the API, the infowindow now appears twice as wide as it did before.  I have reverted the code back to use 3.18 but how do I fix this for 3.19?

That's funny about your infowindow being twice as wide. Could you share a code snippet that demonstrates the problem?

While using 3.19 of the API, the size of the infoWindow has become smaller. I cannot set max height as the content is dynamically generated.

I am also seeing a sizing issue with 3.19 but not 3.18 for IE8,IE11 but not Chrome.
In 3.19: The width is set much too wide under 3.19 [in IE8/11, Chrome is ok]
In 3.18: Nicely fits the embedded html 3.18 as designed [IE and Chrome]

Hi Paul,
Could you please link to a page that displays the problem?
I haven't been able to reproduce the issue you mentioned.

[Comment deleted]

The problem (only) occurs whilst the IE browser is in compatibility mode (which I need).
I confirmed that by adding the following, it "fixed" the 3.19 version:

    <meta http-equiv=X-UA-Compatible content="IE=8" />

Attached is the stand-alone test popuptest.html -> it hard codes to use 3.19
Use IE10 or IE11 browser

Test1: Run as is : popups work normally
Test1: Change browser to compatibility mode: *** popups too wide ***
Test3: Uncomment the IE=8 line : popups work normally
Test4+: Change to 3.18 and run all above tests: popups work normally