When running IRC cloud with the lastpass extension installed, performance appears to be impacted. Based on my experience, this takes place after having a session open for several hours. Following this IRC cloud becomes sluggish, with noticeable lags when typing and switching channels. As more time passes I notice a greater impact, and if I leave my session for more than a day or so I start to encounter issues with unresponsiveness. I'm using the Lastpass 4.1.35a addon.
As a side note, you can open a ticket with Lastpass from your account on their page to make them aware of the problem. As a workaround, you could try adding irccloud.mozilla.com to the "Never URL" list in your account settings, I set it to "Never do anything" and it seems to help. That said, this needs someone to take a profile with the profiler and analyze it.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 I have tested this issue on Windows 10 x64 with the latest Firefox release (52.0.1) and the latest Nightly (55.0a1-20170324030205) and haven't managed to reproduce it. After running for a couple of hours, the IRC cloud with the latest lastpass(4.1.36a) extension installed, when switching from one channel to another or typing messages, I haven't observed any lagging. However, I've observed that sometimes the CPU goes up to 6% and the RAM Memory up to ~426mb when doing this. Could you please re-test this with the latest version of lastpass, and provide a performance report as mentioned by Marco in comment 1, in order to investigate this further? Thank you.
Hey, sorry for the wait. I have still seen some issues, however, I appreciate that is not a particularly helpful comment on my behalf without a profiler run. I'm going to hold this need info, and will gather a profiler run when I'm next seeing problems.
Created attachment 8856300 [details] Profile run during IRC Cloud chugging Here's a profile captured while I was seeing performance problems with IRC cloud.
I've been noticing the same - 5 to 20 second janks where the page is completely unresponsive. I've taken a profile using the new profiler, which seems to implicate LastPass: https://drive.google.com/a/mozilla.com/file/d/0B1HORKj_EvMPaVM0cDZfdnFtNkU/view?usp=sharing (requires MoCo google apps account to access) Notably I'm not even signed into LastPass -- they should disable page parsing when not signed in. (And ideally provide a way to opt out of the in-page icons and other similar features even when logged in. All I need is autocomplete that I can activate from the toolbar icon) That said, it would be good to confirm whether there's something Firefox can do to avoid chronic cases like this.
(In reply to Ed Morley [:emorley] from comment #5) > I've taken a profile using the new profiler, which seems to implicate > LastPass: > https://drive.google.com/a/mozilla.com/file/d/0B1HORKj_EvMPaVM0cDZfdnFtNkU/view?usp=sharing > (requires MoCo google apps account to access) To clarify, this profile was taken using the http://perf-html.io profiler on today's nightly (20170411030208), and with LastPass 18.104.22.168a. I've used Google Drive rather than the "share" option, since I can set the file to only accessible by Moco Google apps users.
Yeah, these long pauses look like LastPass scanning the DOM for form elements ... looks like they're trying to inject icons? Does disabling the field icons help? https://lastpass.com/support.php?cmd=showfaq&id=7586 If so, I wonder if we can reach out to the LastPass team and show them requestIdleCallback...
(In reply to Mike Conley (:mconley) from comment #7) > Does disabling the field icons help? > https://lastpass.com/support.php?cmd=showfaq&id=7586 I already have that feature disabled sadly. smaug was taking a look at this profile in #developers and had some thoughts: http://logs.glob.uno/?c=mozilla%23developers&s=13+Apr+2017&e=13+Apr+2017&b=1#c1584072
I sent them email. The addon does seem to have some very slow algorithms (O(n^2) or worse) so requestIdleCallback might not really help, if running some function still takes 12s or so.
I wonder if we should consider having a shorter slow script timer for content script sandboxes... It might even make sense to give the option to kill the content script entirely at that point. Having an add-on content script block the UI thread for anywhere near that long is completely inexcusable.
(In reply to Kris Maglione [:kmag] from comment #10) > I wonder if we should consider having a shorter slow script timer for > content script sandboxes... It might even make sense to give the option to > kill the content script entirely at that point. Having an add-on content > script block the UI thread for anywhere near that long is completely > inexcusable. Can we show in our UI prompt which add-on is making Firefox slow and allow the user to kill the add-on content script? (Basically do what you suggest with that UI?)
(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #11) > (In reply to Kris Maglione [:kmag] from comment #10) > > I wonder if we should consider having a shorter slow script timer for > > content script sandboxes... It might even make sense to give the option to > > kill the content script entirely at that point. Having an add-on content > > script block the UI thread for anywhere near that long is completely > > inexcusable. > > Can we show in our UI prompt which add-on is making Firefox slow and allow > the user to kill the add-on content script? (Basically do what you suggest > with that UI?) Yes, we should be able to get the add-on ID from the compartment at the top of the stack. Might be a bit tricky if content scripts wind up calling into page code, but probably doable (and not a factor in this case).
I looked through this profile and found something surprising. LastPass spends 11.8 seconds under LP_createXPathFromElement. For 8.1 of those seconds, elt_is_formlike_container is the caller. It looks like elt_is_formlike_container does not actually use the result of LP_createXPathFromElement. So that time is totally wasted. Additionally, LP_createXPathFromElement contains a loop that repeatedly iterates over all the nodes in the document. It does this to find out whether a nodes ID is unique. Rather than do this, they could use document.querySelectorAll("#id"), which should be much much faster.
CC Andrew from LP for comment 14.
firstname.lastname@example.org would be the best person to look at this.
I sent an email to Mike Chang.
I also reached out using our reviewer tools to let folks know that we'd like them to fix this asap.
The Lastpass changelog ( https://lastpass.com/upgrade.php ) reports that they released a new version 4 days ago that addresses this bug (wish they'd mentioned it here). 4.1.47 supposedly solves this.
(In reply to Gene Wood [:gene] from comment #19) > The Lastpass changelog ( https://lastpass.com/upgrade.php ) reports that > they released a new version 4 days ago that addresses this bug (wish they'd > mentioned it here). 4.1.47 supposedly solves this. The problem does not seem to be fixed in that version.
Bill, can you test version 4.1.48 to see if this issue is solved for your configuration?
I don't see that version on AMO. How do I get access to it?
https://addons.mozilla.org/firefox/downloads/file/636421/lastpass_password_manager-4.1.48-an+fx.xpi (unsigned, so needs install via about:debugging or disabled signing requirements)
Thanks. I have some questions about the fix and I'm following up with the LastPass people. I'll keep the needinfo on me for now.
They're working on a new version.
It looks like the 4.1.49 version should fix the problem!
(In reply to Bill McCloskey (:billm) from comment #26) > It looks like the 4.1.49 version should fix the problem! Bryce, can you confirm?
Reinstalling lastpass and taking a look. Will report back with findings.
Seems better to me. That said, I'm having to restart my browser almost daily as a result of Bug 1363589, so I don't have sessions running for as long as I have previously.