Firefox on Linux doesn't work with some OpenLayers3 examples, but Firefox on Windows and Chromium on Linux both work fine.

NEW
Unassigned

Status

()

Core
Canvas: 2D
P3
normal
3 years ago
4 months ago

People

(Reporter: R Mayer, Unassigned)

Tracking

36 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150224134236

Steps to reproduce:

I have this pretty simple HTML page that uses OpenLayers 3.3.0 to draw a map.

http://www.dishadish.com/ol3_linux_firefox_bug.html

On Firefox 36 on Linux Mint 17, if I zoom in one step further, all the map tiles disappear.   On any other platform I try (Firefox 36 on Windows; Chromium on Linux) it works fine. 

More details in the matching bug report for the OpenLayers project: https://github.com/openlayers/ol3/issues/3337 which has the source code of the HTML page; where they recommended I open a bug report here.


Actual results:

When zooming in one step on the map, all the map tiles vanish.


Expected results:

The map should have zoomed in.
(Reporter)

Comment 1

3 years ago
This HTML page can reproduce the issue:



   <!DOCTYPE html>
    <html>
     <body>

      <div id="map" style="width: 800px; height:600ps"></div>
      <script src="http://openlayers.org/en/v3.3.0/build/ol.js" type="text/javascript"></script>
      <script type="text/javascript">

        var projection = ol.proj.get('EPSG:3857');
        var projectionExtent = projection.getExtent();

        var layer = new ol.layer.Tile({
            extent: projectionExtent,  // this breaks firefox on Linux at zoom levels closer than 15.
            source: new ol.source.MapQuest({layer: 'sat'})
        });

        var map = new ol.Map({
          layers: [layer],
          target: 'map',
          view: new ol.View({
            center: [-13577000, 4520099],
            zoom: 15
          })
        });

      </script>
     </body>
    </html>

Comment 2

2 years ago
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID 	20151221030239

I reproduced this on Nightly 46 and changed the component to Core > Canvas:2D. If anyone considers that the component is not the right one, please change it to a more appropriate one.
Component: Untriaged → Canvas: 2D
Product: Firefox → Core

Updated

2 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a canvas2d issue. I can reproduce it with the cairo backend but not skia.
Using canvas debugging in the devtools shows that the there is an enormous clip path that is created after the succession of clearRect/drawImage that draw the different tiles in the map. Cairo (or at least the verion of cairo that we have in-tree) doesn't deal very well with enormous clips (it'll try to allocate an enormous mask surface regardless of the source and destination size when performing operations with clips.
It could be something else, but this bug is likely to be related to that cairo clipping business.

On the bright side we are pushing hard to switch to skia, so this might get resolved "incidentally". Lee, do you know how far off we are from switching the canvas backend to skia (I assume there isn't much to do compared to what's needed to switch the content backend)?
Flags: needinfo?(lsalzman)
Whiteboard: [gfx-noted]
(In reply to Nicolas Silva [:nical] from comment #3)
> This is a canvas2d issue. I can reproduce it with the cairo backend but not
> skia.
> Using canvas debugging in the devtools shows that the there is an enormous
> clip path that is created after the succession of clearRect/drawImage that
> draw the different tiles in the map. Cairo (or at least the verion of cairo
> that we have in-tree) doesn't deal very well with enormous clips (it'll try
> to allocate an enormous mask surface regardless of the source and
> destination size when performing operations with clips.
> It could be something else, but this bug is likely to be related to that
> cairo clipping business.
> 
> On the bright side we are pushing hard to switch to skia, so this might get
> resolved "incidentally". Lee, do you know how far off we are from switching
> the canvas backend to skia (I assume there isn't much to do compared to
> what's needed to switch the content backend)?

We resolved that the best way to deal with these sorts of issues is probably just to switch over to Skia canvas even on Linux, as we do for Windows, OS X, and Android.

We've filed a bug to track this eventual change: bug 1244754
Depends on: 1244754
Flags: needinfo?(lsalzman)
Is this still reproducible now that bug 1244754 has been fixed?
(Reporter)

Comment 6

2 years ago
With Firefox 46.0.1 the static html above still shows the problem.
(In reply to R Mayer from comment #6)
> With Firefox 46.0.1 the static html above still shows the problem.

The bug was fixed in Firefox 48. Could you test with Firefox Beta?
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.