1118346 - Loop: Loop:RoomURLEmailed is not firing when mailto is handled by a webmail provider

Status: RESOLVED DUPLICATE of bug 1110602

(Firefox :: Tours, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

In bug 1080948 events were added to inform the web page if the Copy Link or Email buttons were clicked.

In testing, we're finding that the Loop:RoomURLCopied IS being fired when "Copy Link" is clicked, but NOT when "Email" is clicked.

My environment is OSX with no native email account set up

This at least effects the step where the info panel changes in the room view, but it could mean the user misses the final step of the tour since we tell FF to reconnect when this event is received.

Comment 1

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

More information:

# Users affected

Users who click "Email" on the last step will not see the updated info panel with instructions to "not wait around" like they do when "Copy Link" is clicked (http://cl.ly/image/3M0C2j450q0e).

# Metrics

We will not be able to count these clicks in GA. We will still be able to count "Copy Link" clicks.

# Other side effects

There could be another more serious side effect which will stop these users from seeing the last step of the tour (when a friend connects the conversation) since we use this event to tell FF to reconnect.

:agibson - per our IRC conversation, please investigate if it's possible to tell FF to rejoin after "Start a conversation" is clicked, and how this could change the workflow (if at all).

Comment 2

[Alex Gibson [:agibson]]

(In reply to Cory Price [:ckprice] from comment #1)
> :agibson - per our IRC conversation, please investigate if it's possible to
> tell FF to rejoin after "Start a conversation" is clicked, and how this
> could change the workflow (if at all).

I've tested this locally and I think it should be fine. All we need to do is move the following line of code:

    Mozilla.UITour.setConfiguration('Loop:ResumeTourOnFirstJoin', true);

If we set this once the conversation view has opened after the user clicks "Start a Conversation", instead of when the copy/email button is clicked; it should not change the current workflow. Clicking "Start a Conversation" does still at least guarantee that the user has interacted with the FTE past the first step.

Comment 3

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Thanks Alex. I've also received confirmation from Chad and Eric that this will not be a blocker for GA 35.

We would like it fixed for GA 36 if possible.

Comment 4

[Justin Dolske [:Dolske]]

(In reply to Cory Price [:ckprice] from comment #0)
> In bug 1080948 events were added to inform the web page if the Copy Link or
> Email buttons were clicked.
> 
> In testing, we're finding that the Loop:RoomURLCopied IS being fired when
> "Copy Link" is clicked, but NOT when "Email" is clicked.

Are you listening for the right events? The code indicates it fires Loop:URLCopied when the Copy Link button is clicked, and Loop:URLEmailed when the Email button is clicked.

Comment 5

[Alex Gibson [:agibson]]

(In reply to Justin Dolske [:Dolske] from comment #4)
> (In reply to Cory Price [:ckprice] from comment #0)
> > In bug 1080948 events were added to inform the web page if the Copy Link or
> > Email buttons were clicked.
> > 
> > In testing, we're finding that the Loop:RoomURLCopied IS being fired when
> > "Copy Link" is clicked, but NOT when "Email" is clicked.
> 
> Are you listening for the right events? The code indicates it fires
> Loop:URLCopied when the Copy Link button is clicked, and Loop:URLEmailed
> when the Email button is clicked.

Thanks Justin, I didn't actually know we had this event available! I was under the impression we had just a single event for both buttons.

It actually seems to be called 'Loop:RoomURLEmailed'.

Cory, I think we can mark this bug as invalid? :)

Cory,

Comment 6

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

(In reply to Alex Gibson [:agibson] from comment #5)
> Thanks Justin, I didn't actually know we had this event available! I was
> under the impression we had just a single event for both buttons.
This was also my impression from our engineering meetings, so this is great news!

> Cory, I think we can mark this bug as invalid? :)
Sounds good to me :) I'll also mark bug 1115225 as Invalid.

Comment 7

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Looks like we spoke a bit too soon.

The Loop:RoomURLEmailed event is only firing when the default mailto application is set to Mail.app on OSX (haven't tested other platforms).

Priority is still good for GA 36, and the web work-around described in comment 2 is still valid.

Comment 8

[Justin Dolske [:Dolske]]

Testing with Nightly on OS X, this generally seems to work.

However I sometimes seem to be able to get things into a state where I see UITour.notify() being called from chrome, but the content message listener isn't being invoked. I _think_ the screwup is triggered by changing the default mailto handler to one of the built in web protocol handlers (eg Gmail/Yahoo). We're opening a new tab upon clicking Email Link, so I wouldn't be surprised if something is getting confused by that.

However, this seems like an E10S specific bug, and the code in Firefox 35 isn't using this (it's directly generating content events that drive the tour).

Is this reproducible with Firefox 35, or is it Nightly-only? (I'm out of time for testing tonight.)

We do have tests for this, so I'd strongly suspect that this is only breaking when mailto is opening Gmail/Yahoo. I suspect that's fairly uncommon for users to change, and iirc all major platforms have an OS-supplied default mail program that will be invoked by default, so this shouldn't be an issue for most users.

Comment 9

[Alex Gibson [:agibson]]

(In reply to Justin Dolske [:Dolske] from comment #8)
> However I sometimes seem to be able to get things into a state where I see
> UITour.notify() being called from chrome, but the content message listener
> isn't being invoked. I _think_ the screwup is triggered by changing the
> default mailto handler to one of the built in web protocol handlers (eg
> Gmail/Yahoo). We're opening a new tab upon clicking Email Link, so I
> wouldn't be surprised if something is getting confused by that.

I can confirm when setting my default mail handler to GMail, I don't see the event being received.

> However, this seems like an E10S specific bug, and the code in Firefox 35
> isn't using this (it's directly generating content events that drive the
> tour).

I don't think this is an e10s specific bug. None of the Loop events work for me with e10s enabled in Nightly fwiw, but this is probably another bug separate to this one. I also see this particular bug in Nightly with e10s disabled.

> Is this reproducible with Firefox 35, or is it Nightly-only? (I'm out of
> time for testing tonight.)

When setting Gmail as my default, I do not receive the 'Loop:RoomURLEmailed' event in either 36.0a2 or 35.0.

Comment 10

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

The campaign owners would like to differentiate between Copy Link or Email actions in an attempt to better understand how users are interacting with Hello. This works except for the cases above. Marking this as a P3 for Hello 36.

Comment 11

[Matthew N. [:MattN]]

This should be fixed by bug 1110602.