mozbrowser frames inside gaia browser app are popping up with NO_APP_ID

RESOLVED FIXED in Firefox 19

Status

defect
P1
normal
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: nhirata, Assigned: cjones)

Tracking

(Depends on 1 bug)

unspecified
B2G C3 (12dec-1jan)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

Details

(Whiteboard: [feedback])

Attachments

(3 attachments, 1 obsolete attachment)

Posted file logcat
## Environment :
Unagi phone, build 2012-12-21

## Repro :
1. go to KTUL.com

## Expected :
1. you can see the site

## Actual :
1. Well this is embarassing ...

## Note :
1. logcat attached
2. I didn't see any sigkills...
The same thing happened for Kron4.com, except with Kron4.com, you had to try going to a newslink, and when that happened there was an attempt for a sigkill : 

12-21 17:23:37.538: D/memalloc(107): /dev/pmem: Freeing buffer base:0x4b8aa000 size:184320 offset:4521984 fd:187
12-21 17:23:37.538: D/memalloc(107): /dev/pmem: Freeing buffer base:0x4b8d7000 size:184320 offset:4706304 fd:192
12-21 17:23:37.819: I/Gecko(107): [Parent 107] WARNING: waitpid failed pid:589 errno:10: file ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 260
12-21 17:23:38.399: E/profiler(674): Registering start signal
12-21 17:23:38.399: E/profiler(673): Registering start signal
12-21 17:23:39.400: E/GeckoConsole(673): [JavaScript Warning: "Unknown property '-moz-align-self'.  Declaration dropped." {file: "resource://gre-resources/ua.css" line: 44}]
12-21 17:23:39.410: E/GeckoConsole(674): [JavaScript Warning: "Unknown property '-moz-align-self'.  Declaration dropped." {file: "resource://gre-resources/ua.css" line: 44}]
12-21 17:23:39.821: I/Gecko(107): [Parent 107] WARNING: waitpid failed pid:589 errno:10: file ../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 260
12-21 17:23:39.821: I/Gecko(107): [Parent 107] WARNING: Failed to deliver SIGKILL to 589!(3).: file ../../../gecko/ipc/chromium/src/chrome/common/process_watcher_posix_sigchld.cc, line 118
12-21 17:23:39.901: I/Gecko(673): ###################################### forms.js loaded
12-21 17:23:39.921: I/Gecko(674): ###################################### forms.js loaded
12-21 17:24:46.015: I/IdleService(107): Remove idle observer 438d84f0 (1 seconds)
12-21 17:24:46.225: D/memalloc(107): /dev/pmem: Freeing buffer base:0x4b752000 size:614400 offset:3112960 fd:165
12-21 17:24:46.225: D/memalloc(107): /dev/pmem: Freeing buffer base:0x4b904000 size:614400 offset:4890624 fd:110
12-21 17:24:46.306: E/GeckoConsole(107): [JavaScript Error: "Image corrupt or truncated: app://system.gaiamobile.org/style/lockscreen/images/mask.png" {file: "app://system.gaiamobile.org/style/lockscreen/images/mask.png" line: 0}]
12-21 17:28:36.090: I/IdleService(107): Get idle time: time since reset 300010 msec

Might have to log this separately?
For the kron4 test case,

I/Gecko   (11101): [Parent 11101] WARNING: NeckoParent::AllocPHttpChannel: FATAL error: TabParent reports appId=NECKO_NO_APP_ID but is a mozbrowser: KILLING CHILD PROCESS
Blocks: 782542
That's bad irrespective of the necko stuff.
blocking-basecamp: --- → ?
Blocks a blocker.
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
Blocks two blockers, because it means clear-private-data is broken too.
Summary: Certain websites seem to cause the profiler to register a start signal. → mozbrowser frames inside gaia browser app are popping up with UNKNOWN_APP_ID
Sorry, typo.
Summary: mozbrowser frames inside gaia browser app are popping up with UNKNOWN_APP_ID → mozbrowser frames inside gaia browser app are popping up with NO_APP_ID
Let me know the best way to write a test for this.
Assignee: nobody → jones.chris.g
Attachment #695105 - Flags: review?(justin.lebar+bug)
Comment on attachment 695105 [details] [diff] [review]
Opened windows of browsers inherit their containing app

Did you mean to assign the bug to me?  I can take it if you want, but I probably won't be able to get to it until Jan 7 or so.

>+        mContainingAppId = context->BrowserOwnerAppId();

I don't think this is quite right.

ipcContext.isBrowserElement() tells us whether we're a browser.  But it doesn't tell us whether our opener is a browser.

But context->BrowserOwnerAppId() gets our opener's app-id only if the opener is a browser.  If context (our opener) is not a browser, BrowserOpenerAppId() returns NO_APP.

I /think/ it should be mContainingAppId = context->OwnOrContainingAppId().  If the opener is an app, that's the app's id, and if the opener is a browser, that's the browser's owner id.

As far as writing a test for this, you can of course create a mozbrowser which calls window.open and do that business.  It's not clear to me what else needs to be done to trigger this bug, though.
Attachment #695105 - Flags: review?(justin.lebar+bug)
jduell, in which testing configurations do we have necko security enabled?  I'm not sure which harness will actually test this correctly.

The test just needs to do the following
 - create a <browser> inside an <app>
 - have the <browser> window.open() another window
 - load any HTML file in that new window
Attachment #695105 - Attachment is obsolete: true
Attachment #695542 - Flags: review?(justin.lebar+bug)
Flags: needinfo?(jduell.mcbugs)
Component: Gaia::Browser → General
QA Contact: nhirata.bugzilla
Comment on attachment 695542 [details] [diff] [review]
Opened windows of browsers inherit their containing app, v2

r=me, but I would <3 a test.
Attachment #695542 - Flags: review?(justin.lebar+bug) → review+
I would too.  Maybe jdm knows the answer to comment 10?
Flags: needinfo?(josh)
I don't know what kind of testing abilities we have for apps. I am only aware of the test harnesses in which we have disabled the checks, being xpcshell and the dom/browser-element tests.
Flags: needinfo?(josh)
The dom/browser-element tests are exactly what I need to write this test :/.  Is there a bug to re-enable checking there?  Is it kosher to turn checking on/off willy nilly?
I guess an alternative is introspecting on the containing app ID from chrome script.  Is there a way I can do that?
Flags: needinfo?(justin.lebar+bug)
Component: General → DOM: Apps
Product: Boot2Gecko → Core
Cowardly punting to a followup because this looks really hard.
Flags: needinfo?(justin.lebar+bug)
Flags: needinfo?(jduell.mcbugs)
https://hg.mozilla.org/mozilla-central/rev/cd2211a458e5
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
(In reply to Chris Jones [:cjones] [:warhammer] from comment #15)
> I guess an alternative is introspecting on the containing app ID from chrome
> script.  Is there a way I can do that?

I don't get what the problem is -- content can get its app manifest, and I think with a little special powers magic you can get the app ID from a mochitest.  IIRC we even have code in the browser-element tests which does this.

Such a test would work on desktop as well as b2g.

> I am only aware of the test harnesses in which we have disabled the checks, being 
> xpcshell and the dom/browser-element tests.

I don't remember being told that we disabled these tests on B2G, but I could be forgetting.  Could you please point me to the bug?

> Is it kosher to turn checking on/off willy nilly?

Certainly not without asking the owner of those tests, I should think.
(In reply to Justin Lebar [:jlebar] (away 12/21-1/2) from comment #20)
> > I am only aware of the test harnesses in which we have disabled the checks, being 
> > xpcshell and the dom/browser-element tests.
> 
> I don't remember being told that we disabled these tests on B2G, but I could
> be forgetting.  Could you please point me to the bug?
> 
> > Is it kosher to turn checking on/off willy nilly?
> 
> Certainly not without asking the owner of those tests, I should think.

Bug 782542 comment 47. Sorry for not roping you in.
I'm cc'ed on that bug, actually.  But I'm confused: jduell is saying in there that we don't use browser-not-in-app in production, which is true.  But I thought we were saying here that we aren't running dom/browser-element tests on B2G?

Sorry if I'm misunderstanding.
I only said that we disable the necko security checks when running the dom/browser-element tests, due to the unusual situation of browser without app. The tests themselves still run as usual.
Ooooh, okay.  I understand now.  Sorry for the confusion!
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.