1491631 - Javascript, leaflet.js very slow

Status: RESOLVED DUPLICATE of bug 1421885

(Core :: Graphics: Canvas2D, defect, P3)

Description

[bernardzhu]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180912141329

Steps to reproduce:

I recently upgraded to Firefox 62.0, and started noticing pages with very heavy Javascript load very slowly. For example, a page I previously designed with Leaflet.js http://140.247.64.145/ shows an interactive network of about 800 nodes, each with a mouseover event. Moving the mouse around these nodes should instantly display the tooltips, as was the case in all prior Firefox versions (fine in 61.0), but in 62.0, this is extraordinarily slow. Network also cannot be dragged.


Actual results:

Moving the mouse around these nodes (with mouseover events) should instantly display the tooltips, as was the case in all prior Firefox versions (fine in 61.0), but in 62.0, this is extraordinarily slow. Network also cannot be dragged.


Expected results:

Tooltips should be displayed instantly with no lag.

Comment 1

[Andre Klapper]

See https://developer.mozilla.org/son/docs/Tools/Performance how you can provide more information.
Looks like the painting takes a long time?

Comment 2

[bernardzhu]

(In reply to Andre Klapper from comment #1)
> See https://developer.mozilla.org/son/docs/Tools/Performance how you can
> provide more information.
> Looks like the painting takes a long time?

I did the profiling of the website, 
In FF 61, which does not have problem, display is very efficient (avg. 51.93fps). Lots of activity and frame refreshes as you would expect from mousing over many nodes in the network.

In FF 62, it slows down to avg. 10.96fps. In the same amount of time, it can only manage a few mouse-overs (2-3) and sometimes it just freezes. The speed difference is really noticeable.

Breaking things down, here are the function time costs in FF 61:

Total time, Total Cost, Samples, Function
16464.55ms  78.3%       15315    Gecko
3300.44ms   15.7%       3070     Graphics
245.11ms    1.17%       228      JIT
172.01ms    0.82%       160      Tools

In FF62, here are the stats:

Total time, Total Cost, Samples, Function
19846.0ms   79.9%       19577    Graphics
4026.59ms   16.22%      3972     Idle
152.06ms    0.62%       150      Gecko
139.90ms    0.56%       138      JIT

You see that there is a switch from using Gecko in FF61 to using Graphics function in FF62. Gecko seems to be turned off or inactive in FF62. Could this be the cause?

Comment 3

[Gyula Palko[:gpalko]]

I've also tested this and I can reproduce the issue on the latest Release 62 build. Setting the component  in order to involve the development team in reviewing this issue.

Comment 4

[Lee Salzman [:lsalzman]]

Can you please use mozregression to narrow down to the revision that causes the problem? We would need this information to really track down the problem.

See https://mozilla.github.io/mozregression/quickstart.html

Comment 5

[bernardzhu]

 9:06.20 INFO: Using local file: /tmp/tmpGSMgK6/82c236207951--autoland--target.tar.bz2 (downloaded in background)
 9:06.20 INFO: Running autoland build built on 2018-06-12 23:11:55.919000, revision 82c23620
 9:20.08 INFO: Launching /tmp/tmp2IJf6m/firefox/firefox
 9:20.08 INFO: Application command: /tmp/tmp2IJf6m/firefox/firefox -profile /tmp/tmpddEFxU.mozrunner
 9:20.09 INFO: application_buildid: 20180612225125
 9:20.09 INFO: application_changeset: 82c23620795156dd9bc070659ac8a42f91bd378a
 9:20.09 INFO: application_name: Firefox
 9:20.09 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 9:20.09 INFO: application_version: 62.0a1
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
 9:34.65 INFO: Narrowed inbound regression window from [412df3e5, 6659f392] (3 builds) to [82c23620, 6659f392] (2 builds) (~1 steps left)
 9:34.65 INFO: No more inbound revisions, bisection finished.
 9:34.65 INFO: Last good revision: 82c23620795156dd9bc070659ac8a42f91bd378a
 9:34.65 INFO: First bad revision: 6659f392f4af0cef3cb4a5e19eef7e0e1b045f37
 9:34.65 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=82c23620795156dd9bc070659ac8a42f91bd378a&tochange=6659f392f4af0cef3cb4a5e19eef7e0e1b045f37
(In reply to Lee Salzman [:lsalzman] from comment #4)
> Can you please use mozregression to narrow down to the revision that causes
> the problem? We would need this information to really track down the problem.
> 
> See https://mozilla.github.io/mozregression/quickstart.html

Comment 6

[Alice0775 White]

I can reproduce the super slow on Windows10 Firefox62.0.
However, I can no longer reproduce the issue on Windows10 Firefox63.0b7 and Nightly64.0a1.

Comment 7

[Alice0775 White]

(In reply to Alice0775 White from comment #6)
> I can reproduce the super slow on Windows10 Firefox62.0.
> However, I can no longer reproduce the issue on Windows10 Firefox63.0b7 and
> Nightly64.0a1.

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d5950b441d27d8f6b19142d1d9336d3bd63d8635&tochange=0c55071115c23017c733aa421862beda1e6af20e

Comment 8

[Alice0775 White]

And next dot release of Firefox62 seems to fix this.

Comment 9

[Lee Salzman [:lsalzman]]

Matt, is this just a dup of bug 1421885? (also bug 1490625?)