Closed
Bug 1024618
Opened 10 years ago
Closed 10 years ago
Cannot add collection after homescreen kill
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
FIXED
mozilla33
People
(Reporter: jlal, Assigned: baku, NeedInfo)
References
Details
Attachments
(1 file, 2 obsolete files)
4.12 KB,
patch
|
ehsan.akhgari
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
The collections app will show up but after saving the collection nothing appears on the homescreen: I see this in logcat E/GeckoConsole( 1387): [JavaScript Error: "NS_ERROR_NOT_INITIALIZED: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMessageSender.sendAsyncMessage]" {file: "resource://gre/modules/DataStoreChangeNotifier.jsm" line: 61}] Which is likely the error (making this a DataStore bug?)
Updated•10 years ago
|
Component: Gaia::Homescreen → DOM: Device Interfaces
Product: Firefox OS → Core
Comment 1•10 years ago
|
||
Andrea - This feels like it could be a datastore issue. Could you take a look?
Flags: needinfo?(amarchesini)
Comment 2•10 years ago
|
||
(When the homescreen recovers we should do sync from datastore to get updated records - and those should appear)
Comment 3•10 years ago
|
||
This might be a dupe of bug 1023796, but I need a logcat on bug 1023796 to confirm.
Updated•10 years ago
|
Blocks: vertical-homescreen
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Comment 4•10 years ago
|
||
Actually before I triage this - how is the homescreen getting killed here? By LMK?
blocking-b2g: 2.0? → ---
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Flags: needinfo?(jlal)
Comment 5•10 years ago
|
||
Even if it is LMK, we might have a datastore bug on our hands here.
Reporter | ||
Comment 6•10 years ago
|
||
I killed it via adb shell kid <homescreen pid> not sure how close it is to LMK these days.
Flags: needinfo?(jlal)
Comment 7•10 years ago
|
||
(In reply to Kevin Grandon :kgrandon from comment #5) > Even if it is LMK, we might have a datastore bug on our hands here. We found a datastore bug with the other homescreen proto that shows exactly the same error than the one you are seeing. Will open a bug with our local patch for it.
Comment 8•10 years ago
|
||
Andrea, I tried to do a cleaner with a method that check if the message manager is still alive but didn't find the right method for that :/
Attachment #8439794 -
Flags: review?(amarchesini)
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-]
Assignee | ||
Comment 9•10 years ago
|
||
Sorry Vivien but your patch is not good. The real problem was that, if an app is registered to many dataStore, when it quits/is killed, DataStoreChangeNotifier.jsm doesn't remove all the instances of this app in its hashtable.
Attachment #8439794 -
Attachment is obsolete: true
Attachment #8439794 -
Flags: review?(amarchesini)
Attachment #8439914 -
Flags: review?(ehsan)
Flags: needinfo?(amarchesini)
Comment 10•10 years ago
|
||
Comment on attachment 8439914 [details] [diff] [review] foobar.patch Review of attachment 8439914 [details] [diff] [review]: ----------------------------------------------------------------- Oops. Can you add a test for this please?
Attachment #8439914 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 11•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/25b0cc03110c I tried to create a test. It's not so easy to reproduce with a mochitest. I'll try again. I land this patch because I spoke with ehsan on IRC and he agreed to land it and to write the mochitest in a separated patch.
Comment 12•10 years ago
|
||
Backed out for failures in test_changes.html: https://tbpl.mozilla.org/php/getParsedLog.php?id=41685326&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=41685116&tree=Mozilla-Inbound remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/264e4791ad72
Assignee | ||
Comment 13•10 years ago
|
||
Attachment #8439914 -
Attachment is obsolete: true
Attachment #8440079 -
Flags: review?(ehsan)
Updated•10 years ago
|
Attachment #8440079 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 14•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b3794b7e1dc https://tbpl.mozilla.org/?tree=Try&rev=949a34532afd
Comment 15•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8b3794b7e1dc
Assignee: nobody → amarchesini
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Comment 16•10 years ago
|
||
Comment on attachment 8440079 [details] [diff] [review] foobar.patch Review of attachment 8440079 [details] [diff] [review]: ----------------------------------------------------------------- This is required for the vertical homescreen. Is the process the same here for uplifting as it is for gaia patches?
Attachment #8440079 -
Flags: approval-mozilla-aurora?
Comment 17•10 years ago
|
||
Bhavana - is there anything special I need to do to get this uplifted? Thanks!
Flags: needinfo?(bbajaj)
Comment 18•10 years ago
|
||
Kevin - For uplift approval you either need to have your bug marked as blocking-b2g (use the flag to nom) or request uplift approval as you've done. Please fill out the uplift questionnaire, which should autopopulate when you set approval-mozilla-aurora? [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String or IDL/UUID changes made by this patch: In this case, I see that the patch bounced, but had a successful try push and has now relanded. Can you comment on any additional testing that you have done? What are the risks to taking this patch? In a quick glance at the patch I do see hardcoded strings but I think they are all in debug statements. Did I miss any that require l10n?
Flags: needinfo?(bbajaj)
Updated•10 years ago
|
Flags: needinfo?(kgrandon)
Comment 19•10 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #18) > User impact if declined: The bug. Users won't be able to add collections to the vertical homescreen. > Testing completed (on m-c, etc.): Lots of manual testing and verification for now. A CI test is coming as a follow-up. > Risk to taking this patch (and alternatives if risky): See below. > String or IDL/UUID changes made by this patch: See below. > > In this case, I see that the patch bounced, but had a successful try push > and has now relanded. Can you comment on any additional testing that you > have done? It's been baking on master for a while now, and we've done lots of manual testing to verify that this is fine. > What are the risks to taking this patch? It's already broken, so not much, but if there were an area of regression it would be in datastore. > In a quick glance at the patch I do see hardcoded strings but I think they > are all in debug statements. Did I miss any that require l10n? No l10n changes necessary.
Flags: needinfo?(kgrandon)
Updated•10 years ago
|
Attachment #8440079 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 20•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/9d21d16d60fa
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
Comment 21•10 years ago
|
||
Would you please provide the reproduce step for tester to verify this issue.Thanks for your help.
Flags: needinfo?(jlal)
You need to log in
before you can comment on or make changes to this bug.
Description
•