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)
Tracking
(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)
People
(Reporter: nhirata, Assigned: cjones)
References
Details
(Whiteboard: [feedback])
Attachments
(3 files, 1 obsolete file)
## 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...
![]() |
Reporter | |
Comment 1•12 years ago
|
||
![]() |
Reporter | |
Comment 2•12 years ago
|
||
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?
Assignee | ||
Comment 3•12 years ago
|
||
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
Assignee | ||
Comment 4•12 years ago
|
||
That's bad irrespective of the necko stuff.
blocking-basecamp: --- → ?
Assignee | ||
Comment 5•12 years ago
|
||
Blocks a blocker.
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C3 (12dec-1jan)
Assignee | ||
Comment 6•12 years ago
|
||
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
Assignee | ||
Comment 7•12 years ago
|
||
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
Assignee | ||
Comment 8•12 years ago
|
||
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 9•12 years ago
|
||
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)
Assignee | ||
Comment 10•12 years ago
|
||
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)
Updated•12 years ago
|
Component: Gaia::Browser → General
QA Contact: nhirata.bugzilla
Comment 11•12 years ago
|
||
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+
Assignee | ||
Comment 12•12 years ago
|
||
I would too. Maybe jdm knows the answer to comment 10?
Flags: needinfo?(josh)
Comment 13•12 years ago
|
||
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)
Assignee | ||
Comment 14•12 years ago
|
||
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?
Assignee | ||
Comment 15•12 years ago
|
||
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)
Assignee | ||
Updated•12 years ago
|
Component: General → DOM: Apps
Product: Boot2Gecko → Core
Assignee | ||
Comment 16•12 years ago
|
||
Cowardly punting to a followup because this looks really hard.
Flags: needinfo?(justin.lebar+bug)
Flags: needinfo?(jduell.mcbugs)
Assignee | ||
Comment 17•12 years ago
|
||
Comment 18•12 years ago
|
||
Comment 19•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 20•12 years ago
|
||
(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.
Comment 21•12 years ago
|
||
(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.
Comment 22•12 years ago
|
||
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.
Comment 23•12 years ago
|
||
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.
Comment 24•12 years ago
|
||
Ooooh, okay. I understand now. Sorry for the confusion!
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•