search

deanishe / alfred-firefox

Search and control Firefox from Alfred
Other
345 stars 19 forks source link

Switching to open tabs is extremely slow on M1 Mac mini #23

Closed jrochell closed 3 years ago

jrochell commented 3 years ago

I use the alfred-firefox on an Intel MacBook Pro without any issues. However, on a new M1 Mac mini, the tab command functions incredibly slowly, and performs the action several minutes after submitting it. The other actions (bookmarks, history, etc.) behave instantly as expected - only switching to open tabs takes a very long time.

I already attempted to reinstall alfred-firefox and the Firefox Integration add-on, and also in a new Firefox profile. It's reproducible on both release and beta versions of Firefox (versions 85 and 86). macOS 11.2.1

Happy to share any logs or other information to help diagnose.

erdnaavlis commented 3 years ago

I have a Macbook Air M1 and I'm experiencing this exactly same behaviour :(

brttbndr commented 3 years ago

I think this is due to the alfred-firefox binary shipped with the extension. It is built for x86_64 (not arm64, not universal). The AppleScript to activate Firefox before switching tabs will hang if it's run as x86_64.

The tab action invokes RunAS:

https://github.com/deanishe/alfred-firefox/blob/63fcc7ac5f5c7717d0bccf63355c9406aeab8227/actions.go#L107

and this is where the stall occurs. You can observe this in output from ps when you're waiting, like this:

33179   ??  S      0:00.03 ./alfred-firefox tab https://www.amazon.com/
33180   ??  S      0:00.05 /usr/bin/osascript -l AppleScript -e tell application "Firefox" to activate

If you clone this repo on a M1 and do a go build you'll get an amd64 binary. Swapping this in for the one shipped w/the extension solves the stalling problem. (Note you need to copy the build artifact alfred-firefox-assistant to alfred-firefox in the workflow's installed directory.)

I've found I can reproduce the hang in isolation like so:

# this works
arch -arch x86_64 osascript -e 'log "Hello, World"'
# as does this
arch -arch x86_64 osascript -e 'display notification "Hello, World"'
# this hangs
arch -arch x86_64 osascript -e 'tell application "Firefox" to activate'
# and this works
arch -arch arm64 osascript -e 'tell application "Firefox" to activate'
erdnaavlis commented 3 years ago

I've tried your suggestion

Unfortunately, if I check the Activity Monitor it still shows that the architecture is Intel :(

Any suggestions?

image
brttbndr commented 3 years ago

I'd guess either the build wasn't for arm64, or the alfred-firefox that's running isn't what got built.

I'm using go installed with homebrew, with /opt/homebrew/bin on my path.

➜  brew info go
go: stable 1.16 (bottled), HEAD
➜  go version
go version go1.16 darwin/arm64

Here's what I have in my workflow directory -- I backed up the "official" build as alfred-firefox.x64

➜  file alfred-firefox
alfred-firefox: Mach-O 64-bit executable arm64
➜  file alfred-firefox.x64
alfred-firefox.x64: Mach-O 64-bit executable x86_64

And in Activity Monitor I get Apple as the architecture:

image
erdnaavlis commented 3 years ago

fixed it! Nevermind, my go installation was messed up. Everything is working smoothly. Thanks 👍

brttbndr commented 3 years ago

It's also possible to build a universal binary so that the workflow works with Alfred synced between an M1 and an Intel Mac. 

for arch in amd64 arm64 ; do
  GOARCH=$arch go build -o alfred-firefox-assistant.$arch
done
lipo -create -output alfred-firefox alfred-firefox-assistant.*
jrochell commented 3 years ago

@brttbndr I'm having trouble following the steps to install a universal binary. Is there any chance you could provide it as a direct .alfredworkflow download?

brttbndr commented 3 years ago

@jrochell Sure -- here's a patched build that takes the most recent release from this repo, and swaps in a universal binary (built w/the snippet I wrote above).

https://github.com/brttbndr/alfred-firefox/releases/tag/v0.2.1-universal

jrochell commented 3 years ago

It works! Thanks so much for this.