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

VERIFIED FIXED in Firefox OS v1.2

Status

Firefox OS
Gaia::System
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Enpei, Assigned: gerard)

Tracking

({regression})

unspecified
1.3 Sprint 5 - 11/22
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:koi+, b2g18 unaffected, b2g-v1.1hd unaffected, b2g-v1.2 verified)

Details

(Whiteboard: [FT:RIL][systemsfe])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 820849 [details]
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
(Reporter)

Updated

5 years ago
Blocks: 924808
blocking-b2g: --- → koi?
Whiteboard: [FT:RIL]
(Reporter)

Comment 1

5 years ago
Created attachment 820851 [details]
video
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.
Component: Gaia → Gaia::System
(Reporter)

Comment 3

5 years ago
(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.
Weird, I think I had actually fixed this. I'll re-check it and see if I can reproduce it.
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Hardware: x86_64 → ARM
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?
(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.
Keywords: regression
(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.
Hi Gabriele,

What is the work around for the 2 bugs - 929895 and https://bugzilla.mozilla.org/show_bug.cgi?id=924808
Flags: needinfo?(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.
Flags: needinfo?(gsvelto)
David,

Please check
blocking-b2g: koi? → koi+
Flags: needinfo?(dscravaglieri)
Created attachment 823493 [details] [diff] [review]
[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
Attachment #823493 - Flags: feedback?(felash)
Flags: needinfo?(dscravaglieri)
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.
Alive, could you please comment on comment 12 (context is comment 11)? Thanks!
Flags: needinfo?(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.
Flags: needinfo?(alive)
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!
Flags: needinfo?(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..
Flags: needinfo?(alive)
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...
Flags: needinfo?(alive)
Also NI Kyle who implemented the new notification API in the system app IIRC.
Flags: needinfo?(kyle)
(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.
Flags: needinfo?(kyle)
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.
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.
Flags: needinfo?(jrburke)
Flags: needinfo?(bugmail)
: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.)
Flags: needinfo?(bugmail)
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...
Flags: needinfo?(alive)
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?

Updated

5 years ago
Duplicate of this bug: 935096

Updated

5 years ago
Summary: [WAP push] Read one of multiple received WAP push message will remove/close rest of messages from utility tray. → [WAP push] [CP] Read one of multiple received WAP push message will remove/close rest of messages from utility tray.
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?
Andrew, see previous comment. (forgot to put the flag...)
Flags: needinfo?(bugmail)
Attachment #823493 - Flags: feedback?(felash) → feedback-
(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.
Flags: needinfo?(bugmail)
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.
Flags: needinfo?(jrburke)
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.
Flags: needinfo?(jrburke)
Flags: needinfo?(alive)
(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.
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.
Flags: needinfo?(jrburke)
Transfer to Gregor to find someone from system frontend team to involve this since I was really occupied now ;)
Flags: needinfo?(alive)
Flags: needinfo?(anygregor)
Flags: needinfo?(anygregor)
Whiteboard: [FT:RIL] → [FT:RIL][systemsfe]
Gabriele, are you still working on this?
Flags: needinfo?(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.
Flags: needinfo?(gsvelto)
(Assignee)

Comment 36

5 years ago
Taking, I can reproduce also with other apps, as reported in other comments. We will provide a workaround for this for v1.2.
(Assignee)

Updated

5 years ago
Assignee: gsvelto → lissyx+mozillians
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...
(Assignee)

Comment 38

5 years ago
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.
Flags: needinfo?(alive)
(Assignee)

Comment 39

5 years ago
(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.
(Assignee)

Comment 40

5 years ago
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.
(Assignee)

Updated

5 years ago
Depends on: 890440
(Assignee)

Comment 41

5 years ago
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.
(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.
Flags: needinfo?(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.
Flags: needinfo?(jrburke) → needinfo?(arogers)
(Assignee)

Comment 44

5 years ago
(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.
(Assignee)

Comment 45

5 years ago
Created attachment 832108 [details] [review]
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.
Attachment #832108 - Flags: review?(alive)
(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?
Flags: needinfo?(jrburke)
Target Milestone: --- → 1.3 Sprint 5 - 11/22

Comment 47

5 years ago
The assertion by jrburke in comment 43 is confirmed.
Flags: needinfo?(arogers)
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.
Flags: needinfo?(jrburke)
Comment on attachment 832108 [details] [review]
Link to Github https://github.com/mozilla-b2g/gaia/pull/13691

Good enough for koi+
Attachment #832108 - Flags: review?(alive) → review+
Flags: needinfo?(alive)
(Assignee)

Comment 50

5 years ago
(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 !
(Assignee)

Comment 51

5 years ago
https://github.com/mozilla-b2g/gaia/commit/f7f616c7b893e215f3a5ffc82d0557d23c4d9c02
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 52

5 years ago
Travis got red a lot today, now it's mostly green the only failure is totally unrelated.
Attachment #823493 - Attachment is obsolete: true
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.
status-b2g18: --- → unaffected
status-b2g-v1.1hd: --- → unaffected
status-b2g-v1.2: --- → affected

Updated

5 years ago
Keywords: checkin-needed
John, can you please assist? :)
Flags: needinfo?(jhford)
Uplifted f7f616c7b893e215f3a5ffc82d0557d23c4d9c02 to:
v1.2: 6affb9243d24024bceea6a9e9cf5a3f9161f29d6
status-b2g-v1.2: affected → fixed
Keywords: checkin-needed
Clearing the needinfo since this was uplifted, see comment 55.
Flags: needinfo?(jhford)
(Reporter)

Comment 57

5 years ago
Verified on Buri.

Gaia:     ce276842c9ac1746073271fb736dfdb626a89240
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/36c4c667b9f2
BuildID   20131121004002
Version   26.0
Status: RESOLVED → VERIFIED
status-b2g-v1.2: fixed → verified
You need to log in before you can comment on or make changes to this bug.