1408203 - Long hangs/pauses/beachball on certain keyboard shortcuts in OS X High Sierra

Status: RESOLVED DUPLICATE of bug 1403460

(Core :: Widget: Cocoa, defect)

Description

[Dan McGee]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

1. Open browser to any page
2. Select some text
3. Hit Command-C to copy

Note that it seems a TON of keyboard commands fall under this slowness issue. I've seen it affect:
* Command-C (copy)
* Command-V (paste)
* Command-T (new tab)
* Command-W (close tab)
* Command-F (find)
* Command-A (select all)
* Ctrl-T (next tab)
* Ctrl-Shift-T (previous tab)

In all cases I've tested, NOT using keyboard shortcuts does not show the same problem. E.g. use "copy" or "paste" from the edit menu, click other tabs, etc.

I've started the browser in Safe Mode to no avail, same with running "Refresh Firefox" and trying there.

Other applications on my computer do not appear to be affected.


Actual results:

Beachball will appear, copy (or any other keyboard shortcut action) will take 5+ seconds


Expected results:

Copy or keyboard action happens instantly, no delay

Comment 1

[Dan McGee]

Here's a performance capture of a single "Command-C" occurrence; the 3.8 second hang time is obvious, but I'm not completely sure how to read this: https://perfht.ml/2gfeAWP

Here is a "Command-A": https://perfht.ml/2ghPpmd

This is a common slower component of both:

```
___getdirentries64
XREMain::XRE_main
(root)
```

Using dtruss, I caught it in the act, and it looks like an absolute mess. See attached "trace.dtruss".

This getdirentries64/fstatfs64/etc. business is *extensive*.


Here's the summary output from a "doing nothing" timespan using `time sudo dtruss -p 32179 -c`:

CALL                                        COUNT
ulock_wait                                      1
ulock_wake                                      1
kevent_qos                                      2
poll                                            2
workq_kernreturn                                4
bsdthread_ctl                                   9
pwrite                                         12
read                                           13
sendmsg                                        13
write                                          13
fcntl                                          18
kevent                                         32
recvmsg                                        39
psynch_mutexdrop                              288
psynch_mutexwait                              388
psynch_cvsignal                               538
psynch_cvwait                                1144
__semwait_signal                            10405


real	0m11.046s
user	0m0.368s
sys	0m0.336s


Here's the same thing, but with a "Command-A" during the similar wall clock timespan:


CALL                                        COUNT
__pthread_kill                                  1
poll                                            1
sigreturn                                       1
getrusage                                       2
psynch_cvclrprepost                             2
rename                                          2
__mac_syscall                                   5
gettimeofday                                    5
thread_selfid                                   6
kevent_id                                       8
kevent_qos                                      9
mprotect                                       14
munmap                                         14
lseek                                          18
mmap                                           19
ulock_wait                                     21
fcntl                                          30
ulock_wake                                     31
access                                         33
mkdir                                          33
recvmsg                                        44
psynch_cvbroad                                 70
getattrlist                                    72
getuid                                         74
workq_kernreturn                               75
pread                                          90
madvise                                       225
psynch_mutexdrop                              256
stat64                                        271
bsdthread_ctl                                 288
psynch_mutexwait                              329
fstat64                                       411
sendmsg                                       415
write                                         416
kevent                                        436
close                                         458
open                                          461
psynch_cvsignal                               698
read                                          826
fstatfs64                                    1551
close_nocancel                               1553
psynch_cvwait                                1567
geteuid                                      1617
open_nocancel                                1771
getdirentries64                              3215
__semwait_signal                             6212


real	0m11.116s
user	0m0.413s
sys	0m0.377s


Something going on with the "Input Methods" directories here is super fishy.

Comment 2

[Dan McGee]

Attachment: dtruss capture during a 'Command-A'

Comment 3

[Marcia Knous [:marcia]]

Dan: Thanks for reporting. Are you able to reproduce this issue using Firefox 57 beta? Thanks.

Comment 4

[isaac]

(In reply to Marcia Knous [:marcia - use ni] from comment #3)
> Dan: Thanks for reporting. Are you able to reproduce this issue using
> Firefox 57 beta? Thanks.

Just tried the 57 Beta and keyboard shortcuts seems to working normally again. I was experiencing this issue on the 56 branch as well.

Comment 5

[Dan McGee]

I am not able to reproduce in 57 beta. 57.0b8 (64-bit) seems to be much faster to respond to keyboard shortcuts. Would it be of any use to move back to the release channel again to see if it comes back, or just chalk this up as "fixed in 57"?

Comment 6

[Dan McGee]

Not to pile on, but this made me all but switch to Chrome for daily usage as the browser became unusable for someone used to doing a lot of things with keyboard shortcuts. I'm not sure what the timeline is on the 57 release, but it was extremely frustrating something as simple as copy/paste was so infuriatingly slow.

Comment 7

[Marcia Knous [:marcia]]

(In reply to Dan McGee from comment #5)
> I am not able to reproduce in 57 beta. 57.0b8 (64-bit) seems to be much
> faster to respond to keyboard shortcuts. Would it be of any use to move back
> to the release channel again to see if it comes back, or just chalk this up
> as "fixed in 57"?

We would have to have someone investigate your profiling to see what was going in before 57. Firefox 57 will ship 11/14, and it would be immensely helpful to have you on board until ship to see if you find any other High Sierra issues. Thanks!

Comment 8

[Matt Holgate]

I'm seeing the same problem in Thunderbird, and I've opened bug #1410806 for it. Thanks!

Comment 10

[Marcia Knous [:marcia]]

Duping this to Bug 1403460, which is being tracked for 57. They seem to be the same issue reported, just with a different description.

Comment 11

[mdoog3]

Just a heads up that after upgrading to MacOS 10.13.1 yesterday, this issue is no longer occurring.  I opened Bug 1409833 for this issue which was marked as a duplicate of this bug. Currently running Firefox 56.0.2 and after the upgrade to 10.13.1 all is back to normal.