Open the map: http://militarymaps.info/ (no politic, just technical issue) Open it. Feel the slowness of FF. UI is unresponsive, Tabs and Windows as well. Chrome is fine with it.
I can confirm the issue (latest nightly, 64bit, e10s, Win7). The main process works ok (e.g. tab switching to about:... tabs), but the content process is hanged (militarymaps & other normal tabs remain blank when I switch between them)
This issue is still present!
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 BuildID: 20160205030204 I can confirm this issue. The Website makes use of GoogleMaps-API and the profiler shows, that these sections are especially slow. Probably related to Bug 697443?
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0 Hi, I have tested your issue on latest FF release (45.0), latest Nightly build (buid ID:20160310030242) and managed to reproduce it. This issue is most visible when using a PC that has a on board graphic card. I've used 2 PCs to run the tests, one with an on board graphic card and the other with a dedicated graphic card. 1. for the PC with the on board graphic card (AMD 760G), the UI becomes unresponsive, or it takes a couple of minutes to load the page but not with all of the UI elements. 2. for the PC with the dedicated graphic card (AMD Radeon R7 360 Series) the page loads faster, zoom in-zoom out works as expected, and from my point of view all UI elements are loaded Thank you.
Component: Untriaged → Canvas: WebGL
Vlad, can you please check the current state of this on all active branches? It would also be good to know if this is something we regressed or if performance has always been slow.
Hi Anthony, I have verified this issue on the following branches: - Nightly 48.0a1, Build ID: 20160419030312 - Firefox latest release 45.0.2, Build ID: 20160407164938 - Firefox Beta 46.0, Build ID: 20160418114253 - Firefox Dev edition 47.0a2, Build ID: 20160419004026 On the current builds the wait time for page load, is much similar with the one on Chrome. This behavior is encountered on both machines (the PC with integrated graphic card and for the one with dedicated graphic card). The tests were run with new profiles. I've opened a few tabs with different websites before opening http://militarymaps.info/ in another tab, and after the map has loaded I've switched between tabs. No issues on this side, the content of the websites was displayed instantly. From my point of view the issue with UI load and UI hang is no longer reproducible. Another scenario was to open a few tabs with different websites before opening http://militarymaps.info/ in another tab. When accessing http://militarymaps.info/, I was put in a queue. I've switched between tabs while I was queued. The content of other tabs is loaded slowly and the UI hangs for a few seconds. This behavior is experienced only if you are queued when accessing http://militarymaps.info/. Thank you.
The issue is not the loading, but using the site. Try to move the map.
With new profile it takes me 24 second to load this page and with my default profile 64 second, both profiles with e10s disabled. The slowdown is caused by Ghostery and ABP.
I did a bit of manual regression and investigated further the issue pointing to map manipulation on the following builds: - Nightly 18.0a1, Build ID: 20120901030528 - Nightly 20.0a1, Build ID: 20130104030823 - Nightly 29.0a1, Build ID: 20140102030203 - Nightly 37.0a1, Build ID: 20150101030214 - Nightly 48.0a1, Build ID: 20160420030213 (e10s enabled) The performance while using the map, has improved a little for the newer builds compared with the old ones, but when actions like zoom-in/zoom-out, drag & drop, map exploration are made, the map content is loading slowly and fractionated. Compared to Chrome, Nightly is sluggish when using the map. Tried to go further in the past to see how the map behaves on older builds, but on Nightly 12.0a1, and 15.0a1 the map didn't load. With mozregression I've tried to find when the page content started to successfully load. First good revision was 57abb5f70e01 (2012-07-15) and last bad revision was 0602e44ac248 (2012-07-14). Inbound failed because the rest of the builds were too old. Here is the pushlog for the entire day: http://goo.gl/YeVq7r . Maybe this helps in finding a solution.
Actually it is now OK with FF55.
You need to log in before you can comment on or make changes to this bug.