929895 - [WAP push] [CP] Read one of multiple received WAP push message will remove/close rest of messages from utility tray.

Status: VERIFIED FIXED

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

Description

[Enpei]

Attachment: time stamp: 15:04.

When multiple wap push message have been received, read any one of it will remove others from notification bar which unable to read them.

* Build Number                
Buri
Gaia:     00d5964eabf95a6a8a632420dfa36fc76dcbc9b7
Gecko:    http://hg.mozilla.org/releases/mozilla-aurora/rev/7453a764f9a9
BuildID   20131022004000
Version   26.0a2

* Reproduce Steps
1. Send more than 1 WAP push message to DUT.
2. Open one of it.

* Expected Result
Another won't be closed and can be opened as well.

* Actual Result
Another message will be removed from utility tray.

* Occurrence rate

Comment 1

[Enpei]

Attachment: video

Comment 2

[Jason Smith [:jsmith]]

This is likely the same general problem with the fact that we can't persist notifications once the app is open. Probably a dupe of one of those same bugs.

Comment 3

[Enpei]

(In reply to Jason Smith [:jsmith] from comment #2)
> This is likely the same general problem with the fact that we can't persist
> notifications once the app is open. Probably a dupe of one of those same
> bugs.

You mean general problem occurred recently? At least no such problem when I filed bug 924808 on 10/09.

Comment 4

[Gabriele Svelto [:gsvelto]]

Weird, I think I had actually fixed this. I'll re-check it and see if I can reproduce it.

Comment 5

[Gabriele Svelto [:gsvelto]]

I've just re-tested and I can reproduce this. It seems that after the app is opened I get notification-closed events for the notifications that have not been clicked and once that happens they disappear from the utility tray.

(In reply to Jason Smith [:jsmith] from comment #2)
> This is likely the same general problem with the fact that we can't persist
> notifications once the app is open. Probably a dupe of one of those same
> bugs.

That sounds like it, I've tried the same with the SMS app and I get the same behavior. Is there a bug for tracking this or is this intended behavior?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)
> I've just re-tested and I can reproduce this. It seems that after the app is
> opened I get notification-closed events for the notifications that have not
> been clicked and once that happens they disappear from the utility tray.
> 
> (In reply to Jason Smith [:jsmith] from comment #2)
> > This is likely the same general problem with the fact that we can't persist
> > notifications once the app is open. Probably a dupe of one of those same
> > bugs.
> 
> That sounds like it, I've tried the same with the SMS app and I get the same
> behavior. Is there a bug for tracking this or is this intended behavior?

https://bugzilla.mozilla.org/show_bug.cgi?id=890440 - it's definitely a bug, but the earliest we can look into fixing this is in the 1.3 timeframe.

(In reply to Enpei from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > This is likely the same general problem with the fact that we can't persist
> > notifications once the app is open. Probably a dupe of one of those same
> > bugs.
> 
> You mean general problem occurred recently? At least no such problem when I
> filed bug 924808 on 10/09.

Ah okay. Then it's probably unrelated to the general problem cited in bug 890440.

Comment 7

[Gabriele Svelto [:gsvelto]]

(In reply to Jason Smith [:jsmith] from comment #6)
> https://bugzilla.mozilla.org/show_bug.cgi?id=890440 - it's definitely a bug,
> but the earliest we can look into fixing this is in the 1.3 timeframe.

After reading that bug this sounds exactly like a duplicate; the behavior I'm observing is exactly the same as what :julienw describes in that bug. There's almost nothing we can do in the WAP Push app... The only workaround that comes to mind is to re-send notifications from the app when it's notified about the previous ones being closed. However that would be very kludge-y as the user would see the notification bar pop up again as if new messages had been received.

Comment 8

[Preeti Raghunath(:Preeti)]

Hi Gabriele,

What is the work around for the 2 bugs - 929895 and https://bugzilla.mozilla.org/show_bug.cgi?id=924808

Comment 9

[Gabriele Svelto [:gsvelto]]

(In reply to Preeti Raghunath(:Preeti) from comment #8)
> What is the work around for the 2 bugs - 929895 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=924808

Bug 924808 was already fixed before we hit this problem, if we solve this we can close that one too. I can put together a work-around for this one as described in comment 7 but it's kludge so I'll do it only if it's absolutely necessary.

Comment 10

[Preeti Raghunath(:Preeti)]

David,

Please check

Comment 11

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Re-send non-read notification as a workaround for bug 890440

The issue with this bug is that if more than one WAP push message is received and shown in the notification bar then opening one will effectively make the others disappear. The user won't have any chance of reading them as the notifications are gone.

This patch implements a VERY UGLY HACK to work around this problem. The hack here involves re-sending the notifications that were discarded so that the user can still click them. It has two major drawbacks though:

- First of all the user will see new notifications pop up while opening a WAP Push message if others are present but these notifications are nothing new, just a side-effect of re-posting them

- I'm not completely sure that this works properly anyway, it seems to work but being hackish it's probably a very fragile approach

Comment 12

[Julien Wajsberg [:julienw]]

Comment on attachment 823493 [details] [diff] [review]
[PATCH] Re-send non-read notification as a workaround for bug 890440

wow, this is actually ugly.

I'm wondering if the less ugly solution could be to special-case the wappush app in the system app instead. Still ugly, and we can argue it's uglier because it's in the system app, but we wouldn't have the notification toaster.

Comment 13

[Julien Wajsberg [:julienw]]

Alive, could you please comment on comment 12 (context is comment 11)? Thanks!

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

Julien, I think it's your commit to let that happen :)

https://github.com/mozilla-b2g/gaia/commit/7cec8abf54f661238ba4d4765e53f61485f54643

So we're closing all the notifications when an app is brought to foreground.
If we want to fix this we should do only clear the notification but not all notifications belong to the app.

I'm a little confused by the current implementation way.

Comment 15

[Julien Wajsberg [:julienw]]

Hey Alive,

The current implementation was done as a workaround for 1.1, because we had the old Notification API with no way to control a notification once it was sent.

Bug 890440 is especially to remove those workarounds, but we can't do this unless we also do bug 855165, otherwise we'll see the old bugs come back.

That's why I was suggesting to add an ugly hack to _not_ remove the notifications for the wappush app when we open this application. This ugly hack would disappear once bug 890440 is fixed of course.

I don't see other good solutions right now, but I'm definitely open to other ideas!

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> That's why I was suggesting to add an ugly hack to _not_ remove the
> notifications for the wappush app when we open this application. This ugly
> hack would disappear once bug 890440 is fixed of course.

The only thing I suspect is how do you distinguish WAPPUSH app with others...(hardcode app manifestURL?)
But as you said, I'm O.K. to do this sad change.

> 
> I don't see other good solutions right now, but I'm definitely open to other
> ideas!

I'm not that familiar with new Notification API, so I don't have better ideas now.
BTW I have a proposal to move mozChromeEvent of notifications into mozBrowser events so we|system could launch the app while the corresponding notifications are clicked, and we could use the same logic as window.prompt to send message back to the app to let it know the message is read/cleared by the user. Don't know if this helps..

Comment 17

[Julien Wajsberg [:julienw]]

Maybe one idea could be to:
* keep the workaround behaviour when a notification was sent using the old API
* remove the workaround behaviour when a notification was sent using the new API

Currently, we don't know in the System app if a notification was sent with the new or the old API.

Also, thinking this more, most apps are using NotificationHelper, which uses the old API. But some apps are using the new API directly (especially email), so this might be a good way forward. But this may be more code than what we're willing to do for a transition period...

Comment 18

[Julien Wajsberg [:julienw]]

Also NI Kyle who implemented the new notification API in the system app IIRC.

Comment 19

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

(In reply to Julien Wajsberg [:julienw] from comment #17)
> Maybe one idea could be to:
> * keep the workaround behaviour when a notification was sent using the old
> API
> * remove the workaround behaviour when a notification was sent using the new
> API
> 
> Currently, we don't know in the System app if a notification was sent with
> the new or the old API.

So there's nothing saying we couldn't move NotificationHelper to the new API too, since it's fairly transparent. Or just create a bug to sweep through and change NotificationHelper calls to the new API, last time I checked (oslo) there weren't THAT many.

Comment 20

[Julien Wajsberg [:julienw]]

My idea in comment 17 was actually not migrating the app until they're ready to manage their own notification.

We should probably still remove the tapped notification though, so maybe most apps would have nothing to do.

Comment 21

[Julien Wajsberg [:julienw]]

Currently thinking if we actually should remove the tapped notification. Let's say an app (email, sms) would generate "merged" notification, eg "3 unread messages". I think Email's developers wouldn't want to remove it, rather would want to replace the notification with a new one with updated text whenever the user reads this message.

Flagging Email's developer to get their feedback.

Comment 22

[Andrew Sutherland [:asuth] (he/him)]

:jrburke channeling UX has the final word for e-mail (and responsiblity to check ;), but I think Julien's proposal makes sense in general (and for the messages app).  If we have multiple notifications in e-mail then they are for multiple accounts, and having the system make the decision to clear them all when we show only a single account's messages is not terribly helpful.  Having said that, I think our e-mail UX spec might currently call for the e-mail app to clear the notifications when we get focus, but I do think it's appropriate for the e-mail app itself to decide to do that.  (I personally would want the e-mail app to only clear the notifications if I entered the inbox in question.)

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

Makes sense to me if you have a long term plan filed later.

(In reply to Julien Wajsberg [:julienw] from comment #17)
> Maybe one idea could be to:
> * keep the workaround behaviour when a notification was sent using the old
> API
> * remove the workaround behaviour when a notification was sent using the new
> API
> 
> Currently, we don't know in the System app if a notification was sent with
> the new or the old API.
> 
> Also, thinking this more, most apps are using NotificationHelper, which uses
> the old API. But some apps are using the new API directly (especially
> email), so this might be a good way forward. But this may be more code than
> what we're willing to do for a transition period...

Comment 24

[Gabriele Svelto [:gsvelto]]

Quick question, if I migrate WAP Push to the new API would the problem go away? Or would that also need modifications in the system app?

Comment 26

[Julien Wajsberg [:julienw]]

Gabriele: currently the system app does not distinguish between both APIs.

Andrew, James: and do you think it's appropriate if the system app removes only the notification that has been "activated" (touched, clicked) by the user? I think that now the app should control it instead of letting the system app do it (again, only if the app uses the new Notifiation API), but it may be too much work for this common case. What's your call?

Comment 27

[Julien Wajsberg [:julienw]]

Andrew, see previous comment. (forgot to put the flag...)

Comment 28

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Julien Wajsberg [:julienw] from comment #26)
> Andrew, James: and do you think it's appropriate if the system app removes
> only the notification that has been "activated" (touched, clicked) by the
> user? I think that now the app should control it instead of letting the
> system app do it (again, only if the app uses the new Notifiation API), but
> it may be too much work for this common case. What's your call?

Yes, I think it's appropriate if the system app removes only the notification that has been touched/clicked by the user.

Comment 29

[James Burke [:jrburke]]

Yes, I prefer system to remove just ones that are clicked. If the email app determines others should be closed, those will closed by the email app using the Notification.get() API. The bug related to that work is bug 915643, which we want to land for 1.3, since Notification.get() is in 1.3.

Comment 30

[Julien Wajsberg [:julienw]]

My problem is the following one:

* say we want to merge notifications instead of having 1 notification per mail. So we would have "email: you got 3 notifications"
* 2 ways of doing this: 
  + either email send 3 notifications, and the system app merges them, allowing the user to show them all if eg he taps the merged notification. Then we can probably do what you're suggesting.
  + either the email app replaces the existing notification. Advantage: we won't have a generic text ("<app>: you got <n> notifications") but you can have more functional text ("You have <n> unread mails in your mailbox"). In this case, we probably don't want that the system app removes this notification when the user taps it, rather we want that the email app replaces this notification with "You have <n - 1> unread mails" once the user reads one of them.


See what I mean? Am I overthinking?

To me, the last solution is the best one, but it's also the one giving the most work. Another way is that we could stick to the first solution for the time being (without the merge thing furst, with the merge thing then, UX can decide), and switch to the second solution in a future release.

Comment 31

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Julien Wajsberg [:julienw] from comment #30)
>   + either email send 3 notifications, and the system app merges them,
> allowing the user to show them all if eg he taps the merged notification.
> Then we can probably do what you're suggesting.

This would be inventing new semantics for the notification API, especially since it has l10n/string issues as you allude to below and could require new data arguments.  This would need to be done at a standards level.

There was some discussion of something like this on the dev-webapi list; see https://groups.google.com/d/msg/mozilla.dev.webapi/vxfl3yNW4x0/pph2EEVRIO0J fourth quoted block down.

(In general there is the problem that the standard was really designed for ephemeral growl-style notifications that disappear, but we are using them for persistent notifications.  That gets touched on in some of the various mailing list discussions.)

>   + either the email app replaces the existing notification.

This is what the e-mail app wants / already does.  We use tags so that there should only ever be one notification per account.


> See what I mean? Am I overthinking?

I think dealing with the 'too many notifications' case is important.  Based on the spec, I think the system app should simply have an arbitrary upper-bound on the number of persistent notifications that will hang around per-app.  The system app should arbitrarily close them to keep the app under the limit.  Assuming the notification still generates the animation stuff as it happens/gets enqueued, the implementation should still be compliant with the standard.

I do think we can do a lot more to improve the notification spec, but that should be done on the WHATWG or W3C lists, etc.

Comment 32

[James Burke [:jrburke]]

As :asuth mentions, the email app uses the "tag" capability to make sure there is only ever one notification per email account shown. Once bug 915643 and its dependencies are fixed, then notification state should be updated correctly by the email app by using the Notification.get() API.

If the system app wanted to do something fancier with grouping messages or controlling notifications, the first part of that may be exposing a settings pane that allows setting per-app notification settings, and part of that could be a "only ever show one notification for this app" if that made sense.

Comment 33

[(inactive after 6/18) Alive Kuo [:alive]]

Transfer to Gregor to find someone from system frontend team to involve this since I was really occupied now ;)

Comment 34

[Gregor Wagner [:gwagner]]

Gabriele, are you still working on this?

Comment 35

[Gabriele Svelto [:gsvelto]]

(In reply to Gregor Wagner [:gwagner] from comment #34)
> Gabriele, are you still working on this?

Right now I'm not as I still have some other koi+ bugs in my backlog. If you want to take it feel free to do it as I probably won't have time for this until next week.

Comment 36

[:gerard-majax]

Taking, I can reproduce also with other apps, as reported in other comments. We will provide a workaround for this for v1.2.

Comment 37

[Julien Wajsberg [:julienw]]

Of course you can reproduce, this was the expected behavior...

Following comment 32, I think the system app should never touch (remove) any notification sent by the new API, but still do the old behaviour with the notifications sent by the old API.

That means you need a way to mark the notifications depending whether they were sent by the old or the new API.

Could be done in bug 890440...

Comment 38

[:gerard-majax]

After trying to dig up into all of this, I could understand finally that until a couple of weeks ago this was working correctly.

I did notice that bug 905116 modified the way we handle stuff around this behavior. More specifically, the change listen against 'appforeground' instead of 'foreground'. I don't understand the scope of this modification.

Comment 39

[:gerard-majax]

(In reply to Julien Wajsberg [:julienw] from comment #37)
> Of course you can reproduce, this was the expected behavior...
> 
> Following comment 32, I think the system app should never touch (remove) any
> notification sent by the new API, but still do the old behaviour with the
> notifications sent by the old API.
> 
> That means you need a way to mark the notifications depending whether they
> were sent by the old or the new API.
> 
> Could be done in bug 890440...

Reading the code in Gecko, more precisely https://mxr.mozilla.org/mozilla-central/source/b2g/components/AlertsService.js#70 it seems that the aDetails.id value is provided by the new API but not by the old API. This could be a way to distinguish between the old and the new API and set a boolean in the message that is sent.

However, I have a hard time understanding how distinguishing between both would help to fix the present bug.

Comment 40

[:gerard-majax]

The 'appforeground' event is triggered when the application is becoming foreground again, i.e., it is not triggered when the application is launched, but it will be when you use the task switcher. When this event happens, then we wipe all notifications from the application that are still here.

Comment 41

[:gerard-majax]

We might mitigate this for koi by maybe blacklisting the apps for which we don't want the behavior, since it seems the proper fix is just too late for this release and that we would fix it in v1.3.

Comment 42

[Julien Wajsberg [:julienw]]

(In reply to Alexandre LISSY :gerard-majax from comment #40)
> The 'appforeground' event is triggered when the application is becoming
> foreground again, i.e., it is not triggered when the application is
> launched, but it will be when you use the task switcher. When this event
> happens, then we wipe all notifications from the application that are still
> here.

This is actually strange. The intended behavior was that we wanted to remove all notifications for the displayed app, in all the following cases:
* it was launched
* it was displayed (using the task switcher or tapping the icon again)
* it was already displayed and the user goes out of the lockscreen

Please see bug 824549 and bug 868816 for history.

(In reply to Alexandre LISSY :gerard-majax from comment #39)
> 
> However, I have a hard time understanding how distinguishing between both
> would help to fix the present bug.

The old Notification API, currently used by all the apps except Email (AFAIK), only lets notifications to be sent, and that's all. Therefore, it makes sense to let the System app do some manipulations on these notifications.

The new W3C-compliant Notification API, used by Email only currently AFAIK, lets the application control a sent notification: close or replace it. That's why it makes sense that the System app does not touch these notifications.

Once Bug 890440 implements this, this bug will be about moving from the old Notification API to the new Notification API for the Wap Push App (this can be started now if everyone agrees this solutions is good).

Does that make better sense now?


That said, I agree with blacklisting the necessary apps for v1.2 (alive was ok with this too, see comment 16). I don't know if Email needs it for now, or if it can wait the full change in 1.3. Flagging James for providing an answer to this question.

Comment 43

[James Burke [:jrburke]]

For email in 1.2, it is fine to continue to remove all email notifications using the existing system implementation, no special allowances for it, besides the existing one around screen wake for email notifications. 

For email, with the "tag" grouping, there is only ever one notification per account visible, and it seems likely that the majority of email use cases are just one email account configured, so it is just one notification in play.

For 1.3, the expectation from the email app is that:

* Notification.get() is available, so email can close notifications it feels are no longer necessary.
* Only notifications that are activated (tapped) by the user are removed by system app, or if the user chooses to Clear All notifications, or swipes the notification to close it.
* Ideally the app is not opened if the notification was closed (not activated) if the app did not bind an onclose handler.

Asking :arog to confirm as he is product, but that is my understanding.

Comment 44

[:gerard-majax]

(In reply to Julien Wajsberg [:julienw] from comment #42)
> (In reply to Alexandre LISSY :gerard-majax from comment #40)
> > The 'appforeground' event is triggered when the application is becoming
> > foreground again, i.e., it is not triggered when the application is
> > launched, but it will be when you use the task switcher. When this event
> > happens, then we wipe all notifications from the application that are still
> > here.
> 
> This is actually strange. The intended behavior was that we wanted to remove
> all notifications for the displayed app, in all the following cases:
> * it was launched
> * it was displayed (using the task switcher or tapping the icon again)
> * it was already displayed and the user goes out of the lockscreen
> 
> Please see bug 824549 and bug 868816 for history.
> 
> (In reply to Alexandre LISSY :gerard-majax from comment #39)
> > 
> > However, I have a hard time understanding how distinguishing between both
> > would help to fix the present bug.
> 
> The old Notification API, currently used by all the apps except Email
> (AFAIK), only lets notifications to be sent, and that's all. Therefore, it
> makes sense to let the System app do some manipulations on these
> notifications.
> 
> The new W3C-compliant Notification API, used by Email only currently AFAIK,
> lets the application control a sent notification: close or replace it.
> That's why it makes sense that the System app does not touch these
> notifications.
> 
> Once Bug 890440 implements this, this bug will be about moving from the old
> Notification API to the new Notification API for the Wap Push App (this can
> be started now if everyone agrees this solutions is good).
> 
> Does that make better sense now?

I think it does, you just confirmed the thing I was not sure about: this implies that we have to enable the use of the new API for WAPPush and others, which is out of the scope of koi.

> 
> 
> That said, I agree with blacklisting the necessary apps for v1.2 (alive was
> ok with this too, see comment 16). I don't know if Email needs it for now,
> or if it can wait the full change in 1.3. Flagging James for providing an
> answer to this question.

Comment 45

[:gerard-majax]

Attachment: Link to Github https://github.com/mozilla-b2g/gaia/pull/13691

Please find attached a link to the github pull request https://github.com/mozilla-b2g/gaia/pull/13691 which implements a temporary workaround blacklisting the wappush app from the clearing process.

Comment 46

[Julien Wajsberg [:julienw]]

(In reply to James Burke [:jrburke] from comment #43)

> * Only notifications that are activated (tapped) by the user are removed by
> system app

James, I don't get why you want this one: if the tapped notification is a notification holding the information for 2 accounts (that I call a "merged" notification, although it's all managed by the email app like we said earlier), I think you'd want to replace this notification with another text once the user visits one of both accounts, rather than remove the notification.

Does that make sense?

Comment 47

[Adam Rogers (:arog)]

The assertion by jrburke in comment 43 is confirmed.

Comment 48

[James Burke [:jrburke]]

Julien: (In reply to Julien Wajsberg [:julienw] from comment #46)
> (In reply to James Burke [:jrburke] from comment #43)
> 
> > * Only notifications that are activated (tapped) by the user are removed by
> > system app
> 
> James, I don't get why you want this one: if the tapped notification is a
> notification holding the information for 2 accounts (that I call a "merged"
> notification, although it's all managed by the email app like we said
> earlier), I think you'd want to replace this notification with another text
> once the user visits one of both accounts, rather than remove the
> notification.

To clarify:

There is one notification used for each email account configured. However, we update that one notification per account based on ongoing number of sync values. So, if there are two email accounts configured, we could be managing two different notifications. The "tag" in the notification is the account ID.

So, tapping on a notification for email, that is enough to have it removed by the system from the notification tray. The user is brought to that account to see any new messages, and the user has effectively addressed dealing with the notification. If two accounts are configured though and both had notifications, the second notification for the second account would still be in the notification tray.

I would also think that is how it should work for any notification: tapping on it by default removes it from the system tray as the user has addressed it. It seems awkward to force the app to deal with manually clearing it, as the default behavior apps will want is to clear it. It would be much rarer for it to want to persist.

We do update the notification text (or will, now that Notification.get() is available for 1.3) when more messages are synced to update the count in the notification.

Comment 49

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 832108 [details] [review]
Link to Github https://github.com/mozilla-b2g/gaia/pull/13691

Good enough for koi+

Comment 50

[:gerard-majax]

(In reply to Alive Kuo [:alive][NEEDINFO] from comment #49)
> Comment on attachment 832108 [details] [review]
> Link to Github https://github.com/mozilla-b2g/gaia/pull/13691
> 
> Good enough for koi+

Thansk, I'm addressing the nits, retesting and then I'll merge once travis is green !

Comment 51

[:gerard-majax]

https://github.com/mozilla-b2g/gaia/commit/f7f616c7b893e215f3a5ffc82d0557d23c4d9c02

Comment 52

[:gerard-majax]

Travis got red a lot today, now it's mostly green the only failure is totally unrelated.

Comment 53

[Gabriele Svelto [:gsvelto]]

This needs to be uplifted to v1.2. The patch in attachment 832108 [details] [review] applies cleanly to the v1.2 branch and I've verified that it fixes the problem using the emulator.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

John, can you please assist? :)

Comment 55

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted f7f616c7b893e215f3a5ffc82d0557d23c4d9c02 to:
v1.2: 6affb9243d24024bceea6a9e9cf5a3f9161f29d6

Comment 56

[Gabriele Svelto [:gsvelto]]

Clearing the needinfo since this was uplifted, see comment 55.

Comment 57

[Enpei]

Verified on Buri.

Gaia:     ce276842c9ac1746073271fb736dfdb626a89240
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/36c4c667b9f2
BuildID   20131121004002
Version   26.0