1259884 - google keep, screen flicker, improper selection of text when reordering, erratic graphics, high CPU consumption

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Chris Murphy]

Description: When reordering items in Google Keep lists, the resulting behavior is erratic. Very high, 400+% CPU load, jerky and slow dragging of the selected item to its new location, inability to precisely place the item in the desired location in the list, display suggests items are being selected when they aren't I'm merely holding the mouse button and dragging one item to a new location.

This happens on all versions of Firefox on (Fedora) Linux in recent memory. It never happens on the same system on Chrome. And it doesn't happen on the same hardware rebooted to OS X and running the same version of Firefox.

Reproducible: 100% (on Linux)

Regression testing: It doesn't appear to be a regression, I've gone back to Firefox 39 and happens there as well.

Comment 1

[Chris Murphy]

Attachment: Screencast from 03-25-2016 08:24:43 PM.webm

screencast of the problem; there really are substantial delays in the selected item even starting to move, and then once it's moving it starts highlighting text as if I'm asking for a selection, rather than dragging/dropping an item to a new location

Comment 2

[Chris Murphy]

Attachment: firefox-troubleshooting-info

Comment 3

[Chris Murphy]

The problem is reproducible in Safe Mode.

Comment 4

[Chris Murphy]

Attachment: firefox.tar.gz

sudo strace -p <pid> -ff -o

Run with only Google Keep, no other tabs, while in safe mode.

Comment 5

[Davi Medrade]

I have the same problems with Aurora 47.0a2 (2016-04-25) on Ubuntu. CPU usage keeps hovering at around 15~20% (i.e. 60~80% of one core in a quad-core CPU) whenever the Google Keep tab is the active tab, even when it's just sitting there open, and even when there are maximized windows from other applications completely covering Firefox. That CPU usage drops to normal levels if I switch to another tab, or if I minimize Firefox.

On Windows 10 (same Aurora version) I haven't tested other things like moving notes around, but the CPU usage is basically the same (high while on the tab, low after switching to another tab).

The high CPU usage has been happening for months, but I finally got around to testing it with Chrome (to try to determine if it's an issue in Google Keep or in Firefox), and in Chrome the CPU usage is a lot lower (20%~30% of one core), but still steady and it also drops to basically nothing when I switch to another tab. In Chrome moving notes around is a lot more fluid (apart from a little freeze when you start moving a note for the first time which also happens in Firefox) and there are no text-selection issues (i.e. it doesn't keep selecting all the text on the page when you're trying to move a note).

Comment 6

[Wayne Mery (:wsmwk)]

can you get a profile of the problem?

Comment 7

[Wayne Mery (:wsmwk)]

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Comment 8

[Davi Medrade]

I can't reproduce this anymore.

They did make some big changes to Google Keep's interface, so if the cause of this issue wasn't fixed in Firefox, that might have.

Comment 9

[Chris Murphy]

When using trackpad physical click and drag, the problem does not happen. When using tap to click and drag, the problem does still happen most of the time. There is a nuance to make it happen that I haven't really figured out. It is easy to reproduce, but I can't articulate what movement makes it happens vs not. Best I can tell so far is speed. If I double tap then drag fast upward or downward to change the location of a checklist item, it starts highlight/selecting other items in the list. If I do the double tap and drag slowly, this doesn't happen. (I think.)


Reproduces on nightly flatpak, 53.0a2 (2017-02-13) (64-bit); but does still happen with the official Fedora RPM, 51.0.1 (64-bit).

Comment 10

[Chris Murphy]

Attachment: profile.json

This is from the nightly flatpak 53.0a2 (2017-02-13) (64-bit) on Fedora 25. I clicked on the wrench icon, chose Performance from the menu, and then click on start recording, then I reproduced the problem, clicked stop recording, and saved the resulting recording which is what's attached.