Chrome "stack trace" showing two different invocations of the push callback handler.

console.trace() cloud-push.html:122
handlePush cloud-push.html:122
b.handleCloudPush bridgeit.js:1275
(anonymous function) bridgeit.js:529

bridgeit history replaceState: /cloud-push.html bridgeit.js:535
[icepush.0ad91] received notifications: 73hot433sj:13od VM843:1398
console.trace() cloud-push.html:122
handlePush cloud-push.html:122
(anonymous function) VM843:2699
apply VM843:177
(anonymous function) VM843:546
(anonymous function) VM843:422
(anonymous function) VM843:70
broadcast VM843:545
selectWindowNotifications VM843:2870
(anonymous function) VM843:2504
(anonymous function) VM843:65
(anonymous function) VM843:2900
(anonymous function) VM843:2029
(anonymous function) VM843:65
(anonymous function) VM843:2928
apply VM843:177
(anonymous function) VM843:546
(anonymous function) VM843:422
(anonymous function) VM843:70
broadcast VM843:545
(anonymous function) VM843:2190
apply VM843:177
(anonymous function) VM843:207
nativeRequestResponse.onreadystatechange VM843:1044

Method to reproduce:
View bridgeit demo cloud-push.html
Enable Cloud Push
0) Press "Push"
Press device home button
Return to browser via device notification
Navigate to BridgeIt demo menu via link at top
Select Cloud Push
Repeat 0)

At some point you will see "Debouncing duplicate push: 252" in the JavaScript console log. (The time value of milliseconds from the previous push will vary.)

Although this seems to be a stale delivery of a push notification from ICEpush, the steps to reproduce are consistent with duplicate listener registration. However, duplicate listener registration is guarded with a flag.

From the HTTP traffic below, we can see that the add-group-member and the listen have the same timestamp. This seems to indicate that the notification has remained queued on the server even though the cloud push was sent.

POST /push/add-group-member.icepush HTTP/1.1
Host: labs.icesoft.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://seven.local:4000
Content-Length: 141
Connection: keep-alive
Accept: /
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11D5099e Safari/9537.53
Referer: http://seven.local:4000/cloud-push.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate

ice.push.browser=3houk2oym&ice.push.apikey=197EBF31-40CD-444F-826F-10158A0F3581&group=f9c3601c-352f-4edf-a099-e904dd7d2f38&id=3houk2oym%3A2da

HTTP/1.1 200 OK
Date: Thu, 05 Dec 2013 22:17:44 GMT
Server: Apache-Coyote/1.1
Access-Control-Expose-Headers: ice.push.sequence,X-Connection,X-Connection-reason,X-Set-Window-Cookie,ice.push.heartbeatTimestamp,ice.push.heartbeat
Access-Control-Allow-Headers: origin, ice.push.sequence, ice.push.window, ice.push.browser, content-type, ice.parkids, ice.notifyBack, ice.push.heartbeatTimestamp
Access-Control-Allow-Origin: http://seven.local:4000
Access-Control-Allow-Credentials: true
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: close

POST /push/listen.icepush HTTP/1.1
Host: labs.icesoft.com
ice.push.heartbeatTimestamp: 1386281832166
ice.notifyBack: apns:cb3053be6920d6c3e57101539df001fb0fffd89cc4af384d83be7d65328d86de
Accept: /
ice.push.browser: 3houk2oym
ice.push.sequence: 23
ice.parkids: true
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://seven.local:4000
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11D5099e Safari/9537.53
ice.push.window: de4ee
Referer: http://seven.local:4000/cloud-push.html
Content-Length: 106
Connection: keep-alive

ice.push.browser=3houk2oym&ice.push.apikey=197EBF31-40CD-444F-826F-10158A0F3581&ice.pushid=3houk2oym%3A2da

HTTP/1.1 200 OK
Date: Thu, 05 Dec 2013 22:17:44 GMT
Server: Apache-Coyote/1.1
Access-Control-Expose-Headers: ice.push.sequence,X-Connection,X-Connection-reason,X-Set-Window-Cookie,ice.push.heartbeatTimestamp,ice.push.heartbeat
Access-Control-Allow-Headers: origin, ice.push.sequence, ice.push.window, ice.push.browser, content-type, ice.parkids, ice.notifyBack, ice.push.heartbeatTimestamp
Access-Control-Allow-Origin: http://seven.local:4000
Access-Control-Allow-Credentials: true
ice.push.heartbeat: 9711
ice.push.heartbeatTimestamp: 1386281864684
ice.push.sequence: 24
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Content-Length: 52
Connection: close

<notified-pushids>3houk2oym:2da</notified-pushids>

To be verified by testing of the current version.

I tested this fairly recently but I was unable to reproduce this then. However, going through the instructions we might need to test this a little differently. We should try to re-test this for the upcoming EE-4.0.0.GA release.

This was discovered using the BridgeIt Demo application deployed back in Nov/Dec of 2013. Since then NaaS (which is used by BridgeIt Demo) changed quite a bit. Using the "internal" Edge Push demo I was unable to reproduce this issue with the latest NaaS (which uses the latest ICEpush-EE). I checked the HTTP traffic that occurs after the Cloud Push notification is received and used to get back into the browser. I do see the add-group-member.icepush Request as expected but I don't see a listen.icepush Response containing <notified-pushids>. I tried multiple times.

Once we have BridgeIt Demo up-to-date again with the NaaS or once we see this issue again we should re-open this one.

Marking this one as Cannot Reproduce for now.