866585 - Google Maps Polylines visible beyond edge of map

Status: RESOLVED DUPLICATE of bug 854873

(Core :: Graphics, defect)

Description

[whitejoshua2012]

Attachment: Google Maps Polyline example on Android Tablet.jpg

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

On an internal website that I am responsible for, I have used Google Maps. The map is generated with the following JavaScript:

  var options = {
    center: latlng,
    zoom: ZOOM,
    mapTypeId: google.maps.MapTypeId.TERRAIN,
    scaleControl:true
  };
  map = new google.maps.Map(mapDiv, options);

  weatherLayer = new google.maps.weather.WeatherLayer({
    temperatureUnits: google.maps.weather.TemperatureUnit.CELCIUS
  });

  cloudLayer = new google.maps.weather.CloudLayer();
  weatherLayer.setMap(map);
  cloudLayer.setMap(map);


I have then added some polylines to represent various things like routes and railways:

      railline = new google.maps.Polyline({
  			path: rail_latlng,
				strokeWeight: 2,
				strokeColor: linecolour,
				map: map
      });



Actual results:

In Firefox on Android 4.0.4 (Toshiba AT100 tablet) and Android 4.1.1 (Samsung Galaxy S3 4G phone), the polylines extend beyond the edge of the map. This only occurs in Firefox and not in Chrome or the default Android Browser on either of these devices. The desktop version functions correctly as well.


Expected results:

The polylines should not be visible beyond the edge of the map and should "disappear" at the edge of the map like the map markers.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Do you have a standalone test case that can reproduce this problem? It sounds like a clip rect somewhere is either missing or not being respected, and it could be anywhere in the stack, from the google maps script code to the gecko engine. Without a way to reproduce the problem this is going to be hard to debug.

Comment 2

[whitejoshua2012]

Attachment: Self-contained Sample HTML that causes polyline bug on Android Firefox.

I don't have an external site I can provide a link to, but I have put together this self-contained sample file that will demonstrate the bug, assuming you have a Net connection (requires Net access for the Google Maps API and jQuery).

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I can reproduce this on the latest Fennec nightly on a Nexus 4 using the attachment provided. It doesn't happen on Firefox desktop. (Note that you need to set security.mixed_content.block_active_content to false in desktop to load the page properly).

Comment 4

[Kartikaya Gupta (email:[e-mail])]

From a quick look at how the page works on desktop, there are a few top-level container divs with overflow:hidden that contain all of the map elements. The map area is split up into a grid of div elements, and the polyline is drawn by a set of canvas elements inside the div elements that make up the grid. Since the canvas elements are contained inside the overflow:hidden divs, the polyline should not leak out of the top-level div. I can replicate the bug on desktop if I change the overflow:hidden properties on the top-level containers to be overflow:visible, so it seems that on Fennec that overflow:hidden isn't being respected for some reason.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

What is the right thing to do here - get Fennec to deal with overflow:hidden, or draw "correctly", or both?

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I'm not sure what you mean. The overflow:hidden code in gecko is the same across all platforms AFAIK so I doubt the bug is in there. I suspect that in the case of canvas elements there are more layers being created and that somewhere in Fennec-specific gfx code there is a cliprect that is not being respected on some of the layers. At least that's my wild guess based on the observed behavior.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

This bug sounds kind of similar to bug 854873, and may have the same underlying issue. CC'ing nrc in case this bug (or the dupes/dependencies) shed more light or provide a test case that he can reproduce.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Adding a dependency on bug 854873 just so that this set of bugs is easier to find.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

This is fixed via bug 854873. Note that the test case attached in comment 2 still works but only if you have mixed-content blocking turned off, or you are viewing the page over HTTP rather than HTTPS.