And it possibly affects other well-known websites like Facebook (it's slow too, but I haven't profiled it). I've been getting these "A web page is slowing down your browser" yellow bars fairly regularly this week on multiple websites. Here's a profile where the Dashlane add-on blocks for ~6 seconds. https://perfht.ml/2qHYbcu

Which versions of Dashlane and Firefox are you using? Is this the only add-on you have enabled? If not, have you isolated the problem to only the Dashlane add-on?

Here are two profiles taken with a fresh profile on today's Nightly (55.0a1 - 2017-06-01), only Dashlane 4.7.5 installed. https://perfht.ml/2rquiiF https://perfht.ml/2rqjIZ6

Hi Edouard, I'm a Dashlane developer. Thank you for bringing this to our attention. We have a couple of leads on the causes of the slowdown, we'll investigate further and keep you posted on our progress.

This is still happening with Dashlane 4.10.4 which was updated recently. My browser just locked up for literally 2 seconds while switching folders on fastmail.com. Not sharing the profile since it may contain sensitive info, but here's a screenshot.

Hi Edouard, I'm sorry to hear that. 4.10.4 did include some improvements in our use of mutation observers, but they were centered around the first page load, which seemed to be the biggest pain point emerging from our investigations. Did that use case improve? I'll keep digging to see what we can do to improve this during browsing as well.

Harald, someone recommended me to ping you if there could be a potential performance problem going on. I'm starting to think that Firefox may be the culprit in this case of extreme slowness, would you mind having a look at the profiles I captured in comment 2? I recommend having a look at the 2nd profile: we apparently spend a lot of time in js::ProxyGetProperty but I'm not sure how to interpret that result.

Looks like most time is spent in add-on code. js::ProxyGetProperty seems just a side effect of the recursive `visitNode` that is running in the add-on. ni? on kannan if this is something JIT can take care of.

Yeah. We're just hitting proxies constantly on this. It's also clear that the code is hot enough to be jitted (raw frame addresses showing up in the profile). I'll tentatively say the jit _should_ be able to handle this. We need to figure out what properties are being accessed. I tried to find a source repo for dashlane to look up the relevant source from the profile, but was not able to find any. Is dashlane OSS or closed? If closed, it might help to get access to the specific DOM-recursion that's hitting these. It'll help us identify what properties are being accessed on what kinds of DOM Nodes. Edouard, could you link me to the source, or provide a snippet that helps identify what the JS code is doing. Specifically, this is a call to 'visitNode' (which recurses) from 'processMutations'.

Sorry I do not have the source code myself (it looks like it is minified), I am merely a Dashlane user :)

So I did a little bit of digging/debugging of the Dashlane extension: I put a breakpoint in the matchabilityChange function, and it turns out that this.visited/this.treeChanges (instances of NodeMap ≈ 2 arrays with the same size) have a length of more than 40k+ items. However most of these items resolve to null (I'm guessing these are weak references). I wonder if this is what makes the script so slow to execute. > >t his.treeChanges.nodes.length > 41268 > > this.treeChanges.nodes.filter(e => !!e).length > 24

Found the NodeMap code: https://github.com/rafaelw/mutation-summary/blob/48a1559c0959cf4fe012f5c0385d0d16ed80ec0f/src/mutation-summary.js#L30-L73

So I investigated with the help of djvj, and from what I understood it appears that webextension DOM object proxies might be the ones causing the slowdown. I have created two testcases, in both cases we are doing the same thing: - Registering a MutationSummary, an abstraction above MutationObservers. Source code here [0] - Adding/Deleting a bunch of DOM nodes The first version of the page, slow_proxies_page.html, takes 300ms max on my computer. The second version of the page, slow_proxies_webext.html, used in conjunction with the minimal webextension I provided, easily takes 1sec or more. I'm also not sure how that would explain that using the dashlane extension, that problem only gets worse with time (after a restart everything's fast), maybe because we keep these DOM object proxies around somewhere? That's probably a different issue thought. [0] https://github.com/marcelklehr/mutation-summary/blob/master/src/mutation-summary.js

We have some ICs for getter calls over xrays. We probably just have to extend that for slot reads.

Could this bug be related to bug 613498?

That bug is the metabug for issues like what comment 12 describes where access to DOM bits over the proxies is slower than direct in-page access. That said, comment 12 has a 4x slowdown, while comment 0 describes a 6-second lockup. Even if we fixed the 4x slowdown you'd still have a 1.5s lockup, which is pretty horrible. :(

I'm a little confused by the profiles from comment 2. They have stuff like JS::WeakMapPtr::lookup and JS_WrapObject under XrayTraits::getExpandoObjectInternal. I guess maybe they predate bug 1355109 being fixed?

Up to date profile with latest nightly: https://perfht.ml/2wFAbKj

Thank you. So that profile seems to be for the comment 12 testcase, not the original extension here, right? It does show some time in Xray bits, about 1/3 of total time. There's also various time in the sandbox proxy handler (presumably reading globals in the sandbox; looks like 1/5 of total time) and various normal script execution.

Correct, this is comment 12 testcase. Here's a profile with the Dashlane extension (same test page): https://perfht.ml/2vMyuhK

(In reply to Kannan Vijayan [:djvj] from comment #8) > I tried to find a source repo for dashlane to look up the relevant source > from the profile, but was not able to find any. Is dashlane OSS or closed? > If closed, it might help to get access to the specific DOM-recursion that's > hitting these. It'll help us identify what properties are being accessed on > what kinds of DOM Nodes. Loic may help here?

This is probably not needed since I posted a simplified test case in comment 12. However, I'd like to request the webextensions blocking flag to be added to that bug, so this doesn't fall under the radar.

Can we prioritize this Andy? Not sure if you are the right person to ping, it may be on the platform side since we probably found the culprit, feel free to redirect that NI?. This is how bad we are performing at the moment: https://imgur.com/a/02ugy. As you can see from this screencap, Firefox is completely locked up ("Newer" link still has an underline) for a few seconds when changing pages. Using Firefox + this extension (and probably others who went unreported!) every day is painful.

Do we know what the problem is yet to prioritize?

This bug is most likely a manifestation of bug 613498. Accessing DOM elements from the extension process is very slow. We suspect bug 1388538 might help.

Dashlane has enough users to be a concern, both those bugs sounds pretty big to land in this cycle for 57 though. Kris does the analysis that its those bugs sound about right, any suggestions here?

Yes, this is caused by X-ray wrapper overhead. The only way to fix it, short of changing the extension to avoid unnecessary overhead (changing it to use WeakMaps rather than sticking objects in expando properties would be a good start), there's nothing we can do to fix it short of seriously optimizing the X-ray code.

Do we have a number on the server side telling us how many people have the Dashlane extension? It is not listed on AMO, so I am not sure this is actually possible. From their last press release, Dashlane claim they have 5M+ users and this problem happens on pretty much every website with heavy DOM manipulation, so we are probably regressing a ton of people. > there's nothing we can do to fix it short of seriously optimizing the X-ray code. I think bug 1388538 can definitely help here, but it is P3 at the moment, which doesn't reflect the seriousness of the situation in my opinion. Would it be possible to re-evaluate that priority Naveed? > changing it to use WeakMaps rather than sticking objects in expando properties would be a good start I tried making that change but mutation-summary tests are not passing. The DOM instances we are getting are different (despite representing the same element I think), so it looks like an "ID" expando is the best way to track them. https://github.com/rafaelw/mutation-summary/blob/master/src/mutation-summary.js#L38 for context. However, even if the results are probably incorrect, the change you suggested slashes my demo benchmark time by 2 (550ms avg instead of 1100), which makes me believe bug 1388538 can be VERY valuable. I believe the rest of the time is spent doing lookups in these 2 big this.nodes and this.values arrays. Also clearing Loic from Dashlane ni?

(In reply to Edouard Oger [:eoger] from comment #27) > Do we have a number on the server side telling us how many people have the > Dashlane extension? It is not listed on AMO, so I am not sure this is > actually possible. Yes, it's enough users that its a concern. If Naveed or others need that for prioritisation please ping me.

Adding [qf] whiteboard tag so Quantum Flow triage will review this bug.

Whoops, wrong Peter. Hey PeterV, is there anything else (besides bug 1388538) we can do here to optimize our Xray wrappers? A laundry list of ideas is fine, so long as we can turn them into bugs for prioritization.

Hi Edouard, I'm damien from Dashlane, since 5.0.6 we now directly use the MutationObserver API (without using the mutation-summary wrapper you mentioned). It looks like this fixed performance issues we had with pages triggering a lot of mutations. Can you confirm the issue is resolved on your side ? Thanks !

Hi Damien, I can confirm this has helped immensely: I can't recall seeing the "a script is slowing down your browser" bar recently. Running with_webextension/slow_proxies_webext.html from attachment 8893566 [details], I am getting: - 1100ms avg time with Dashlane < 5.0.6 - 80ms avg time with Dashlane > 5.0.6 - 20ms avg time without Dashlane. Dashlane still slows down webpages a little bit, but very far from locking down navigation completely like it used to before. Thanks a lot for taking the time to fix this! To Firefox people: what do we do with this bug? Should we close this and let bug 1388538 take priority? That regression is still probably happening with other extensions/web-pages.