Closed Bug 1066260 Opened 10 years ago Closed 6 years ago

[Bluetooth] Tapping 'open' on the lockscreen for a sent bluetooth file takes user to the homescreen

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::System::Lockscreen
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g-v2.1 affected, b2g-v2.2 affected)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: rpribble, Unassigned)

References

(
URL
)

Details

(Whiteboard: [2.1-flame-test-run-2]) 

Description:
If the user taps the 'open' option on a notification on the lockscreen for an outgoing bluetooth file transfer having been completed, they will be taken to the homescreen. This is irrelevant to the notification. If the user taps open on any other notification such as a received text or bluetooth transfer, they are taken to the file that was transferred. 

Repro Steps:
1) Update a Flame device to BuildID: 20140908000204
2) Pair the DUT with a second device over bluetooth
3) Send a file from the DUT to the second device through bluetooth and lock the DUT
4) Accept the transfer on the second device
5) When the notification of a succesful transfer appear on the lockscreen of the DUT, tap it, then tap the 'open' button that appears on the right
  
Actual:
The 'open' button on the lockscreen for a succesful outgoing bluetooth file transfer has no relevant result.

Expected: 
I'm not sure, but why would I need it to just drop me at the homescreen? Maybe the user is taken to the notifications pull-down menu to see the status bar showing 'File sent'?
  
Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20140908000204
Gaia: a8e4d26555e5713ec6c72270cfd0cfabc096a0d3
Gecko: 746f24f9d21d
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
  
Notes:
  
Repro frequency: 100%
See attached: Video, logcat
Rachel - Can you needinfo your lead & flag QAnalyst-Triage?
Flags: needinfo?(rpribble)
Lead was not yet NIed due to branch checks being completed.

--------------------------------------------------------------
This issue also occurs on the Flame v2.2, Open_C v2.2, and Open_C v2.1.

Device: Flame Master (319mb)
BuildID: 20140910040203
Gaia: 8e02f689b0fc39cb6ccdc22d02ed7e219c58faa7
Gecko: 152ef25e89ae
Version: 35.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Open_C Master
BuildID: 20140910040203
Gaia: 8e02f689b0fc39cb6ccdc22d02ed7e219c58faa7
Gecko: 152ef25e89ae
Version: 35.0a1 (Master) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Open_C 2.1
BuildID: 20140910000202
Gaia: 79dc972d637ff5ef7667b231e93118b4ed83ba9c
Gecko: 0890010015a2
Version: 34.0a2 (2.1) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

The 'open' button on the lockscreen for a succesful outgoing bluetooth file transfer has no relevant result.
----------------------------------------

This issue does not occur on the Flame v2.0, Flame v1.4, Open_C v2.0, and Open_C v1.4.

Device: Flame 2.0 (319mb)
BuildID: 20140910000203
Gaia: 3f4c635106c5364228782d12b1cb76b0c105b971
Gecko: 02a5b9234c13
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 1.4 (319mb)
BuildID: 20140910000204
Gaia: 6018a1c18f0c3eab25aac2ba3064904740591dd2
Gecko: 90e68c490bf9
Version: 30.0 (1.4) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Device: Open_C 2.0
BuildID: 20140910000203
Gaia: 3f4c635106c5364228782d12b1cb76b0c105b971
Gecko: 02a5b9234c13
Version: 32.0 (2.0)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Open_C 1.4
BuildID: 20140910000204
Gaia: 6018a1c18f0c3eab25aac2ba3064904740591dd2
Gecko: 90e68c490bf9
Version: 30.0 (1.4) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

There is no 'open' button on the notifications on the lock screen.

-----------------------------------------

Unable to grab a logcat through Eclipse with USB enabled due to needing to navigate through gallery.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.2: --- → affected
Flags: needinfo?(rpribble) → needinfo?(ktucker)
[Blocking Requested - why for this release]:

This is a new feature and the user would expect to be taken to the file that was transferred over so nominating to block on this.
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Component: Gaia::Bluetooth File Transfer → Gaia::System::Lockscreen
Flags: needinfo?(ktucker)
Triage: feature not a blocker. Hi Rob, Jenny, can you provide answer to what's the expected UX behavior here? Thanks.
blocking-b2g: 2.1? → backlog
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jelee)
(In reply to howie [:howie] from comment #4)
> Triage: feature not a blocker. Hi Rob, Jenny, can you provide answer to
> what's the expected UX behavior here? Thanks.

This doesn't really read off to me like a feature - it looks like a bug in a new feature. To me, this reads off as wrong behavior - we're exposing an operation to the user to allow them open a file transferred to the user, but clicking it does nothing. On that regard, this seems like a broken new feature bug to me, which would block to either fix this to do the right behavior or remove the UX to ensure there's no functionality exposed that does nothing.
Flags: needinfo?(hochang)
Hi John...

Is it possible to not show the "open" command for notifications that are not actionable? 

- Rob
Flags: needinfo?(rmacdonald) → needinfo?(jlu)
Hi Rob,

It's Greg who is responsible for actionable notifications. Forwarding your request to him.
Flags: needinfo?(jlu) → needinfo?(gweng)
I need to check this with Bruce and Tim. Since this is not in the original spec, and it now perform the same behavior with the utility tray version, at least this is what I heard from Ian, the major developer of Gaia Bluetooth.
Flags: needinfo?(timdream)
Flags: needinfo?(gweng)
Flags: needinfo?(bhuang)
(In reply to Jason Smith [:jsmith] from comment #5)
> (In reply to howie [:howie] from comment #4)
> > Triage: feature not a blocker. Hi Rob, Jenny, can you provide answer to
> > what's the expected UX behavior here? Thanks.
> 
> This doesn't really read off to me like a feature - it looks like a bug in a
> new feature. To me, this reads off as wrong behavior - we're exposing an
> operation to the user to allow them open a file transferred to the user, but
> clicking it does nothing. On that regard, this seems like a broken new
> feature bug to me, which would block to either fix this to do the right
> behavior or remove the UX to ensure there's no functionality exposed that
> does nothing.

Here is the longer version of the discussion during triage: 

The code work as expected; the tap on utility tray of the notification does nothing except making the utility tray close and clear the notification. Replace "utility tray" from the previous sentence to "lock screen" you get what we have right now.

I can't find anything in the triage guideline [1] that could classify this bug as a blocker. I therefore classified this bug as a (late-)feature previously didn't covered in any spec. We can always uplift a feature to release branches with approval.

[1] https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #8)
> I need to check this with Bruce and Tim. Since this is not in the original
> spec, and it now perform the same behavior with the utility tray version, at
> least this is what I heard from Ian, the major developer of Gaia Bluetooth.

Greg, comment 6 is a technical question, and I believe the answer depends on whether or not we could differentiate this type of inactionable notification in lock screen module. You don't really need anything for me, nor Bruce.

If what Rob suggests is doable and Jenny agrees, we can do it -- but again, not as a blocker.
Flags: needinfo?(timdream)
Flags: needinfo?(hochang)
Flags: needinfo?(bhuang)
OK. But I think it's better to update spec to contain these adjustments.
Hi Howie, I believe this issue is not covered by Settings. So I'm clearing myself, thanks!
Flags: needinfo?(jelee)
[Blocking Requested - why for this release]:

(In reply to Tim Guan-tin Chien [:timdream] (OOO ~Sep 19) (MoCo-TPE) (please ni?) from comment #9)
> (In reply to Jason Smith [:jsmith] from comment #5)
> > (In reply to howie [:howie] from comment #4)
> > > Triage: feature not a blocker. Hi Rob, Jenny, can you provide answer to
> > > what's the expected UX behavior here? Thanks.
> > 
> > This doesn't really read off to me like a feature - it looks like a bug in a
> > new feature. To me, this reads off as wrong behavior - we're exposing an
> > operation to the user to allow them open a file transferred to the user, but
> > clicking it does nothing. On that regard, this seems like a broken new
> > feature bug to me, which would block to either fix this to do the right
> > behavior or remove the UX to ensure there's no functionality exposed that
> > does nothing.
> 
> Here is the longer version of the discussion during triage: 
> 
> The code work as expected; the tap on utility tray of the notification does
> nothing except making the utility tray close and clear the notification.
> Replace "utility tray" from the previous sentence to "lock screen" you get
> what we have right now.

Not necessarily. In the notification tray case, the notification doesn't say anything to the user about the fact that the notification can be opened. In the lockscreen notification tray case, it does indicate that the notification can be opened, but doesn't do what the user expects it to do. This is broken UX exposed to a user and if it isn't going to be supported, should be removed. We will have a partner complain in partner testing about broken exposed UX, so we need this removed.

> 
> I can't find anything in the triage guideline [1] that could classify this
> bug as a blocker. I therefore classified this bug as a (late-)feature
> previously didn't covered in any spec. We can always uplift a feature to
> release branches with approval.
> 
> [1] https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines

It's exposing broken UX that doesn't do anything. We should block on removing the UX, as this is confusing as it stands to a user.

> 
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #8)
> > I need to check this with Bruce and Tim. Since this is not in the original
> > spec, and it now perform the same behavior with the utility tray version, at
> > least this is what I heard from Ian, the major developer of Gaia Bluetooth.
> 
> Greg, comment 6 is a technical question, and I believe the answer depends on
> whether or not we could differentiate this type of inactionable notification
> in lock screen module. You don't really need anything for me, nor Bruce.
> 
> If what Rob suggests is doable and Jenny agrees, we can do it -- but again,
> not as a blocker.

I don't agree. We do not ship software that clearly exposes a broken button to a user that doesn't do what the user expects it do. Our partners will complain about the fact that you are exposing an open button that doesn't open the file transferred. We need this feature removed from the implementation if it's not going to do what the user expects it do, as right now, this is exposed broken UX.
blocking-b2g: backlog → 2.1?
I agree with Jason. I think this should block. I cannot think of, nor find, any time when we have designed or knowingly shipped with actionable looking UI that doesn't actually do anything. I've looked through specs from over 18 months ago and can't find any indication that we've ever had acceptable UX or a pattern for interface elements that do nothing but are clickable. That = broken and the broken UX, as Jason suggests, should be removed.
I think the fundamental issue here is that there has never been a design for non-actionable notifications...  or consideration of whether we should even have non-actionable notifications. My preliminary thoughts are that we should either find something to link to, or use an alternate pattern to notify the user. I will raise this with the UX frameworks team but this is obviously too late for 2.1.

The short term fix would be to remove the "open" button from the UI for non-actionable notifications. I've asked Maria to update the spec and she'll post the link here when it's available. Definitely agree with Jason and Steph that we would not want to ship it in its current state for 2.1.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Correction. Reviewing the spec with Maria, I realized there was a reference to non-actionable notifications on page 4 of the version 1.1 spec. It states, "Notifications that are not actionable do not highlight upon tap." The earlier 1.1 version of the spec is available on box at https://mozilla.box.com/s/pp885wu1sbnq2mm14bi4.

That said, Maria has already added a second page to the spec that illustrates the non-actionable scenario as discussed and will post it to box and this bug shortly. 

NI'ing Jason as an FYI.
Flags: needinfo?(jsmith)
Here is the link to the updated spec https://mozilla.box.com/s/gsklu2bl6ii98sbn8bsk. Let me know if you have any questions.
Okay - thanks for the information.
Flags: needinfo?(jsmith)
Greg, can we differentiate this type of inactionable notification in the lock screen notification handling?
Flags: needinfo?(gweng)
According to the result I asked Alive, NO. From Gaia side there is no way to know whether the notification has been hooked with a callback to do something or not before it has been invoked (clicked), if this is what you NI me. My suggestion is turn BT notification to the existing 'fake' notification like the file transferring progress or OTA notification. In this way, we can know it's a different *notification* from the ordinary notification fired by Gecko.
Flags: needinfo?(gweng)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #19)
> According to the result I asked Alive, NO. From Gaia side there is no way to
> know whether the notification has been hooked with a callback to do
> something or not before it has been invoked (clicked), if this is what you
> NI me. My suggestion is turn BT notification to the existing 'fake'
> notification like the file transferring progress or OTA notification. In
> this way, we can know it's a different *notification* from the ordinary
> notification fired by Gecko.

Oh, I thought the BT notifications is already a fake notification. Let's do what you suggest here then. Thanks.
Another to do this is to expand our notification path, like to design a tag for sender to attach, like 'no-action', and then in LockScreen or UtilityTray we can identify this without Gecko's help. But, I think this is really tricky and only work for our own app. If 3rd party app (or even our partner's certified app, not controlled by us) can send notification and it should show nothing, the problem would occur again.
Discussed with Ian. NI to let him reply.
Flags: needinfo?(iliu)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #21)
> Another to do this is to expand our notification path, like to design a tag
> for sender to attach, like 'no-action', and then in LockScreen or
> UtilityTray we can identify this without Gecko's help. But, I think this is
> really tricky and only work for our own app. If 3rd party app (or even our
> partner's certified app, not controlled by us) can send notification and it
> should show nothing, the problem would occur again.

Per offline discussion and experiment with Greg, there is no way to check that the callback function is existed or not in `notification.click`. It will need API support to provide the info. Otherwise, we only have to check the property `tag` from each notification. Since we have changed some notification code base via new Notification API(bug 1025628), we usually do `notification.close()` to cleanup notifications after a user clicked on them. I think we have to find out other way to identify non-actionable notification.
Per comment 19, the fake notification might be a solution for the uncompleted user story. But it will lose original behaviour(notification behaviour) to notify user while the file is transferred completely. Is it acceptable to do for the issue here?

I think the better solution is to have a report(information) of the file send after a user clicked on the notification. But it's should be a feature to put in the backlog since we have the ability to open actionable notification from locked screen. And we might to take care file receiving case. It will open the received file in the actionable notification.
Flags: needinfo?(iliu)
A quick sum up:
We can't tell if a notification is non-actionable, so, the new non-actionable UX spec in comment 16, page 5, can't be done in a decent way anytime soon.

If we want to solve this now, 3 proposals:
1. Fake notification: after the file transfer is done, the sender's lockscreen appears a fake notification. But the fake one does not light the screen up or actively alert user, just a static and silent passive notice shown on the screen, which makes the notification less meaningful. Also from the engineering perspective, this solution is dirty and not recommended.

2. Open an information page: when the file transfer is done, clicking "open" leads to a page to show sender some info like: what's the transferred file size, file name, transferred time...etc. This requires product/UX to define what information to be shown and what the UI looks like. Engineering recommends this solution.

Besides above ones, I'd like to propose the third:
3. Open the transferred file: when the transfer is done, clicking "open" opens the transferred file. But not sure it's meaningful for sender to open what he/she just sent. Need product/UX input here.

Let's make a decision from above options.
Flags: needinfo?(swilkes)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(msandberg)
Flags: needinfo?(bhuang)
The one concern I have with solutions [2] & [3] is that they only address the BT use case, but won't handle other notification use cases where they aren't actionable, which likely isn't going to fix the bug here. I understand the engineering concern that we can't identify a non-actionable notification, which means we need to backup and rethink the UX design for this feature in general to take into account that clicking on a notification can't be assumed to have a resulting action. The notification tray handles this use case because it doesn't give a user an indication that clicking on a notification will result in an action, which means a user doesn't have a preconceived notion that something will happen if you click the notification. Instead, they'll only learn that something will happen after clicking it, which implies that user needs to learn that there's an action associated to clicking a notification, rather than knowing about it up front. As such, I think the lockscreen notifications UX needs to be modified to not give the user the preconceived notion that clicking on the notification results in an action.

One idea - why couldn't we just remove the open button all together here? That would resolve the UX concern here I'm talking about.
Clearing multiple/redundant flags and leaving Rob's set.
Flags: needinfo?(swilkes)
Flags: needinfo?(msandberg)
I agree with jsmith's points about solution [2] and [3]. 

Having the open button on actionable notifications is a Tako requirement and committed feature so we can't remove that unfortunately. 

Do I understand correctly (per comment 19) that we can tell if a notification is actionable or not after it has been clicked? If the answer is yes it seems that this UX should work, as the open button only shows up after a user has clicked the notification.
Flags: needinfo?(rmacdonald)
(In reply to Maria Sandberg [:mushi] from comment #28)
> I agree with jsmith's points about solution [2] and [3]. 
> 
> Having the open button on actionable notifications is a Tako requirement and
> committed feature so we can't remove that unfortunately.
> 
> Do I understand correctly (per comment 19) that we can tell if a
> notification is actionable or not after it has been clicked? If the answer
> is yes it seems that this UX should work, as the open button only shows up
> after a user has clicked the notification.

I think comment 19 means that we only know if a notification is actionable or not after the open button is clicked. At that point, we're hitting the on click handler of a notification, which is when we know if something will or won't happen.
Yes. Gaia have no idea whether the notification would do something after we trigger the 'click' event, so we can't distinguish actionable and non-actionable notifications. Even so, Gaia still don't know what will happen after those 'actionable' notification being clicked. If someone write a broken notification action, like do-nothing, even we know there is an valid action with the notification, we would still have the same issue here.
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #30)
> Yes. Gaia have no idea whether the notification would do something after we
> trigger the 'click' event, so we can't distinguish actionable and
> non-actionable notifications. Even so, Gaia still don't know what will
> happen after those 'actionable' notification being clicked. If someone write
> a broken notification action, like do-nothing, even we know there is an
> valid action with the notification, we would still have the same issue here.

Random idea - can we detect if the onclick handler was set on the notification or not (something like notification.onclick === null)? If we could, then we could soften the impact here by doing something like:

1. notification.onclick === null - don't show the open
2. notification.onclick !== null - show open
(In reply to Jason Smith [:jsmith] from comment #31)
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #30)
> > Yes. Gaia have no idea whether the notification would do something after we
> > trigger the 'click' event, so we can't distinguish actionable and
> > non-actionable notifications. Even so, Gaia still don't know what will
> > happen after those 'actionable' notification being clicked. If someone write
> > a broken notification action, like do-nothing, even we know there is an
> > valid action with the notification, we would still have the same issue here.
> 
> Random idea - can we detect if the onclick handler was set on the
> notification or not (something like notification.onclick === null)? If we
> could, then we could soften the impact here by doing something like:
> 
> 1. notification.onclick === null - don't show the open
> 2. notification.onclick !== null - show open

Oh and when I say soften the impact - I mean reduce the # of use cases this problem could happen where we know the notification didn't have an onclick handler explicitly set. It won't solve the case where a dev sets notification.onclick to be a function that results in no visual changes from the user perspective (e.g. an empty JS function). IMO though, if a dev chose to do that, then it's their problem, not ours.
According to our experiments, the onclick is always there and there is no different between 'actionable' notification and 'non-actionable' notification. We connect to device and capture the screenshot notification that should be come with some actions after we click it and check the value, it's NOT NULL. And then, we make a vanilla notification via 'new Notification('title')', it apparently has no action after we clicking it, and the 'onclick' is still there, NOT NULL.

Unless we made mistakes in our experiments, the current conclusion is this doesn't work.
Sorry I reverted the result: the onclick is ALWAYS NULL, confirmed 2 mins ago.
Ehsan - See above. We're having problems coming up with a strategy to determine actionable notifications vs. non-actionable notifications in the Web Notifications API. Do you have any ideas on what we could do here on the API side of things?
Flags: needinfo?(ehsan.akhgari)
Flags: needinfo?(pdolanjski)
Jenny, based on your work with bluetooth, do you have any ideas here? (Even though it would only solve the bluetooth use case).
Flags: needinfo?(jelee)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #33)
> According to our experiments, the onclick is always there and there is no
> different between 'actionable' notification and 'non-actionable'
> notification. We connect to device and capture the screenshot notification
> that should be come with some actions after we click it and check the value,
> it's NOT NULL. And then, we make a vanilla notification via 'new
> Notification('title')', it apparently has no action after we clicking it,
> and the 'onclick' is still there, NOT NULL.
> 
> Unless we made mistakes in our experiments, the current conclusion is this
> doesn't work.

How did you test this?

When I run this code: |console.log((new Notification("title")).onclick), I get null, which is what I would expect.  But read on...

(In reply to Jason Smith [:jsmith] from comment #35)
> Ehsan - See above. We're having problems coming up with a strategy to
> determine actionable notifications vs. non-actionable notifications in the
> Web Notifications API. Do you have any ideas on what we could do here on the
> API side of things?

Reading this bug, it seems like by "actionable", you mean whether or not whether clicking the notification will cause a visible side effect on the screen.  This is impossible to detect without running the click event handler.  Also, note that checking the onclick property will *not* do the right thing if the event handler is registered using addEventListener.

That being said, I think we can solve a simpler problem.  Assuming that we count notifications that don't have any click event handler (either through the onclick attribute or addEventListener) as non-actionable, we can detect whether we're dealing with such a notification inside Gecko, and then extend AppNotificationServiceOptions with an attribute indicating whether such an event listener has been registered on the notification.  We will be able to read that attribute in the system app and decide whether to show the open button based on that.

This idea will not take us all of the way of course.  For example, if you trigger a notification which has a click event handler that doesn't do anything visible, it will still have the open button in the UI.

Does this sound good enough?
Flags: needinfo?(ehsan.akhgari)
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO on Thu/Fri) from comment #37)
> (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #33)
> > According to our experiments, the onclick is always there and there is no
> > different between 'actionable' notification and 'non-actionable'
> > notification. We connect to device and capture the screenshot notification
> > that should be come with some actions after we click it and check the value,
> > it's NOT NULL. And then, we make a vanilla notification via 'new
> > Notification('title')', it apparently has no action after we clicking it,
> > and the 'onclick' is still there, NOT NULL.
> > 
> > Unless we made mistakes in our experiments, the current conclusion is this
> > doesn't work.
> 
> How did you test this?
> 
> When I run this code: |console.log((new Notification("title")).onclick), I
> get null, which is what I would expect.  But read on...
> 
Comment 34 corrected the result as you said. Yes, it is always NULL. And, the solution is good enough to resolve this bug, I think.
blocking-b2g: 2.1? → 2.1+
Just to make sure I understand - this solution would show a open button only if there is a click event handler, correct? 

If yes, what does the click event handler do? Is this something a developer would put into their app to specify behavior on a particular notification or is it something else? Do you have an example of a case where there might be a click event handler that doesn't do anything visible? 

Apologies if these are silly questions, I'm just trying to understand what edge cases there may be so we can assess the UX implications :)
Based on comment 37, the long term solution is to modify the API behavior so that these types of notifications can be distinguished from each other.  I recommend that we open a separate bug for that.

Suggestion for a short term solution on this bug: what about changing the "Open" wording to an icon, such as an "unlock" icon?  In the end the behavior is the same, but that way it doesn’t lead the user to think that something will “Open”.  There are still consistency issues with this approach, it at least makes it match the notification behavior when dragged from the status bar, and does not imply any additional action.  The additional benefit is we remove any issues with localization, since the word “Open” leaves little room for interpretation and in certain languages may be too long to fit into that space.
This is relatively low risk and can get done in a short time if we want to address this in 2.1.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(pdolanjski)
Flags: needinfo?(msandberg)
Flags: needinfo?(bhuang)
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> from comment #40)
> Suggestion for a short term solution on this bug: what about changing the
> "Open" wording to an icon, such as an "unlock" icon?  In the end the
> behavior is the same, but that way it doesn’t lead the user to think that
> something will “Open”.  There are still consistency issues with this
> approach, it at least makes it match the notification behavior when dragged
> from the status bar, and does not imply any additional action.  The
> additional benefit is we remove any issues with localization, since the word
> “Open” leaves little room for interpretation and in certain languages may be
> too long to fit into that space.
> This is relatively low risk and can get done in a short time if we want to
> address this in 2.1.

This is an interesting suggestion for a short term solution. I'm a little worried we'd be obscuring useful functionality to soften the blow from these edge cases though. I agree that if we use an unlock icon only it wouldn't set the specific expectation that the app would open but it also removes the hint that there is functionality there at all which makes the unlock icon almost redundant. 

Have we determined there is absolutely nothing we can do in time to solve this technically?
Flags: needinfo?(msandberg)
(In reply to Maria Sandberg [:mushi] from comment #36)
> Jenny, based on your work with bluetooth, do you have any ideas here? (Even
> though it would only solve the bluetooth use case).

After discussion with Harly, due to technical limitation, for short term we think the solution Bruce proposed is most reasonable and it covers all cases. For long term, we need to be able to distinguish actionable and non-actionable notifications to provide the best UX. 

Also, in the next framework team meeting, this issue will be addressed. Thanks!
Flags: needinfo?(jelee)
(In reply to Maria Sandberg [:mushi] from comment #39)
> Just to make sure I understand - this solution would show a open button only
> if there is a click event handler, correct? 

Yes, exactly.

> If yes, what does the click event handler do? Is this something a developer
> would put into their app to specify behavior on a particular notification or
> is it something else?

It's controlled by the author of the app emitting the notification.

> Do you have an example of a case where there might be
> a click event handler that doesn't do anything visible? 

Hmm.  Not a good example, but please note that event handlers have this nice property that registering one usually doesn't have any side effects, and we're bending that rule a little bit here.  Consider for example this code:

notification.onclick = function() {
  showUI();
};

Now, consider that the developer decides that the UI doesn't work well in their v1 app, and attempts to disable it like this:

notification.onclick = function() {
  // showUI();
};

Now, the function is effectively empty, but there is an event handler registered as far as we can tell, so we would still show the open button.  I hope this helps clarify the potential issues with this solution.

Also, note that the "proper" fix for this would be for us to detect whether the app is going to do something visible on the screen, but that solution is only the ideal solution, one which we cannot implement in reality, so we need to settle for something that works well in most cases, but not in all.

> Apologies if these are silly questions, I'm just trying to understand what
> edge cases there may be so we can assess the UX implications :)

There are no silly questions.  :-)  If anything else is unclear, please feel free to ask!
(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> from comment #40)
> Based on comment 37, the long term solution is to modify the API behavior so
> that these types of notifications can be distinguished from each other.  I
> recommend that we open a separate bug for that.
> 
> Suggestion for a short term solution on this bug: what about changing the
> "Open" wording to an icon, such as an "unlock" icon?  In the end the
> behavior is the same, but that way it doesn’t lead the user to think that
> something will “Open”.  There are still consistency issues with this
> approach, it at least makes it match the notification behavior when dragged
> from the status bar, and does not imply any additional action.  The
> additional benefit is we remove any issues with localization, since the word
> “Open” leaves little room for interpretation and in certain languages may be
> too long to fit into that space.
> This is relatively low risk and can get done in a short time if we want to
> address this in 2.1.

FWIW I think the solution in comment 37 (at least the Gecko side of it) is pretty simple and very low risk, so unless there are engineering time concerns and the like, I suggest just implementing that right now.  But if that won't work because of timing/resourcing issues, moving that to a separate bug seems fine.
Thanks for the clarifications in comment 43 Ehsan, that helped a lot! 

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #44)
> FWIW I think the solution in comment 37 (at least the Gecko side of it) is
> pretty simple and very low risk, so unless there are engineering time
> concerns and the like, I suggest just implementing that right now.  But if
> that won't work because of timing/resourcing issues, moving that to a
> separate bug seems fine.

Implementing this would definitely be the best path from a UX perspective, even though I understand we may get "false positives" with the open button in some cases.
The unlock icon was just an example, I know it's not easy to think of an icon that is able to clearly indicate an action while at the same time obscuring what the action will be.  If there is something that can achieve that effect I still believe it's something we should work on, since short text on a small button is usually prone to string truncation during translation.  With the API solution in place we would then also be covered from those false positives.
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #37)
> This idea will not take us all of the way of course.  For example, if you
> trigger a notification which has a click event handler that doesn't do
> anything visible, it will still have the open button in the UI.

I don't think comment 37 is the ideal solution based on your comment above. I also don't think we are following normal Web API design pattern by having the UA behaves differently based on the existence of a event listener (onbeforeunload is probably the only "exception"). I could be wrong though.

Based on above, I still recommend we stick to replacing "open" label to an unlock icon or "unlock" label as the 2.1+ solution. Please understand that 2.1 is going FC in 2 weeks.
Flags: needinfo?(ehsan.akhgari)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #47)
> (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> comment #37)
> > This idea will not take us all of the way of course.  For example, if you
> > trigger a notification which has a click event handler that doesn't do
> > anything visible, it will still have the open button in the UI.
> 
> I don't think comment 37 is the ideal solution based on your comment above.

I explicitly said that it isn't.  I also said that an ideal solution is not attainable.

> I also don't think we are following normal Web API design pattern by having
> the UA behaves differently based on the existence of a event listener
> (onbeforeunload is probably the only "exception"). I could be wrong though.

You're right.  I explicit called that out as well in comment 43.

> Based on above, I still recommend we stick to replacing "open" label to an
> unlock icon or "unlock" label as the 2.1+ solution. Please understand that
> 2.1 is going FC in 2 weeks.

As I said in comment 44, if we don't have enough time we can do something else here.  I leave that decision to you and others.
Flags: needinfo?(ehsan.akhgari)
Is this a final call that we are not able to better the experience with a technical solution? If that final call has been made UX will provide a final recommendation on how to deal with the UX assuming there will be no technical change.
Flags: needinfo?(rmacdonald)
(In reply to Maria Sandberg [:mushi] from comment #49)
> Is this a final call that we are not able to better the experience with a
> technical solution? If that final call has been made UX will provide a final
> recommendation on how to deal with the UX assuming there will be no
> technical change.

I don't know.  Tim?
Flags: needinfo?(timdream)
I think so, since it's not technically address issues mentioned in comment 48.
Flags: needinfo?(timdream)
... not technically *complete on* addressing issues ...
Okay, thanks! 

I've spoken with Rob about this and we agree that we should keep the UX as described in the spec available here: https://mozilla.box.com/s/gsklu2bl6ii98sbn8bsk

Since we can't tell the difference between actionable and non-actionable notifications in this release that will effectively mean that tapping any notification from the home screen will display an open button. We think that it's worth keeping the functionality clear to the user even though it will cause a sub-optimal experience for this particular bluetooth notification. We believe the bluetooth case will be rare and that the benefit of having actionable notifications for more common cases like messaging and dialer outweighs  this problem. 

Let me know if you have any questions!
Remove blocking status per comment above.

Maria, should I close this bug as WONTFIX too? Should this behavior be addressed eventually or we should stop worry about it and accept it as a fact?
blocking-b2g: 2.1+ → ---
Flags: needinfo?(msandberg)
Hi Tim,

We should address this behavior eventually because there may be other edge cases like this that comes up. I understand we don't have time to implement a technical solution to this in 2.1 so let's try and solve it in the next release.

Thanks!
Flags: needinfo?(msandberg)
Greg, do you know any other use case for notification where the notification is not actionable? If Bluetooth is the only case, let throw this bug to Gaia::Bluetooth and work ask for a updated spec on it's action from lock screen.

(Also, remove the part of spec added for this bug on "if a notification is not actionable ...")
Flags: needinfo?(gweng)
So far we have two cases that are not actionable:

1. Bluetooth sender completing notification, as this bug described
2. Error while taking screenshot is impossible

But since 2. is rare, or for user it seems like an edge case, I think 1. is the major issue as you described.
Flags: needinfo?(gweng)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.