Closed Bug 767191 Opened 12 years ago Closed 11 years ago

Add about:memory to B2G

Categories

(Firefox OS Graveyard :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: gwagner, Unassigned)

Details

(Whiteboard: [MemShrink:P2])

Justin suggested this should be an app.
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"?
(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.
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.
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.)
> 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.
(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.
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.
Let me double-check an assumption ... about:memory has chrome *privileges*, correct?  Because it can ask for memory reports and trigger GC?
(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.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]
The dump-memory-reports-on-signal mechanism is good enough.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.