google-map does not render to its size when used in core-animated-pages when it is in secion 1+

[cdata]

From @atotic on July 9, 2015 18:57

From @tobiashutterer on July 15, 2014 14:23

using in a just works right on index=0. When i try using or styling it on index 1-x the box is as i defined it, but the redered map just shows about 200px in the left upper corner of the map box.
.
Might this me a bug, or am I too stupid? I hope it is the second one.

Copied from original issue: GoogleWebComponents/google-map#33

Copied from original issue: PolymerElements/neon-animation#57

[cdata]

From @atotic on July 9, 2015 18:57

From @bamnet on July 15, 2014 14:38

Can you link to a sample which reproduces this?

[cdata]

From @atotic on July 9, 2015 18:57

From @ebidel on July 15, 2014 17:35

I believe the problem is related to the fact that the map's container is display: none initially. From here, the fix is:

google.maps.event.trigger(map, 'resize');

Haven't tested, but we can bake something like this into the map element.

[cdata]

From @atotic on July 9, 2015 18:57

From @ebidel on July 16, 2014 5:42

Unfortunately, there's no good way to detect when the parent element of the map becomes visible. I got it working by polling if .offsetParent was set using rAF callbacks, but that's not ideal. If core-animated-pages were to fire an event, the client can call mapEl.resize() to ensure the map is displayed properly. That method already has the google.maps.event.trigger(map, 'resize'); trick.

In the general case, mapEl.resize() will adjust the map to display properly.

[cdata]

From @atotic on July 9, 2015 18:57

From @sjmiles on July 16, 2014 6:16

Fwiw, this is a common problem and we need to work out a way to inform downstream elements of these kind of changes. I'm reluctant to get into broadcasting, but I don't have any better ideas at the moment.

[cdata]

From @atotic on July 9, 2015 18:57

From @addyosmani on July 16, 2014 8:38

Are there perf implications of excessive broadcasting you're concerned of?

[cdata]

From @atotic on July 9, 2015 18:57

From @ebidel on July 16, 2014 17:27

We almost need a platform primitive to know if an element is in the render tree.

[cdata]

From @atotic on July 9, 2015 18:57

From @ebidel on July 16, 2014 22:4

core-animated-pages now fires the "core-animated-pages-transition-prepare" event when transitions occur: googlearchive/core-animated-pages@e18d5bf

This should do the trick:

animatedPagesEl.addEventListener('core-animated-pages-transition-prepare', function() {
  mapsEl.resize();
});

[cdata]

From @atotic on July 9, 2015 18:57

From @ebidel on July 30, 2014 21:9

@tobiashutterer we moved this to the GoogleWebComponents org and will be keeping the release version up to date more frequently. You'll get the latest when using the plain bower install GoogleWebComponents/google-map.

Closing this as the workaround is posted above for the original issue.

[cdata]

From @atotic on July 9, 2015 18:57

From @phidias51 on March 10, 2015 20:6

I've noticed the same problem when embedding the map in a core-pages element or a core-collapse element. It looks like the map is being translated up and to the left, leaving grey space behind in its wake. The position is not centered in the middle of the map. Also, the map.resize() call is causing the original lat/longs to be shifted.

[cdata]

From @atotic on July 9, 2015 18:57

From @Zippersk on June 15, 2015 15:12

I have same problem with neon-animated-pages. I can't find som fire like neon-animated-pages-transition-prepare. Is there any solution to display map?

[cdata]

From @atotic on July 9, 2015 18:57

Pull #152 should have fixed this for neon-animated-pages. Have you tried #master

[cdata]

From @atotic on July 9, 2015 18:57

From @Zippersk on June 15, 2015 17:5

Install master verison helps! Thaks a lot. :)

[cdata]

From @atotic on July 9, 2015 18:57

From @kingflurkel on July 9, 2015 15:38

I still have this bug with neon-animated-pages.
I use this version: "google-map": "GoogleWebComponents/google-map#^1.0.0",
Any help / tips to get this working?

[cdata]

From @atotic on July 9, 2015 18:57

@kingflurkel if you have a test case, I can take a look

[cdata]

From @atotic on July 9, 2015 18:57

From @kingflurkel on July 9, 2015 18:8

http://actaanbod.bitballoon.com/
Click on the location icon. So I have google-map within iron-animated-pages.
Code:
https://github.com/A-StadLabs/activiteitenaanbod/tree/master/app/elements/a-activiteitenstage
https://github.com/A-StadLabs/activiteitenaanbod/blob/master/app/elements/a-locatie/a-locatie.html

[cdata]

From @atotic on July 9, 2015 18:57

Thanks.
google-map is not getting the iron-resize event. I'll have to dig in to
find out why.

On Thu, Jul 9, 2015 at 11:08 AM, Michael Thuy notifications@github.com
wrote:

http://actaanbod.bitballoon.com/
Click on the location icon. So I have google-map within
iron-animated-pages.
Code:

https://github.com/A-StadLabs/activiteitenaanbod/tree/master/app/elements/a-activiteitenstage

https://github.com/A-StadLabs/activiteitenaanbod/blob/master/app/elements/a-locatie/a-locatie.html

—
Reply to this email directly or view it on GitHub
GoogleWebComponents/google-map#33 (comment)
.

[cdata]

From @atotic on July 9, 2015 18:57

From @kingflurkel on July 9, 2015 18:31

Maybe because google-map is in another custom-element, which is in iron-pages?

[cdata]

From @atotic on July 9, 2015 18:57

The problem is in the neon-animated-pages. Because map is inside a custom element, it does not get a notification that it has been shown. Iniside neon-animated-pages:

      this.resizerShouldNotify = function(element) {
        return element == selectedPage;
      }
      this.notifyResize();

This should probably be: if element is selectedPage, or its parent is a selected page.

[cdata]

From @naoak on July 10, 2015 2:21

Hmm.. It certainly has a problem. For the present, adding IronResizableBehavior to pages (in this case, a-locatile) might be work.

[cdata]

From @naoak on July 10, 2015 3:41

This resizerShouldNotify trick code restricts resize notifications to only a selected page so that unnecessary resize notifications to invisible pages can be removed. But it requires children pages to be iron-resizable. I think we can handle this issue by two ways.

1. Improve the trick to check if an element's ancestor is a selected page.
2. Remove the trick and handle iron-resize events in each pages on user responsibility so that invisible pages ignore resize notifications.

Do you think which is the better?

[cdata]

From @naoak on July 10, 2015 4:21

I made a PR with the 1st way. Please confirm it.

[cdata]

From @atotic on July 10, 2015 8:17

Thanks, we'll have to wait for animated-pages owner to take a look at it.

[cdata]

From @kingflurkel on July 10, 2015 9:44

Yes @naoak ! This works like a charm.

[cdata]

From @naoak on July 10, 2015 9:54

Sorry to cause you trouble...
But, that's good to hear:)

[cdata]

From @morethanreal on July 10, 2015 19:19

@naoak I think your suggestion 2 is the better fix, because we decide whether or not to fire iron-resize on a subtree is at the page level. Since the interested node could be n levels deep it seems better to not walk the tree every time resize is fired.

[cdata]

From @naoak on July 12, 2015 11:46

You're absolutely right. The 1st way has a performance issue that cannot be ignored. I also think the 2nd is the better. But, on neon-animated-pages, it is a common case that invisible pages receive iron-resize events which originally should be ignored. I'd like to know a standard manner how to achieve this.
Many thanks.

[cdata]

From @morethanreal on July 13, 2015 23:17

@naoak @atotic IronResizableBehavior intends for both the resizing and resized element to implement the behavior, but in the case of neon-animated-pages it is resizing an element it doesn't own (ie. not itself, and not in its local DOM). My first thought is to require the user to implement IronResizableBehavior, but I echo the concerns about making this easy to use. I added some comments in the PR.

[cdata]

From @naoak on July 14, 2015 17:19

OK, I see. I found iron-pages also has the redundant resize notification issue, seeing https://github.com/PolymerElements/iron-pages/blob/master/iron-pages.html#L91.
I think reverting neon-animated-pages's notification is good to follow it, for the time being.

[cdata]

From @morethanreal on July 23, 2015 20:28

@naoak How do you feel about moving your PR to iron-pages?

[cdata]

From @naoak on July 24, 2015 1:50

@morethanreal I am okay with that. This issue is not essentially related with animations.

[cdata]

Moving this to iron-pages.

[ebidel]

Dupe of #13?

[notwaldorf]

Closing, as this could be a dupe, and much like #13 it doesn't have any repro steps. Please re-open this issue if it still occurs, with a JSBin containing a set of reproducible steps. Check this element's CONTRIBUTING.md for an example to help you get started.