getSelf() returns null for app immediately after install

NEW
Unassigned

Status

Core Graveyard
DOM: Apps
5 years ago
2 months ago

People

(Reporter: Bobby Holley (parental leave - send mail for anything urgent), Unassigned)

Tracking

unspecified
x86
Mac OS X

Firefox Tracking Flags

(blocking-basecamp:-)

Details

Attachments

(2 attachments)

This is a potential bug I found while writing tests for the install/update paths. There's one failure:

13 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/apps/tests/test_hosted_app_update.html | App is not installed


I'd think maybe I was just doing something stupid, but when the check is repeated it succeeds. Jonas thinks this might be a race condition. I'll attach the tests and the log output.
Created attachment 699311 [details]
mochitest output

Attaching the mochitest output. Note that the call to SimpleTest.finish() is currently commented out, allowing you to run the test multiple times by hitting the "Reload Page" button. This saves the excruciating turnaround of emulator test runs.
Created attachment 699314 [details] [diff] [review]
mochitest testcase

Attaching a mochitest to demonstrate the problem. Instructions for running mochitests on an emulator are here: https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/B2G_Mochitests

Also, jgriffin is working on getting mochitests working on desktop b2g. Follow his progress in bug 826111.
Margaret, can you take a look?
blocking-basecamp: --- → ?
I may be worthwhile to compare with the getSelf() tests we already have in https://mxr.mozilla.org/mozilla-central/search?find=%2Fdom%2Ftests%2Fmochitest%2Fwebapps%2F&string=getself

Comment 5

5 years ago
Sure, I can look into this.
Assignee: nobody → margaret.leibovic
What is the potential impact of this bug?  Its hard to make a blocking determination ATM.
(In reply to Lucas Adamski from comment #6)
> What is the potential impact of this bug?  Its hard to make a blocking
> determination ATM.

getSelf() usage so far I've seen is:

* Internal usage - for example, Myk's stub apps he is building to self-update uses this API

It's been quite rare seeing getSelf used outside of internal usage. But that might be cause we are not evangelizing this.

I'd like to know though why our original mochitests for getSelf are passing right now but Bobby's test is failing.
I talked with Andrew and we decided to at least have a look at what's failing here before making a blocking decision.

getSelf not working is not so much serious for our own apps, but it might be more serious for 3rd party developers wanting to make sure that their app is up-to-date, or for developers that want to deploy a website both as a website and an app.
Flags: needinfo?(bobbyholley+bmo)

Comment 9

5 years ago
I made a test app [1] to try to try to see if this is a problem that's reproducible in a real app install situation, and I didn't find any problems (getSelf() worked fine the first time I launched the app immediately after installing it). I don't think we should block if we can't find a problem outside the test infrastructure, but this is definitely something to investigate and fix.

I'm building the emulator now, and hopefully I can play around with these tests more when that's done.

[1] http://people.mozilla.com/~mleibovic/app/
I think Jonas wanked Margaret here.
Flags: needinfo?(bobbyholley+bmo) → needinfo?(margaret.leibovic)
(In reply to Bobby Holley (:bholley) from comment #10)
> I think Jonas wanked Margaret here.

er. wanted. _wanted_.
Seems to be a mochitest-specific issue.
blocking-basecamp: ? → -
This isnt going to work as it calls through to 

http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#2568

which is only going to work once platform specific webrt things are implemented
Flags: needinfo?(margaret.leibovic)
(In reply to Dale Harvey (:daleharvey) from comment #13)
> This isnt going to work as it calls through to 

What is "this"? The mochitest? Are you saying that the null return value is a known and well-understood issue? That would seem a bit strange, given that the behavior here seems racy.
I couldnt reproduce the racyness, however you are right

http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/webapps/head.js#4

I am confused about a function that is checking for OS specific registry data that can just be overwritten by a global ignore, however a few of the tests have worked around this by setting allAppsLaunchable = true, should we do the same? at that point they will all pass on both firefox and b2g builds

Comment 16

5 years ago
I'm unassigning myself because I'm not working on this anymore.
Assignee: margaret.leibovic → nobody
I've seen this happening when calling getSelf from the website instead of the app. If you call getSelf from within the launched app, it returns the App object, but if you call it from the webpage you get null. This could be related to Bug 806597.
Comment 17 is unrelated to this bug and is in fact expected behavior. But please let's not debate that here as it's for sure unrelated to this bug. If you think that getSelf() should return something different when called from a website, please file a separate bug and cc me.
(In reply to Jonas Sicking (:sicking) from comment #18)
> Comment 17 is unrelated to this bug and is in fact expected behavior. But
> please let's not debate that here as it's for sure unrelated to this bug. If
> you think that getSelf() should return something different when called from
> a website, please file a separate bug and cc me.

Thanks for the clarification. It must've been that I got confused with the documentation in MDN. I'll take a better look there and try to make it clear if I see something confusing.

Updated

2 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.