Closed
Bug 979974
Opened 10 years ago
Closed 10 years ago
[DataStore] Not receiving change events from different app
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: arcturus, Assigned: baku)
Details
Attachments
(1 file)
10.95 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
We are not receiving change events for a datastore if is a 3rd app the one registering a listener for those changes. IE.: - We have app1 defining DS1 - We have app2 (with correct manifest) ask for datastores 'DS1' and get the instance. - in app2 we register for the onchange event - in app1 we do perform a change in the DS meanwhile app2 is alive. We are suppose to receive a change event in app2, but we don't, this is the log when we add a new element to the datastore: francisco: I/Gecko ( 813): DEBUG DataStore: DBPromise started I/Gecko ( 813): DEBUG DataStoreDB: Transaction request I/Gecko ( 813): DEBUG DataStore: DBPromise success I/Gecko ( 813): DEBUG DataStore: AddInternal I/Gecko ( 813): DEBUG DataStore: Request successful. Id: 1 I/Gecko ( 813): DEBUG DataStoreDB: AddRevision: 1 - added I/Gecko ( 813): DEBUG DataStore: SendNotification I/Gecko ( 813): DEBUG DataStore: AddInternal - revisionId increased I/Gecko ( 684): DEBUG DataStoreChangeNotifier: receiveMessage I/Gecko ( 684): DEBUG DataStoreChangeNotifier: Broadasting message. I/Gecko ( 813): DEBUG DataStore: receiveMessage I/Gecko ( 813): DEBUG DataStoreDB: Transaction request I/Gecko ( 813): DEBUG DataStore: RetrieveRevisionId transaction success I/Gecko ( 813): DEBUG DataStore: receiveMessage I/Gecko ( 813): DEBUG DataStoreDB: Transaction request I/Gecko ( 813): DEBUG DataStore: RetrieveRevisionId transaction success I/Gecko ( 813): DEBUG DataStore: receiveMessage I/Gecko ( 813): DEBUG DataStoreDB: Transaction request I/Gecko ( 813): DEBUG DataStore: RetrieveRevisionId transaction success
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → amarchesini
Assignee | ||
Comment 1•10 years ago
|
||
nsIMessageSender is a bit weird. It turned out that: 1. we have 1 single nsIMessageSender per process. - for this reason we have an hash table in the DataStoreChangeNotification.jsm 2. when a message is send through a nsIMessageSender, only the listeners of that particular process receive the message. For this we have to filter out the unwanted messages in DataStore.jsm The test here included, simulated 2 apps in 2 processes, 1 listening events of the other. There is also a test where 2 apps are on the same process (test_changes.html).
Attachment #8386260 -
Flags: review?(ehsan)
Assignee | ||
Comment 2•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=440163da8bc3
Updated•10 years ago
|
Attachment #8386260 -
Flags: review?(ehsan) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Updated•10 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 3•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb4491ce2a16
Flags: in-testsuite+
Keywords: checkin-needed
Comment 4•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/fb4491ce2a16
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•