Last Comment Bug 767191 - Add about:memory to B2G
: Add about:memory to B2G
Status: RESOLVED WONTFIX
[MemShrink:P2]
:
Product: Firefox OS
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-21 16:18 PDT by Gregor Wagner [:gwagner]
Modified: 2013-02-06 15:27 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Gregor Wagner [:gwagner] 2012-06-21 16:18:09 PDT
Justin suggested this should be an app.
Comment 1 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-06-21 16:33:55 PDT
I think it would be pretty hard to make about:memory an app, because it's chrome-privileged.

Is the idea here to use about:memory just for local testing, or to have it available "in the field"?
Comment 2 Justin Lebar (not reading bugmail) 2012-06-21 16:44:43 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #1)
> I think it would be pretty hard to make about:memory an app, because it's
> chrome-privileged.

I could be wrong, but I *think* we'd just need to relax the restriction on letting <iframe mozbrowser> load "about:" pages, under certain circumstances.

Oh, and we'd have to run it in the top-level process, in order for it to get memory reports from all child processes.  But we already have the notion that some apps will run in the top-level process.

> Is the idea here to use about:memory just for local testing, or to have it
> available "in the field"?

In our experience with MemShrink over the past year, it's very important that about:memory be available "in the field".  It doesn't have to be a prominently-displayed app, of course, so long as you can somehow get to it.
Comment 3 Justin Lebar (not reading bugmail) 2012-06-21 16:45:26 PDT
I'm also fine if it's not an app.  I just don't think you should have to load the browser in order to get to about:memory.
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-06-21 17:12:59 PDT
I'm very queasy about gaia having the capability to load chrome-privileged code.  I suspect that might break a lot of things too.  gwagner and I noodled with the idea of exposing the raw memory information to the "window manager", since it already knows all the apps that are loaded.  But it's possible that the memory reports include more information than gaia already has.

The absolute simplest thing we could do here is have the system app dispatch one of those gnarly ContentChromeEvents to gecko and ask it to dump a memory report.  Then internally gecko could dump to logcat or a text file.  (That's not the full about:memory capability, of course.)

Alternatively, we could have b2g shell.js temporarily "hide" the content <iframe> and load about:memory into a <browser> or something.  This could pop-over the content <iframe>, maybe.  (/me waves hands.)
Comment 5 Justin Lebar (not reading bugmail) 2012-06-21 18:12:44 PDT
> The absolute simplest thing we could do here is have the system app dispatch one of those gnarly 
> ContentChromeEvents to gecko and ask it to dump a memory report.  Then internally gecko could dump 
> to logcat or a text file.  (That's not the full about:memory capability, of course.)

We don't currently have the capability to dump about:memory as plain text.  We've toyed with the idea, and on mobile, it might make sense, but that is not the path of least resistance at the moment.  I also think if we did this, it should be in addition to -- not instead of -- providing the familiar about:memory page on the device.  It's important that about:memory have a low barrier to entry.

> Alternatively, we could have b2g shell.js temporarily "hide" the content <iframe> and load 
> about:memory into a <browser> or something.  This could pop-over the content <iframe>, maybe.

That's fine with me, but it's a B2G-specific hack, whereas allowing <iframe mozbrowser> to load "about:" pages (under certain circumstances) is something that would be useable outside B2G.
Comment 6 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-06-21 18:21:33 PDT
(In reply to Justin Lebar [:jlebar] from comment #5)
> > Alternatively, we could have b2g shell.js temporarily "hide" the content <iframe> and load 
> > about:memory into a <browser> or something.  This could pop-over the content <iframe>, maybe.
> 
> That's fine with me, but it's a B2G-specific hack, whereas allowing <iframe
> mozbrowser> to load "about:" pages (under certain circumstances) is
> something that would be useable outside B2G.

Loading chrome-privileged pages in mozbrowser changes the security model and puts chrome-privileged docshells as children of content-privileged docshells.  I suspect that is not going to be goodtimes.  I really really don't want to go down this route.
Comment 7 Justin Lebar (not reading bugmail) 2012-06-21 18:36:04 PDT
I don't see how this changes the security model.  The security model has nothing to do with "chrome" and "content" pages; it has to do with what apps are capable of doing.  Giving an app the ability to load about:memory doesn't give it any capabilities beyond loading about:memory, so from a security point of view, it changes nothing.

But I'm fine with the solution you're suggesting.  It's less work for me.
Comment 8 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-06-21 19:13:20 PDT
Let me double-check an assumption ... about:memory has chrome *privileges*, correct?  Because it can ask for memory reports and trigger GC?
Comment 9 Justin Lebar (not reading bugmail) 2012-06-21 19:16:01 PDT
(In reply to Chris Jones [:cjones] [:warhammer] from comment #8)
> Let me double-check an assumption ... about:memory has chrome *privileges*,
> correct?  Because it can ask for memory reports and trigger GC?

Correct.
Comment 10 Nicholas Nethercote [:njn] 2013-02-06 15:27:03 PST
The dump-memory-reports-on-signal mechanism is good enough.

Note You need to log in before you can comment on or make changes to this bug.