Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat ) Reporter
	Description • 10 years ago

Needed for
- parity with Safari
- ui on osx.

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html

See:  https://bugzilla.mozilla.org/show_bug.cgi?id=1030780

	Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat ) Reporter
	Comment 1 • 10 years ago

(Noted in:  http://arstechnica.com/apple/2014/10/os-x-10-10/18/)

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 2 • 10 years ago

This would be awesome to have, but I think it will be very difficult to do this with Apple's APIs: handoff requires an app to be iCloud enabled. And being iCloud enabled means you have to be on the app store.

	Blake Winton (:bwinton) (:☕️)
	Comment 3 • 10 years ago

Even for Native-App-to-Web-Browser handoffs?  https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW21 doesn't say anything about iCloud, and even mentions handing webpages off to the non-Safari default browsers (and of Chrome, Firefox, and IE, none of them are in the AppStore ;).

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 4 • 10 years ago

Blake I think you are right. I found this on: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/HandoffFundamentals/HandoffFundamentals.html#//apple_ref/doc/uid/TP40014338-CH3-SW1

"A third-party developer can use the same APIs to implement Handoff in apps that share the developer’s Team ID. Such apps must either be distributed through the App Store or signed by the registered developer."

	Blake Winton (:bwinton) (:☕️)
	Comment 5 • 10 years ago

See also https://codereview.chromium.org/481563002/ for Chrome's patch to enable the feature.  :)

	Justin Dolske [:Dolske]
	Comment 7 • 10 years ago

So. This partially works.

First, setup your Mac and iPhone/iPad so that Handoff is working with Safari. I think it's sufficient to be logged in to iCloud on both devices with the same account (and to have not disabled anything related to Handoff). You should be able to load a page in iOS Safari, wait a second or who, and see a Safari icon appended to the left side of your OS X dock. Clicking it loads the URL from iOS in Desktop Safari. [I've had this randomly stop working, although I was able to "fix" it by rebooting my iPhone.]

To test:

0) Apply patch and build. Then make your build the default OS browser (otherwise it will still handoff to Safari).

1) Load a page on iOS Safari, wait a couple seconds, and you should see a Nightly icon added to the left side of the dock for Handoff.

2) Click icon to load the URL.


This is working when my build is already running before #2. But if the browser isn't running when clicking the icon, it launches without loading anything. :-(

I'm not sure what's happening. The Handoff docs don't seem to say much about how it works if your app isn't already running. Either it's just supposed to work the same way but Firefox is weird/broken, or we need to do something else.

I did notice a weird error in system.log, and added some extra logging in ProcessPendingGetURLAppleEvents. This kinda makes me suspect there's an OS bug -- is it trying to pass us a GURL event but botches the URL? Is a GURL AppleEvent the expected way for us to be launched for a handoff?

Dec 23 12:12:17 Justins-MBP.local sharingd[201]: 12:12:17.506 : Received a new Handoff advertisement from "BaconPhone"

*click dock icon*

Dec 23 12:12:23 Justins-MBP.local sharingd[201]: 12:12:23.174 : Requesting Handoff payload
Dec 23 12:12:23 Justins-MBP.local firefox[5779]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.1 instead of 10.10.1. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
    Call location:
[...]
Dec 23 12:12:23 Justins-MBP.local firefox[5779]: --- ProcessPendingGetURLAppleEvents called
Dec 23 12:12:23 Justins-MBP.local apsd[50]: MessageTracer: load_domain_prefix_whitelist:120: Missing default whitelist file: /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Resources/SubmitDiagInfo.default.domains
Dec 23 12:12:23 Justins-MBP.local sharingd[201]: 12:12:23.877 : Received requested Handoff payload from "BaconPhone" ((null))
Dec 23 12:12:23 Justins-MBP.local firefox[5779]: *** __41-[LSUserActivity(Legacy) activityPayload]_block_invoke is scheduled for removal. Please file a radar against FirefoxDebug/org.mozilla.firefoxdebug and relate it to <rdar://problem/16662425>. (LSUserActivity.m #1101)
Dec 23 12:12:23 Justins-MBP.local firefox[5779]: Could not send 'gurl' AppleEvent, URL is nil. Payload: {
    }
Dec 23 12:12:23 Justins-MBP.local firefox[5779]: --- ProcessPendingGetURLAppleEvents event: (null)
Dec 23 12:12:23 Justins-MBP.local sharingd[201]: 12:12:23.945 : Received a new Handoff advertisement from "BaconPhone"

	Justin Dolske [:Dolske]
	Comment 8 • 10 years ago

Also, note that this patch only allows Firefox to _receive_ a handoff.

My understanding (see bug 1109806 comment 2) is that to _send_ handoff requests you need to be an AppStore app... However, it looks like Chrome just landed support for that in https://codereview.chromium.org/794853004/, so maybe it is possible? I don't see anything happening when I use Canary, though.

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 9 • 10 years ago

That Firefox does not open the page when it was not already running is likely not related to Handoff. The same thing happens if you for example open a link from Terminal.app when Firefox is not running: Firefox starts but then ignores the request to open the page. There must be a bug for that already.

	Justin Dolske [:Dolske]
	Comment 10 • 10 years ago

Ok, so I wrote a little native test app to test Handoff (ie, a minimal app to register as a browser and accept Handoffs as the patch here does). It work in both cases -- when invoking a handoff when the test app isn't running, it's launched and then has its restorationHandler invoked.

So, that's how Handoff seems to normally work. It's unclear to me why Firefox doesn't have this same code called.

	Steven Michaud [:smichaud] (Retired)
	Comment 11 • 10 years ago

Comment on attachment 8540906 [details] [diff] [review]
Patch v.1

I'd really need to test this to be able to provide feedback.

But I hate the way Apple has locked down IOS (and made it an unfair playing field for all but Apple apps).  So I don't own an iPhone or iPad, and on principle I'm extremely reluctant to acquire one.  So I think we need to look for someone else to provide feedback.

Stephen?  Markus?

	Stephen A Pohl [:spohl]
	Comment 12 • 10 years ago

Comment on attachment 8540906 [details] [diff] [review]
Patch v.1

I don't own/have an i-device either.

	Markus Stange [:mstange]
	Comment 13 • 10 years ago

I do have one.

	Richard Newman [:rnewman]
	Comment 14 • 9 years ago

Firstly, what can we do to get this moving?

Secondly, I have a dastardly scheme to detect when a user has pushed a URL via Handoff and offer them Firefox for iOS. I'll file that as a follow-up.

	Justin Dolske [:Dolske]
	Comment 15 • 9 years ago

(In reply to Richard Newman [:rnewman] from comment #14)
> Firstly, what can we do to get this moving?

It would be most helpful if someone more familiar with how OS X interacts with apps can help out with where I got stuck in comment 7 and 10. Or, really, just someone with more time than me to spend debugging in unfamiliar territory. :/

	Clayton Bodendein
	Comment 16 • 9 years ago

(In reply to Stefan Arentz [:st3fan] from comment #9)
> That Firefox does not open the page when it was not already running is
> likely not related to Handoff. The same thing happens if you for example
> open a link from Terminal.app when Firefox is not running: Firefox starts
> but then ignores the request to open the page. There must be a bug for that
> already.

I just tried doing
>   open -a /Applications/Firefox.app -g http://www.google.com
when Firefox (version 43.0.3 running on OS X El Capitan) wasn't already running and it successfully opened Firefox and went to that website. So maybe that issue was fixed in the past year?

Would anyone have the time to re-apply the patch https://bugzilla.mozilla.org/attachment.cgi?id=8540906 and test to see if the Handoff to Firefox works as expected when Firefox is running as well as when it is not running?

	Justin Dolske [:Dolske]
	Comment 17 • 9 years ago

(In reply to Justin Dolske [:Dolske] from comment #8)

> My understanding (see bug 1109806 comment 2) is that to _send_ handoff
> requests you need to be an AppStore app... However, it looks like Chrome
> just landed support for that in https://codereview.chromium.org/794853004/,
> so maybe it is possible? I don't see anything happening when I use Canary,
> though.

I just tested again, and this seems to work. A page opened in desktop Canary is available on my iPhone in Safari.

	Justin Dolske [:Dolske]
	Comment 18 • 9 years ago

(In reply to Clayton Bodendein from comment #16)

> Would anyone have the time to re-apply the patch
> https://bugzilla.mozilla.org/attachment.cgi?id=8540906 and test to see if
> the Handoff to Firefox works as expected when Firefox is running as well as
> when it is not running?

Amazingly, it still applies cleanly.

Still works when the browser is running, and now will open a window with the URL from mobile... Once. Further attempts result in a startup crash (below), which is obviously not good. Weirdly, it seems to work again (once!) if you do a handoff with the browser already running.


Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UAUserActivity sendGURLAppleEvent]: unrecognized selector sent to instance 0x1151034f0'
terminating with uncaught exception of type NSException
abort() called

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fff97cbfae2 __exceptionPreprocess + 178
1   libobjc.A.dylib                     0x00007fff9a685f7e objc_exception_throw + 48
2   CoreFoundation                      0x00007fff97cc2b9d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3   CoreFoundation                      0x00007fff97bfb601 ___forwarding___ + 1009
4   CoreFoundation                      0x00007fff97bfb188 _CF_forwarding_prep_0 + 120
5   LaunchServices                      0x00007fff9992e849 _OPTCEventHandler + 85
6   AE                                  0x00007fff97fe0231 _Z20aeDispatchAppleEventPK6AEDescPS_jPh + 531
7   AE                                  0x00007fff97fdffb8 _ZL25dispatchEventAndSendReplyPK6AEDescPS_ + 31
8   AE                                  0x00007fff97fdfed4 aeProcessAppleEvent + 288
9   HIToolbox                           0x00007fff93ec6af9 AEProcessAppleEvent + 55
10  AppKit                              0x00007fff8bee8588 _DPSNextEvent + 2245
11  AppKit                              0x00007fff8c2b4943 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
12  XUL                                 0x000000010402e126 -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 86
13  XUL                                 0x0000000104c5f556 _Z31ProcessPendingGetURLAppleEventsv + 134
14  XUL                                 0x0000000104c554f2 _ZN21CommandLineServiceMac19SetupMacCommandLineERiRPPcb + 274
15  XUL                                 0x0000000104c4fbee _ZN7XREMain11XRE_mainRunEv + 4878
16  XUL                                 0x0000000104c50738 _ZN7XREMain8XRE_mainEiPPcPK12nsXREAppData + 504
17  XUL                                 0x0000000104c50cad XRE_main + 237
18  firefox                             0x000000010000212f main + 1951
19  firefox                             0x0000000100001644 start + 52
20  ???                                 0x0000000000000001 0x0 + 1

	Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat ) Reporter
	Comment 19 • 8 years ago

looks like this is finished?

	Conrad Yoder
	Comment 20 • 8 years ago

(In reply to Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat ) from comment #19)
> looks like this is finished?

Not in any released build.

	Justin Dolske [:Dolske]
	Comment 21 • 8 years ago

(In reply to Gregg Lind (Fx Strategy and Insights - Shield - Heartbeat ) from comment #19)
> looks like this is finished?

Why would you think that? Nothing landed here, and I'm unaware of any other work to implement this.

	Stephen A Pohl [:spohl]
	Comment 22 • 8 years ago

(In reply to Justin Dolske [:Dolske] from comment #18)
> (In reply to Clayton Bodendein from comment #16)
> 
> > Would anyone have the time to re-apply the patch
> > https://bugzilla.mozilla.org/attachment.cgi?id=8540906 and test to see if
> > the Handoff to Firefox works as expected when Firefox is running as well as
> > when it is not running?
> 
> Amazingly, it still applies cleanly.
> 
> Still works when the browser is running, and now will open a window with the
> URL from mobile... Once. Further attempts result in a startup crash (below),
> which is obviously not good. Weirdly, it seems to work again (once!) if you
> do a handoff with the browser already running.

Does this still require a physical iPhone or iPad to reproduce? If not, I wouldn't mind taking a stab at it. If there is a way to get a loaner device via The Hub, that would work too. Would you know?

	Justin Dolske [:Dolske]
	Comment 23 • 8 years ago

(In reply to Stephen A Pohl [:spohl] from comment #22)
 
> Does this still require a physical iPhone or iPad to reproduce? If not, I
> wouldn't mind taking a stab at it. If there is a way to get a loaner device
> via The Hub, that would work too. Would you know?

I assume so... I don't know enough about OS X to know how to simulate launching Firefox this way without Handoff. You'd have to talk with IT about a loaner iPhone/iPad. (AFAIK either should work fine.)

I'm also happy to try running test builds, if the crash signature is something you think you can figure out without without real testing.

	Kaveh
	Comment 25 • 7 years ago

In order to be competitive, Mozilla should really look at supporting this.  Chrome/Opera/Safari all already support this on macOS.  Firefox is the outlier.

	Yannick Heinrich
	Comment 26 • 7 years ago

Could we help to speed up the development of this feature? What is missing to move on?

	Stephen A Pohl [:spohl]
	Comment 27 • 7 years ago

(In reply to yannick.heinrich from comment #26)
> Could we help to speed up the development of this feature? What is missing
> to move on?

We need to fix the issue in comment 18, assuming it still occurs. The steps would be:
1. Apply the patch in this bug. If it no longer applies cleanly, update it so that it applies properly.
2. Verify that the issue in comment 18 still occurs.
3. Fix issue.

	Yannick Heinrich
	Comment 28 • 7 years ago

(In reply to Stephen A Pohl [:spohl] from comment #27)
> (In reply to yannick.heinrich from comment #26)
> > Could we help to speed up the development of this feature? What is missing
> > to move on?
> 
> We need to fix the issue in comment 18, assuming it still occurs. The steps
> would be:
> 1. Apply the patch in this bug. If it no longer applies cleanly, update it
> so that it applies properly.
> 2. Verify that the issue in comment 18 still occurs.
> 3. Fix issue.

The patch needed a small update. It does not seem to crash but the URL is not opened if the handoff occurs when firefox has not been started.

Is there any better place to ask questions about firefox internals? It is the first time I digg into firefox source code.

	Stephen A Pohl [:spohl]
	Comment 29 • 7 years ago

You can try #developers or #macdev on IRC.

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 30 • 7 years ago

Since Firefox for iOS 10.5 we have pretty good handoff support between iOS devices. But pages still open in Safari when you handoff to your desktop. How can we move this patch forward and include it in an upcoming Firefox release?

	Justin Dolske [:Dolske]
	Comment 31 • 7 years ago

(Talked with Stefan earlier about how to move this forward.)

	Stefan Arentz | :st3fan | ⏰ EST | he/him
	Comment 32 • 7 years ago

The behaviour mentioned in comment #28 is actually not related to this Handoff patch. This patch works correctly. I filed bug 1433358 for not opening links on cold start. (Which also happens when you for example open Firefox from the command line with `open http://www.example.com`)

	Jon Parise
	Comment 33 • 6 years ago

I can also verify that this patch works correctly when applied to the latest code.

I also have a "cleaned up" version of the patch that moves the "URL opening" work into a common routine that can be shared by both ProcessPendingGetURLAppleEvents() and -application:continueUserActivity:restorationHandler:. I'll attach that here for now, but I can also propose it through the proper code review channels if there's interest.

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 35 • 6 years ago

I have updated the latest patch to work after bug 1491560, which was triggering an assertion. No crashes after multiple tries even across browser restarts. Green try run:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=502827056d2eb4aef5b28ec6ae7cec81ac477153

	Pulsebot
	Comment 37 • 6 years ago

Pushed by pastithas@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6ad9bd572bf4
Support Yosemite Handoff 'web browsing' activity type. r=spohl

	Eliza Balazs [:ebalazs_]
	Comment 38 • 6 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/6ad9bd572bf4

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 39 • 6 years ago

Release Note Request (optional, but appreciated)
[Why is this notable]: Long-requested feature, parity with Chrome & Safari.
[Affects Firefox for Android]: No
[Suggested wording]: Firefox now supports Handoff on macOS to continue browsing from your iOS device to your Mac.
[Links (documentation, blog post, etc)]: Apple support docs at https://support.apple.com/kb/PH25169