Closed Bug 824177 Opened 12 years ago Closed 12 years ago

mozbrowser frames inside gaia browser app are popping up with NO_APP_ID

Categories

(Core Graveyard :: DOM: Apps, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

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

RESOLVED FIXED
B2G C3 (12dec-1jan)
blocking-basecamp +
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: nhirata, Assigned: cjones)

References

Details

(Whiteboard: [feedback])

Attachments

(3 files, 1 obsolete file)

Attached 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)
Status: NEW → RESOLVED
Closed: 12 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.

Attachment

General

Created:
Updated:
Size: