Bug 961362 - [e10s] HTML5 video's fullscreen feature zooms video to fill tab, not screen
Initial investigation
Q: What's the syntax for the DOM Fullscreen API?
element.mozRequestFullScreen()
"element" could be document.documentElement if you just wanted to fullscreen the whole thing.
Q: Where is the mozRequestFullScreen code?
Be careful not to confuse DOM fullscreen with the fullscreen browsing mode of the UI. These are not the same things.
Hm... seems like nsDocument.cpp does some dispatching, and eventually the native widget code should take care of things.
But it's not.
Q: What's going wrong?
This code fails in nsGlobalWindow::SetFullScreenInternal:
// make sure we don't try to set full screen on a non-chrome window,
// which might happen in embedding world
if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
return NS_ERROR_FAILURE;
// which might happen in embedding world
if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
return NS_ERROR_FAILURE;
Ah, so because the content doesn't see itself as a non-chrome window, it fails here.
Trace:
* thread #1: tid = 0x21b0ba, 0x00000001022a47be
XUL`nsGlobalWindow::SetFullScreenInternal(this=0x0000000124a21400,
aFullScreen=true, aRequireTrust=false) + 142 at nsGlobalWindow.cpp:5981,
queue = 'com.apple.main-thread', stop reason = step over
* frame #0: 0x00000001022a47be XUL`nsGlobalWindow::SetFullScreenInternal(this=0x0000000124a21400, aFullScreen=true, aRequireTrust=false) + 142 at nsGlobalWindow.cpp:5981
frame #1: 0x00000001022a52cd XUL`_ZThn32_N14nsGlobalWindow21SetFullScreenInternalEbb(this=0x0000000124a21420, aFullScreen=true, aRequireTrust=false) + 61 at nsGlobalWindow.cpp:6066
frame #2: 0x00000001028de22f XUL`nsSetWindowFullScreen::Run(this=0x0000000122b722b0) + 127 at nsDocument.cpp:10394
frame #3: 0x00000001028f78d1 XUL`nsContentUtils::AddScriptRunner(aRunnable=0x0000000122b722b0) + 129 at nsContentUtils.cpp:5106
frame #4: 0x00000001028b4f0d XUL`SetWindowFullScreen(aDoc=0x0000000124ae9800, aValue=true) + 157 at nsDocument.cpp:10431
frame #5: 0x00000001028b640b XUL`nsDocument::RequestFullScreen(this=0x0000000124ae9800, aElement=0x000000012531c280, aWasCallerChrome=false, aNotifyOnOriginChange=true) + 3035 at nsDocument.cpp:11196
frame #6: 0x00000001028de04e XUL`nsCallRequestFullScreen::Run(this=0x0000000124e1e070) + 174 at nsDocument.cpp:10761
frame #7: 0x0000000100164b02
* frame #0: 0x00000001022a47be XUL`nsGlobalWindow::SetFullScreenInternal(this=0x0000000124a21400, aFullScreen=true, aRequireTrust=false) + 142 at nsGlobalWindow.cpp:5981
frame #1: 0x00000001022a52cd XUL`_ZThn32_N14nsGlobalWindow21SetFullScreenInternalEbb(this=0x0000000124a21420, aFullScreen=true, aRequireTrust=false) + 61 at nsGlobalWindow.cpp:6066
frame #2: 0x00000001028de22f XUL`nsSetWindowFullScreen::Run(this=0x0000000122b722b0) + 127 at nsDocument.cpp:10394
frame #3: 0x00000001028f78d1 XUL`nsContentUtils::AddScriptRunner(aRunnable=0x0000000122b722b0) + 129 at nsContentUtils.cpp:5106
frame #4: 0x00000001028b4f0d XUL`SetWindowFullScreen(aDoc=0x0000000124ae9800, aValue=true) + 157 at nsDocument.cpp:10431
frame #5: 0x00000001028b640b XUL`nsDocument::RequestFullScreen(this=0x0000000124ae9800, aElement=0x000000012531c280, aWasCallerChrome=false, aNotifyOnOriginChange=true) + 3035 at nsDocument.cpp:11196
frame #6: 0x00000001028de04e XUL`nsCallRequestFullScreen::Run(this=0x0000000124e1e070) + 174 at nsDocument.cpp:10761
frame #7: 0x0000000100164b02
(50:00)
At first, I was worried that the fullscreen API does things with the
widget being fullscreened - like making somehow passing it to the native
widget stuff to display at full blast.
But now I'm thinking what we do is make the element consume max width
and height of the browser over all else, and then make the browser go
full screen.
If that's the case, we might just want to remote the fullscreen call to the parent process.
Q: Is this true? What happens to the Widget when RequestFullScreen is called on it?
Yes, this seems to be the case. I think this is the code that's doing the job (from nsDocument::RequestFullScreen)
// Set the full-screen element. This sets the full-screen style on the
// element, and the full-screen-ancestor styles on ancestors of the element
// in this document.
DebugOnly<bool> x = FullScreenStackPush(aElement);
NS_ASSERTION(x, "Full-screen state of requesting doc should always change!");
changed.AppendElement(this);
// element, and the full-screen-ancestor styles on ancestors of the element
// in this document.
DebugOnly<bool> x = FullScreenStackPush(aElement);
NS_ASSERTION(x, "Full-screen state of requesting doc should always change!");
changed.AppendElement(this);
// Propagate up the document hierarchy, setting the full-screen element as
// the element's container in ancestor documents. This also sets the
// appropriate css styles as well. Note we don't propagate down the
// document hierarchy, the full-screen element (or its container) is not
// visible there. Stop when we reach the root document.
nsIDocument* child = this;
while (true) {
child->SetFullscreenRoot(fullScreenRootDoc);
NS_ASSERTION(child->GetFullscreenRoot() == fullScreenRootDoc,
"Fullscreen root should be set!");
if (child == fullScreenRootDoc) {
break;
}
nsIDocument* parent = child->GetParentDocument();
Element* element = parent->FindContentForSubDocument(child)->AsElement();
if (static_cast<nsDocument*>(parent)->FullScreenStackPush(element)) {
changed.AppendElement(parent);
child = parent;
} else {
// We've reached either the root, or a point in the doctree where the
// new full-screen element container is the same as the previous
// full-screen element's container. No more changes need to be made
// to the full-screen stacks of documents further up the tree.
break;
}
}
// the element's container in ancestor documents. This also sets the
// appropriate css styles as well. Note we don't propagate down the
// document hierarchy, the full-screen element (or its container) is not
// visible there. Stop when we reach the root document.
nsIDocument* child = this;
while (true) {
child->SetFullscreenRoot(fullScreenRootDoc);
NS_ASSERTION(child->GetFullscreenRoot() == fullScreenRootDoc,
"Fullscreen root should be set!");
if (child == fullScreenRootDoc) {
break;
}
nsIDocument* parent = child->GetParentDocument();
Element* element = parent->FindContentForSubDocument(child)->AsElement();
if (static_cast<nsDocument*>(parent)->FullScreenStackPush(element)) {
changed.AppendElement(parent);
child = parent;
} else {
// We've reached either the root, or a point in the doctree where the
// new full-screen element container is the same as the previous
// full-screen element's container. No more changes need to be made
// to the full-screen stacks of documents further up the tree.
break;
}
}
The FullScreenStackPush function puts a -moz-full-screen pseudoselector
on the element that is fullscreened. That while(true) loop appears to
go up the document tree, and attempt to set -moz-full-screen on the
containing documents if there are any. We also put
-moz-full-screen-ancestor on parent elements of the fullscreened
element.
That -moz-full-screen pseudoclass then has some CSS set on it which
maxes out its z-index, and sets it at 100% width and height,
position:fixed - basically making it consume the whole browser window.
It's after _that_ that we signal to the browser chrome that we need to go into fullscreen mode.
So I think the solution is to detect that we're in the content process,
and signal to the parent to enter and exit fullscreen mode.
Solutions
Q: Where is a good point to forward a fullscreen call to the parent process?
After nsDocument::RequestFullScreen, since this does all of the necessary restyling and modifications on the content.
Q: Hm, so I can message from the child process to the parent to start
full screen... but where do I go from TabParent? What do I call to kick
it off?
Checking out
https://bugzilla.mozilla.org/show_bug.cgi?id=684620..
.
So I can just call RequestFullScreen on the nsDocument, but the browser chrome doesn't go away... interesting.
Q: Why doesn't the browser chrome go away?
Seems like MozEnteredDomFullscreen event isn't being fired.
Q: Can I re-use some of the work done in bug 684620 for my purposes?
Possibly. The observer notifications are being fired on the content side. We'll need the following:
-
Code in the content process to listen for the observer notifications and send messages to the parent process.
-
Message handlers in the parent process to get DOMWindowUtils and call them, like bug 684620 does.
Let's try that - it might be better than trying to add new IPDL plumbing.
So it looks like it kinda works, though it's not clear if the
fullscreen-origin-change notification means something that matters to
Desktop... also, exiting seems to be busted because we fail:
if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
return NS_ERROR_FAILURE;
return NS_ERROR_FAILURE;
in nsGlobalWindow::SetFullScreenInternal, which occurs before
mFullScreen is set, which is what nsGlobalWindow uses to determine
whether or not to exit.
I think I'm blocked on guidance. I need cpearse to help me. I've needinfo'd him in the bug.
From cpearse:
> Hey Chris - I saw that you worked on bug 684620. I'm trying to see if I can
> adapt the solution to desktop.
>
> Does the notion of "fullscreen origins" map nicely to desktop? I'm not sure
> it does - it's not 100% clear to me their purpose having skimmed bug 684620.
> It seems I can indeed count on that "fullscreen-origin-change" observer
> notification to fire if fullscreen is triggered from the DOM, and I can
> certainly forward that to the parent process. Is that advisable? Is
> fullscreen-origin-change something that I can rely on in desktop-land?
Looking at the fullscreen code in nsDocument.cpp, I don't see any reason why fullscreen-origin-change would not be dispatched in desktop Firefox. You should probably test that however.
We'd need to patch the fullscreen code in Firefox to handle fullscreen-origin-change as well. It's in browser-fullScreen.js. For single process Firefox at least.
>
> Also, it seems as if b2g doesn't know (or care) whether or not
> nsGlobalWindow's mFullScreen is,
I think B2G's top level window is fullscreen anyway.
> since setting of it occurs after this
> condition in nsGlobalWindow::SetFullScreenInternal:
>
> if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
> return NS_ERROR_FAILURE;
>
> Which, I *believe* (I haven't tested this theory) will fail in the content
> process on b2g. It certainly does in the content process on desktop. That
> makes exiting fullscreen a bit tricky, since the content process's
> nsGlobalWindow doesn't remember if it's in fullscreen mode or not.
I'm not sure about this.
>
> Anyhow, that's just a bit of a brain-dump.
>
> So, to boil it down - is the work in bug 684620 infrastructure that I can
> rely on for getting the DOM Fullscreen API to work on desktop with remote
> tabs, or do I need to invent my own way (a la my WIP patch)?
I think you should be able to rely on it. We definitely want to be able to share the code paths there.
> adapt the solution to desktop.
>
> Does the notion of "fullscreen origins" map nicely to desktop? I'm not sure
> it does - it's not 100% clear to me their purpose having skimmed bug 684620.
> It seems I can indeed count on that "fullscreen-origin-change" observer
> notification to fire if fullscreen is triggered from the DOM, and I can
> certainly forward that to the parent process. Is that advisable? Is
> fullscreen-origin-change something that I can rely on in desktop-land?
Looking at the fullscreen code in nsDocument.cpp, I don't see any reason why fullscreen-origin-change would not be dispatched in desktop Firefox. You should probably test that however.
We'd need to patch the fullscreen code in Firefox to handle fullscreen-origin-change as well. It's in browser-fullScreen.js. For single process Firefox at least.
>
> Also, it seems as if b2g doesn't know (or care) whether or not
> nsGlobalWindow's mFullScreen is,
I think B2G's top level window is fullscreen anyway.
> since setting of it occurs after this
> condition in nsGlobalWindow::SetFullScreenInternal:
>
> if (mDocShell->ItemType() != nsIDocShellTreeItem::typeChrome)
> return NS_ERROR_FAILURE;
>
> Which, I *believe* (I haven't tested this theory) will fail in the content
> process on b2g. It certainly does in the content process on desktop. That
> makes exiting fullscreen a bit tricky, since the content process's
> nsGlobalWindow doesn't remember if it's in fullscreen mode or not.
I'm not sure about this.
>
> Anyhow, that's just a bit of a brain-dump.
>
> So, to boil it down - is the work in bug 684620 infrastructure that I can
> rely on for getting the DOM Fullscreen API to work on desktop with remote
> tabs, or do I need to invent my own way (a la my WIP patch)?
I think you should be able to rely on it. We definitely want to be able to share the code paths there.
Q: The fullscreen-origin-change event is coming in and being handled fine. But exiting is broken. How should I handle that?
I think we want to special-case the content process and exit early from
nsGlobalWindow::SetFullScreenInternal, but I _think_ I want to see what
b2g does before I do that... I mean, I could _assume_ and try
something. That might be the best way forward until my b2g build is done
and debugged.
Hm. B2G with --enable-debug and --disable-optimize doesn't seem to load up. Trying with just --disable-optimize now.
Q: How does B2G handle this? They're _always_ full screen?
Unsure - I'm building b2g locally, hoping I can attach gdb and figure out wtf is going on there.
Let me try to simulate it in my brain.
Dispatches runnable nsCallRequestFullScreen(aElement), which asynchronously calls
nsDocument::RequestFullScreen
I wonder if it fails here? Is the B2G document a "chrome doc"?
if (nsContentUtils::IsFullscreenApiContentOnly() &&nsContentUtils::IsChromeDoc(this)) {// Block fullscreen requests in the chrome document when the fullscreen API// is configured for content only.LogFullScreenDenied(true, "FullScreenDeniedContentOnly", this);return;}
Probably it is - since we get to the bottom of this function where the fullscreen-origin-change notification gets fired.
Down to (static) nsDocument::SetWindowFullScreen
Dispatches runnablensSetWindowFullScreen
nsGlobalWindow::SetFullScreenInternal
16:17 (cpearce) mconley: pong
16:19 (mconley) cpearce: hiya! I had a few questions about B2G's support for the DOM Fullscreen API, if you have a second. Can I assume that the content process will eventually reach this point if fullscreen is requested from some b2g web app?: http://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#5977
16:20 (mconley) cpearce: I _suspect_ it will, because we dispatch a runnable to get to that method here: http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#11254
16:20 (mconley) cpearce: but if that's the case, won't the content process always fail out once it gets here, since the docshell is definitely not of type chrome?: http://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6004
16:20 (cpearce) mconley: I think it should. note however that full-screen-api.ignore-widgets is set to true on b2g, so it should bail out there.
16:20 (mconley) ohhhh
16:21 (mconley) cpearce: wait - that check for full-screen-api.ignore-widgets occurs _after_ the typeChrome docshell check...
16:21 (cpearce) mconley: basically, we forward the fullscreen request up the tree of documents and across process boundaries, making every doc "fullscreen", until we reach to root.
16:21 (mconley) so you mean the parent process hits that codepath and bails, right?
16:22 (mconley) right, gotcha
16:22 (cpearce) mconley: yeah, basically.
16:22 (cpearce) mconley: is the root document in a content process a chrome document? I'm not sure if it is
16:22 (cpearce) gdb can tell you. ;)
16:23 (mconley) cpearce: I've been trying to get gdb to tell me. I'm having a helluva time getting B2G built. :/
16:23 (cpearce) heh. yeah.
16:29 (mconley) cpearce: can I assume that the best way of finding out for certain is to flash this Flame I'm holding and attach gdb, or is there a faster way of finding out?
16:30 (cpearce) mconley: that's the best way to know for sure. someone who worked on the multi-process iframe/mozbrowser implementation might be able to tell you too.
16:31 (mconley) bz: --^?
16:31 (cpearce) I would guess that only the top level window in the b2g process has a chrome window though.
16:31 (mconley) I would also suspect that
16:32 (mconley) in which case, the child process should probably never enter this function, or it should probably bail out earlier
16:32 (cpearce) mconley: why do you need to know? how is this relevant to making fullscreen work in e10s desktop builds?
16:33 (cpearce) mconley: fullscreen worked in metrofox builds, and I think that was multiprocess too, right?
16:33 (mconley) cpearce: well, that condition is where the content process is failing out, and that occurs _before_ we set mFullScreen in the content process (http://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6026)
16:34 (mconley) and that member is used to determine if we need to exit fullscreen mode if mozCancelFullScreen is called
16:34 (mconley) so I'm trying to find out how all of the consumers of this function work before I start rearranging things
16:34 (cpearce) mconley: the metrofox fullscreen work was done in bug 843849, if it helps.
16:35 (mconley) cool, thanks
16:37 (jdm) cpearce: I'm pretty sure they turned off e10s at some point
16:38 (cpearce) jdm: ok, thanks,
16:39 (cpearce) mconley: so... it's worth pointing out that there's two things called "fullscreen". there's the logical state of being "fullscreen", a property of documents, and then there's whether a window is "fullscreen". For fullscreen to work, all the documents up until the root need to be made logically "fullscreen", and the root chrome window needs to be made "fullscreen". any windows in between...
16:39 (cpearce) ...probably don't matter. so if nsGlobalWindow::SetFullScreenInternal is failing in the content process, it may very well not matter.
16:40 (cpearce) mconley: but I haven't worked on the fullscreen code for over a year, so I could be wrong. ;)
16:41 (mconley) cpearce: heh, it's ok. :)
17:05 (mconley) cpearce: one final question - it looks to me as if the "ask-parent-to-exit-fullscreen" is used to signal to the parent process to exit fullscreen. That makes perfect sense, except that document.mozCancelFullScreen seems to fire that notification as a consequence of calling nsIDocument::ExitFullscreen here: ask-parent-to-exit-fullscreen
17:05 (mconley) er
17:05 (mconley) http://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6043
17:05 (mconley) here
17:05 (mconley) cpearce: and if we're able to get here, that means, I think, that the content process somehow got past this conditional: http://dxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6043
17:05 (mconley) meaning that the toplevel window of the content process must have a typeChrome docshell... no?
17:07 (cpearce) mconley: note that there's two types of "fullscreen mode". there's teh type you get when you press F11, and there's the type when JavaScript calls HTMLElement.mozRequestFullScreen.
17:07 (mconley) cpearce: correct
17:07 (cpearce) mconley: so the nsGlobalWindow entry point to exitFullscreen only happens in tee F11 case, IIRC.
17:08 (cpearce) in the JavaScript case, on exit the entry point is in nsDocument.
17:08 (cpearce) and the nsGlobalWindow code comes at the end of the process.
17:08 (mconley) cpearce: hm, so gdb suggests that, at least on desktop, we enter nsGlobalWindow::SetFullScreenInternal on exit
17:08 (cpearce) process of exiting/entering fullscreen.
17:08 (mconley) oh
17:09 (mconley) cpearce: I see - so by the time we enter this function, on b2g, the event should have already been fired to exit us from fullscreen mode?
17:09 (cpearce) so I don't understand why the code in nsGlobalWindow is relevant here; it's the code that actions the state changes that happen in nsDocument.
17:09 (mconley) and by event, I mean notification
17:10 (cpearce) mconley: well, I think on B2G we don't actually exit fullscreen properly, at a widget level, since the b2g process always runs fullscreen anyway
17:10 (cpearce) mconley: I'm not actually sure what the answer is to your question explicitly, I can't remember exactly how it all works now.
17:11 (mconley) cpearce: alright, let me try a different tack - on b2g, at some point, when document.mozCancelFullScreen is called, a "ask-parent-to-exit-fullscreen" notification is sent. Is that correct?
17:11 (cpearce) yep
17:12 (mconley) cpearce: ok. How do we go from calling mozCancelFullScreen to firing that notification? From what I can tell, that notification gets fired here: http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#10587
17:12 (mconley) and if I trace the callers of the ResetFullScreen function
17:12 (mconley) allll the way up
17:13 (mconley) cpearce: I get these callers that trigger it somehow: http://dxr.mozilla.org/mozilla-central/search?q=%2Bcallers%3A%22nsIDocument%3A%3AExitFullscreen%28class+nsIDocument+*%2C+_Bool%29%22
17:14 (mconley) since nsIDocument::ExitFullscreen seems to be the only caller that makes its way to ResetFullScreen
17:15 (mconley) cpearce: and from what I know, only nsGlobalWindow::SetFullScreenInternal has a path from mozCancelFullScreen to it (though I might be wrong)
17:15 (mconley) and if that's the case, that means that mozCancelFullScreen must call into SetFullScreenInternal, which (after passing the doctype check), calls ExitFullScreen on the nsIDocument.
17:15 (mconley) cpearce: with me so far?
17:17 (mconley) if the above is not the way we go from calling mozCancelFullScreen to firing ask-parent-to-exit-fullscreen, then how else do we get there?
17:18 (cpearce) mconley: no. from what I can tell, script calls nsDocument.mozCancelFullScreen(), which calls through to RestorePreviousFullScreenState(), which dispatches ask-parent-to-rollback-fullscreen notification, which BrowserElementtChildPreload.js listens for and forwards across the process boundarry, where it's picked up again and the process resumes in teh parent process.
17:20 (mconley) cpearce: hm - that's for the "ask-parent-to-rollback-fullscreen" notification. How is the "ask-parent-to-exit-fullscreen" notification gotten to?
17:20 (cpearce) and the ask-parent-to-rollback-fullscreen gets proxies across processes to a nsDocument::RemoteFrameFullscreenReverted() call.
17:22 (cpearce) mconley: I think the ask-parent-to-exit-fullscreen message is a fiat command to exit fullscreen completely, whereas the ask-parent-to-rollback-fullscreen message is a "make the current fullscreen thing no longer fullscreen, and restore the previous thing that was fullscreen to being fullscreen" message. that's the difference between them.
17:22 (mconley) ah, I see
17:22 (mconley) cpearce: (thanks for walking me through all of this, btw)
17:23 (cpearce) so I think you're tracing the "in DOM fullscreen mode and user press F11 to exit fullscreen mode completely" case, which starts in nsGlobalWindow, since the JS event handler for the F11 keypress calls that code directly.
17:23 (mconley) I see
17:23 (cpearce) the JS event handler in chrome code that is.
17:24 (mconley) and since that handler is in the chrome process, we should be all good
17:24 (cpearce) whereas I'm thinking of the DOM content script calling in case.
17:24 (mconley) right
17:24 (mconley) mozCancelFullScreen is what I'm particularly interested in
17:24 (cpearce) yeah, it's relevant in the top level chrome document, but should not be in the content sub process case.
17:24 (mconley) I see
17:24 (mconley) OK
17:25 (cpearce) other than making sure it's remoted down to subprocesses so that they exit DOM fullscreen mode too.
17:25 (cpearce) I thought that would already happen, maybe it doesn't.
17:25 (cpearce) mconley: note, I have a test page at http://pearce.org.nz/f which tests a variety of cases that you may find useful.
17:27 (mconley) cpearce: ok, great, thanks
17:27 (mconley) cpearce: so, last question for the day, I swear
17:27 (cpearce) :)
17:27 (mconley) cpearce: under what conditions do children fire "ask-parent-to-exit-fullscreen"? You said it's a fiat command to fully exit fullscreen everywhere, and that makes sense... but what set of actions causes it to happen?
17:31 (cpearce) mconley I think that happens when the content element that is in fullscreen state is removed from its document.
17:32 (cpearce) mconley: that notification happens on the "fully exit fullscreen" path.
17:32 (mconley) cpearce: I see. Ok, thank you. :) I really appreciate you explaining this all to me! I'll let you get on with your day now. :)
17:32 (cpearce) mconley: fullscreen is recursive. for example you can make a document fullscreen (like a PowerPoint document say), and then make a video inside that fullscreen, and then call mozCancelFullscreen and the previous fullscreen element (the power point) will be fullscreen again. when you "fully exit fullscreen", it calls mozCancelFullscreen in a loop until everything has exited, and the top level...
17:32 (cpearce) ...window is back to windowed mode.
17:33 (mconley) makes sense
17:33 (cpearce) ok, cool.
Q: What notifications from the content process map to what actions?
"fullscreen-origin-change"
Some origin that is not the currently fullscreened one (if any) is requesting fullscreen.
"asks-parent-to-exit-fullscreen"
Content that was in a fullscreen state has been removed from the document.
"ask-parent-to-rollback-fullscreen"
Something that was fullscreen is asking to no longer be full screen.
Q: Why isn't ask-parent-to-rollback-fullscreen being fired?
This is because the notification is wrapped by HasCrossProcessParent,
which fails to be true, because it checks
docShell->GetIsBrowserOrApp().
Q: How can I get HasCrossProcessParent to be true for the top-level docshell of an e10s remote browser?
I've got a solution that's able to get a TabChild from the docshell, and check IsRootContentDocument.
Q: I need the MozEnteredDomFullscreen event to be fired from the window. Why isn't it being fired?
Good question!
Let's monitor what occurs when the event is fired in non-e10s, and when it works, and see if we can
spot the difference.
nsInProcessTabChildGlobal::PreHandleEvent in good case
nsWindowRoot::PreHandleEvent in bad case
Hm - so what is the thing actually getting the event dispatched on, and what is the document?
Grr - ok, so the document is something that nsIDOMWindowUtils knows
about - it must be the document for the window that
nsIDOMWindowUtils is connected to. In that case, that'd be the
XULDocument that remote-browser.xml is inside.
And in that XULDocument, we call RequestFullScreen. And then on that XULDocument, we dispatch MozEnteredDomFullscreen.
And it _looks_ like we attempt to dispatch that event. So what gives? Doesn't seem to be affected by whether or not we're
capturing…
Breakpoints:
b nsDocument::RequestFullScreen
b nsContentUtils::DispatchChromeEvent
b EventDispatcher::Dispatch
b EventTargetChainItem::HandleEventTargetChain
b EventListenerManager::
HandleEventInternal
So it looks like the only node in the event chain is an "nsWindowRoot"
16:21 (mconley) smaug: hey - not sure if you're the right person to
ask about this. I'm working on getting the DOM Fullscreen API to work
with e10s, and I've hit a small snag. I've noticed that if I call
remoteFrameFullscreenChanged(this, someOrigin) on a DOMWindowUtils of
the chrome window from within remote-browser.xml, this event -
MozEnteredDomFullscreen (
http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#11212
), do
16:21 (mconley) esn't get picked up by the capture event handler set on window in browser.js
16:21 (mconley) smaug: I've been debugging it, and it looks like when
we try to dispatch that event, the only element in the "chain" of
elements that we're dispatching things to is an nsWindowRoot
16:22 (mconley) do you know why that might be? I know it's kinda hard without more context
16:22 mt_ has joined (
mt@moz-73A57CE6.meeting.ietf.org
)
16:23 mt_ has left IRC (Quit: Leaving.)
16:23 (smaug) mconley: we dispatch it to chrome event handler?
16:23 (smaug) yes
16:23 mconley nods
16:23 (smaug) nsWindowRoot is the chrome event handler of chrome document
16:24 (mconley) I see - so I guess the problem isn't so much that
nsWindowRoot is in the chain, but rather that it's the _only_ element in
the chain
16:24 (mconley) ok, I'll try to figure out why that is
16:24 (smaug) in this case it would be better to flag the event with mOnlyChromeDispatch = true
16:24 (mconley) well
16:24 (mconley) in the e10s case, sure
16:25 (smaug) mconley: we have two things... DispatchToCrome or some
such, which dispatches to the chrome event handler, and we can flag
events for chrome only dispatch, which just bypasses content
16:25 (smaug) s/Crome/Chrome/
16:25 (mconley) oh, I see
16:25 (smaug) for the flag, see what EventDispatcher::Dispatch does
16:26 (mconley) alright
16:29 (mconley) smaug: ah hah
16:29 (mconley) ok
16:30 (mconley) I think I see what's going on here
16:30 (mconley) yeah, that flag is definitely set to false
16:31 (mconley) which is strange, because we construct the
AsyncEventDispatcher where the 4th argument is "true", which should set
mDispatchChromeOnly to true... hrm...
16:32 (smaug) mconley: unfortunately that one means same as DispatchToChrome
16:32 (mconley) alright
16:32 (mconley) so
16:33 (smaug) (the history is that the flag was added afterwards and has been used very rarely )
16:33 (mconley) smaug: so just so I'm clear - it's _expected_ that
when dispatching to chrome, nsWindowRoot is the only element in the
dispatch chain?
16:34 (smaug) nsWindowRoot is the "chrome event handler" object of the chrome document
16:34 (smaug) so everything is working as expected
16:34 (mconley) OK
16:34 (mconley) cool
16:35 (smaug) we just way need some new form of AsyncEventDispatcher
16:35 (smaug) so that we don't do
http://mxr.mozilla.org/mozilla-central/source/dom/events/AsyncEventDispatcher.cpp#39
16:35 (smaug) but use the flag on events
16:36 (smaug) (I know, this all is a bit messy)
16:36 (mconley) I'm not even 100% sure I know what's going on here.
16:36 (mconley) smaug: but thank you. :)
16:37 (mconley) smaug: but it sounds like you see what the problem is here... is that correct?
16:38 (smaug) the issue is that
http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#11212
dispatches the event to the chrome event handler
16:39 (mconley) smaug: ok, and that's not the case when this method is run for some HTML document?
16:39 (mconley) in the non-e10s case?
16:40 (smaug) mconley: in case the document is a content document (not
a chrome document), we dispatch the event to the TabChildGlobal
16:40 (mconley) ah
16:40 (smaug) and from there to <xul:browser>
16:40 (mconley) ok, that makes sense
16:40 (smaug) and up to chrome document, window and nsWindowRoot
16:40 (mconley) smaug: thank you. :)
16:41 (mconley) right, and that's how browser.js's event handler hears about it
So I think what I need to do is write a variant of AsyncEventDispatcher
that creates the event and sets the mDispatchChromeOnly flag on it, and
dispatches the event asynchronously.
Q: Should I re-jib AsyncEventDispatcher, or create a new one?
Here are the things that currently use AsyncEventDispatcher with true for chrome dispatch only:
Presumably, _none_ of them will work with e10s… is that correct? Not sure. And not sure it matters.
We might just want to introduce a new class AsyncChromeEventDispatcher that takes… something.
Q: Ok, so I modified nsContentUtils::DispatchChromeEvent to
set mOnlyChromeDispatch on the event it dispatches. Why does that
fail?
nsCOMPtr<nsINode> node = do_QueryInterface(aTarget);
if (!node) {
nsCOMPtr<nsPIDOMWindow> win = do_QueryInterface(aTarget);
if (win) {
node = win->GetExtantDoc();
}
}
NS_ENSURE_STATE(node);
We seem to fail here in EventDispatcher::Dispatch. Why?
Hm. So aTarget is the nsWindowRoot, which doesn't QI into an nsINode, nor does it QI into an nsPIDOMWindow.
smaug is saying that we have 2 ways of dispatching chrome-only events:
1) Direct (current) - we send directly to the chrome event handler, which is nsWindowRoot. This bypasses the event handler
2) Bypass content - we send to some node, and it captures down and bubbles up, skipping things that aren't of type chrome.
This second one is the one we want to use.
I've modified the AsyncEventDispatcher so that if we're dispatching to
chrome events only, instead of using
nsContentUtils::DispatchChromeEvent, we dispatch normally, but set
the mOnlyChromeDispatch flag on the event.
Q: How do I connect the parent process signal to the child to exit fullscreen?
I should probably do the same thing that b2g does… let me see what they do.
An "ask-children-to-exit-fullscreen" observer notification is sent along with the document that's dispatching it.
nsIDocument::ExitFullscreen is where the system fullscreen button and Esc or F11 calls into.
ResetFullScreen is entered, so we _do_ fire the observer notification.
Ok great, exiting from the parent is hooked up.
I might actually be able to clean up some FullScreen code in here while I'm at it.
Q: Why aren't the "X is now fullscreen" and "Remember decision" things showing up?
Fuuuu… so the issue here is that the MozEnteredDomFullscreen event is
expected to be dispatched such that the target is the document that
we're full screening.
Because the document is the XUL Document in the case of e10s (since the
actual document is not something that the parent process has direct
access to without CPOWs, so the event didn't bubble up from it)
GREAT - I'm failing a test. :/ Has to do with my AsyncEventDispatcher change. Test is for bug 839103:
b nsIDocument::SetStyleSheetChangeEventsEnabled
b nsDocument::NotifyStyleSheetAdded
Grrr.. I think something funky is going on. I think
AsyncEventDispatcher's old usage of the Chrome event handler is what's
expected here…
So what the hell - what is the difference between the MozEnteredDomFullscreen event and any of the StyleSheet events?
It looks like the issue is that we're failing any of the retargeting
that mOnlyChromeDispatch is supposed to cause, because the ownerDoc
of the target (in this case, an HTMLDocument), is itself an
HTMLDocument - but that HTML document has chrome privileges, so it skips
this bit of code:
if
(!nsContentUtils::IsChromeDoc(doc)) {
nsPIDOMWindow* win = doc ? doc->GetInnerWindow() : nullptr ;
// If we can't dispatch the event to chrome, do nothing.
EventTarget* piTarget = win ? win->GetParentTarget() : nullptr ;
NS_ENSURE_TRUE(piTarget, NS_OK);
// Set the target to be the original dispatch target,
aEvent->target = target;
// but use chrome event handler or TabChildGlobal for event target chain.
target = piTarget;
}
nsPIDOMWindow* win = doc ? doc->GetInnerWindow() : nullptr ;
// If we can't dispatch the event to chrome, do nothing.
EventTarget* piTarget = win ? win->GetParentTarget() : nullptr ;
NS_ENSURE_TRUE(piTarget, NS_OK);
// Set the target to be the original dispatch target,
aEvent->target = target;
// but use chrome event handler or TabChildGlobal for event target chain.
target = piTarget;
}
10:59
(smaug)
mconley: so I would really just have a different version of asyncdispatcher ctor which uses event.mOnlyChromeDispatch
11:00
(mconley)
smaug: ah, instead of wholesale replacement? You mean a separate class
entirely, or another boolean on the AsyncEventDispatcher?
11:00
(smaug)
at least for this fullscreen bug
11:00
(smaug)
another boolean in AsyncED
11:00
(mconley)
smaug: I see, ok. mDispatchChromeOnly is already used... how would I describe what it is that the new boolean does?
11:00
(smaug)
rename mDispatchChromeOnly to mDispatchToChromeEventHandler
11:01
(mconley)
ah hah
11:01
(smaug)
and then add perhaps mOnlyChromeDispatch
11:01
(mconley)
smaug: ok, that sounds workable. Thanks!
11:01
(smaug)
and maybe then for ctor...
11:01
(smaug)
add an enum
11:01
rocketman has joined (chatzilla@
1E0C5781.690004FA.7CCB197A.IP
)
11:01
(mconley)
so it can only be one or the other?
11:01
(smaug)
enum { eDispatchToChromeEventHandler, eOnlyChromeDispatch }
11:01
(smaug)
right
11:02
(mconley)
got it
Done.
GARRARRH - A leak. :/
16:02:50 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, default process 1738 16:02:50 INFO - |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| 16:02:50 INFO - Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 16:02:50 INFO - 0 TOTAL 16 2319383 360362968 78981 (37401.50 +/- 77812.20) 295602811 65364 ( 7482.56 +/- 19112.77) 16:02:50 INFO - 8 AnimationTimeline 32 64 123 2 ( 16.61 +/- 13.17) 19372 2 ( 46.81 +/- 74.52) 16:02:50 INFO - 25 AsyncLatencyLogger 36 36 1 1 ( 1.00 +/- 0.00) 481 1 ( 7.76 +/- 8.09) 16:02:50 INFO - 27 AsyncStatement 52 260 210 5 ( 46.23 +/- 21.37) 26788 5 ( 53.35 +/- 24.15) 16:02:50 INFO - 32 AtomImpl 24 46560 21871 1940 ( 2343.66 +/- 378.04) 2834648 11583 (32535.49 +/- 23972.19) 16:02:50 INFO - 38 AudioChannelService 160 160 1 1 ( 1.00 +/- 0.00) 41 1 ( 3.77 +/- 1.00) 16:02:50 INFO - 52 BackstagePass 40 1480 247 37 ( 132.04 +/- 67.25) 566084 125 ( 779.22 +/- 85.71) 16:02:50 INFO - 75 BufferRecycleBin 24 120 783 5 ( 7.54 +/- 3.27) 20090 5 ( 22.07 +/- 10.51) 16:02:50 INFO - 84 CSSStyleSheet 88 4664 15175 53 ( 220.48 +/- 186.16) 430428 105 ( 1213.17 +/- 1475.41) 16:02:50 INFO - 85 CSSStyleSheetInner 80 2880 7455 36 ( 122.86 +/- 89.55) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 86 CSSSupportsRule 56 56 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 92 CacheObserver 24 24 1 1 ( 1.00 +/- 0.00) 192 1 ( 9.03 +/- 4.14) 16:02:50 INFO - 97 CalculateFrecencyFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 103 CallbackObject 24 1512 87680 63 ( 894.27 +/- 761.33) 326709 63 ( 877.02 +/- 776.16) 16:02:50 INFO - 128 Comment 68 6256 3459 92 ( 187.30 +/- 31.13) 15408 92 ( 195.89 +/- 35.95) 16:02:50 INFO - 132 CondVar 16 16 13736 1 ( 33.90 +/- 8.51) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 133 Connection 112 224 14 2 ( 7.42 +/- 3.73) 5980 8 ( 171.02 +/- 50.21) 16:02:50 INFO - 198 DOMStorageObserver 28 28 1 1 ( 1.00 +/- 0.00) 832 1 ( 5.87 +/- 4.62) 16:02:50 INFO - 202 DR_State 32 32 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 215 DataSourceSurfaceRawData 44 88 641 2 ( 17.40 +/- 13.91) 2853 2 ( 21.30 +/- 12.50) 16:02:50 INFO - 217 DataStoreService 148 148 1 1 ( 1.00 +/- 0.00) 165 1 ( 12.05 +/- 4.03) 16:02:50 INFO - 219 Database 140 140 1 1 ( 1.00 +/- 0.00) 783 4 ( 7.19 +/- 3.82) 16:02:50 INFO - 223 DecodeRequest 36 1908 620 53 ( 73.54 +/- 14.19) 3756 53 ( 75.18 +/- 19.60) 16:02:50 INFO - 232 DirectoryProvider 12 12 1 1 ( 1.00 +/- 0.00) 782 1 ( 2.50 +/- 0.51) 16:02:50 INFO - 238 DocumentRule 44 44 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 239 DocumentType 104 624 1856 6 ( 39.18 +/- 21.84) 11442 6 ( 46.48 +/- 27.57) 16:02:50 INFO - 249 EventListenerManager 92 77096 88078 838 ( 5828.06 +/- 5706.19) 3082459 838 ( 3044.92 +/- 3991.81) 16:02:50 INFO - 255 ExpirationTrackerObserver 16 352 6272 22 ( 155.43 +/- 83.82) 24856 22 ( 313.30 +/- 167.46) 16:02:50 INFO - 261 FallbackEncoding 12 12 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 279 FixupURLFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 282 FontFamilyList 16 384 796569 24 ( 1171.84 +/- 1800.35) 5836 12 ( 25.15 +/- 7.22) 16:02:50 INFO - 285 FragmentOrElement 60 151620 369151 2527 (19265.61 +/- 16350.22) 20188219 5490 (37761.78 +/- 31278.22) 16:02:50 INFO - 287 FrameSequence 8 424 671 53 ( 82.89 +/- 15.62) 671 53 ( 82.89 +/- 15.62) 16:02:50 INFO - 288 FrecencyNotificationFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 294 GenerateGUIDFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 295 GenericFactory 16 32 338 2 ( 169.50 +/- 97.36) 1056047 3 ( 325.95 +/- 27.61) 16:02:50 INFO - 296 GetUnreversedHostFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 305 GroupRule 36 1512 67 42 ( 37.20 +/- 16.86) 199 42 ( 36.14 +/- 17.84) 16:02:50 INFO - 327 HTMLInputElement 276 1380 7387 5 ( 343.33 +/- 237.31) 856014 5 ( 2915.81 +/- 2653.34) 16:02:50 INFO - 353 HTMLStyleElement 100 200 192 2 ( 13.93 +/- 12.66) 11590 4 ( 39.17 +/- 29.70) 16:02:50 INFO - 360 HTMLTextAreaElement 244 244 158 1 ( 8.86 +/- 5.49) 52163 2 ( 112.15 +/- 98.18) 16:02:50 INFO - 378 Image 52 260 19336 5 ( 20.46 +/- 9.71) 124152 5 ( 24.95 +/- 13.57) 16:02:50 INFO - 379 ImageContainer 76 380 783 5 ( 7.54 +/- 3.27) 31223 5 ( 7.12 +/- 2.94) 16:02:50 INFO - 382 ImageFactory 8 40 983 5 ( 8.67 +/- 3.04) 43412 5 ( 8.49 +/- 2.15) 16:02:50 INFO - 383 ImageLoader 120 2400 6243 20 ( 146.31 +/- 83.33) 729254 20 ( 151.18 +/- 87.49) 16:02:50 INFO - 384 ImageObserver 8 40 12227 5 ( 786.25 +/- 946.64) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 386 ImageURL 256 15360 171 60 ( 73.46 +/- 26.24) 110409 217 ( 1481.64 +/- 840.83) 16:02:50 INFO - 387 ImageValue 68 4012 1164 59 ( 222.74 +/- 86.60) 29895 59 ( 218.50 +/- 100.36) 16:02:50 INFO - 391 ImportRule 52 208 98 4 ( 21.01 +/- 12.93) 196 4 ( 21.31 +/- 13.00) 16:02:50 INFO - 392 ImportantRule 16 1360 135 85 ( 70.11 +/- 30.57) 60377 85 ( 246.80 +/- 69.39) 16:02:50 INFO - 395 InMemoryDataSource 120 240 20 2 ( 9.24 +/- 4.79) 2799 1 ( 12.92 +/- 21.41) 16:02:50 INFO - 405 JSEventHandler 24 21264 56981 886 ( 6854.51 +/- 5848.03) 243118 886 ( 6466.72 +/- 5823.87) 16:02:50 INFO - 419 LiteralImpl 12 12 332 1 ( 37.79 +/- 9.09) 11378 1 ( 84.93 +/- 39.17) 16:02:50 INFO - 424 Loader 96 2016 6246 21 ( 134.28 +/- 75.62) 22863 21 ( 147.32 +/- 86.48) 16:02:50 INFO - 425 LocalStoreImpl 40 40 1 1 ( 1.00 +/- 0.00) 218 2 ( 23.00 +/- 16.66) 16:02:50 INFO - 427 MaskLayerImageCache 32 32 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 429 MatchAutoCompleteFunction 12 12 1 1 ( 1.00 +/- 0.00) 9 1 ( 2.65 +/- 1.17) 16:02:50 INFO - 450 MediaRule 44 1100 43 25 ( 24.31 +/- 10.91) 141 25 ( 23.62 +/- 11.48) 16:02:50 INFO - 471 MiscContainer 16 2848 55925 178 ( 2718.29 +/- 2265.06) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 476 Mutex 12 936 98012 78 ( 440.79 +/- 770.98) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 477 NameSpaceRule 48 1824 11181 38 ( 130.62 +/- 203.36) 44639 38 ( 131.64 +/- 203.42) 16:02:50 INFO - 483 NodeInfo 76 41648 90854 548 ( 2266.42 +/- 1327.10) 934428 3953 (23587.85 +/- 18006.72) 16:02:50 INFO - 566 Preferences 32 32 1 1 ( 1.00 +/- 0.00) 250825 2 ( 37.27 +/- 37.76) 16:02:50 INFO - 571 ProcessingInstruction 68 1224 904 18 ( 150.79 +/- 116.87) 24891 18 ( 179.20 +/- 130.45) 16:02:50 INFO - 579 ProtoAndIfaceCache 8 336 5857 42 ( 343.28 +/- 101.64) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 589 RDFServiceImpl 276 276 1 1 ( 1.00 +/- 0.00) 540 6 ( 51.96 +/- 11.78) 16:02:50 INFO - 593 RasterImage 280 14840 140 53 ( 64.83 +/- 24.54) 1711953 53 ( 86.02 +/- 9.81) 16:02:50 INFO - 597 ReentrantMonitor 16 1360 43521 85 ( 207.65 +/- 56.52) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 613 RuleHash 148 3108 118742 21 ( 1000.24 +/- 2288.92) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 630 SVGDocumentWrapper 40 280 11 7 ( 6.13 +/- 2.67) 169 14 ( 18.69 +/- 5.78) 16:02:50 INFO - 632 SVGGraphicsElement 128 1280 4312 10 ( 1785.53 +/- 1152.95) 672880 30 (20701.99 +/- 11828.92) 16:02:50 INFO - 639 SVGSVGElement 268 536 235 2 ( 25.75 +/- 13.43) 127580 22 ( 1135.15 +/- 1515.52) 16:02:50 INFO - 650 SameOriginChecker 16 16 1 1 ( 1.00 +/- 0.00) 420 19 ( 30.62 +/- 9.64) 16:02:50 INFO - 652 SandboxPrivate 40 120 126 3 ( 11.92 +/- 3.81) 75221 3 ( 43.17 +/- 34.51) 16:02:50 INFO - 661 Service 64 64 1 1 ( 1.00 +/- 0.00) 74 4 ( 14.42 +/- 5.62) 16:02:50 INFO - 664 SharedScriptableHelperForJSIID 12 12 1 1 ( 1.00 +/- 0.00) 66417 3 ( 209.48 +/- 63.78) 16:02:50 INFO - 676 SourceSurfaceCairo 36 1836 30418 51 ( 75.35 +/- 13.70) 234181 55 ( 79.33 +/- 11.19) 16:02:50 INFO - 698 StringAdopt 1 2 364872 2 ( 4.66 +/- 5.20) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 703 StyleRule 44 96052 68864 2183 ( 3284.66 +/- 704.50) 3085915 2183 ( 4822.17 +/- 1024.91) 16:02:50 INFO - 714 TelemetryImpl 320 320 1 1 ( 1.00 +/- 0.00) 1450 1 ( 15.09 +/- 9.31) 16:02:50 INFO - 726 ThirdPartyUtil 16 16 1 1 ( 1.00 +/- 0.00) 8172 2 ( 3.50 +/- 0.50) 16:02:50 INFO - 750 URIPrincipalAndCORSModeHashKey 16 144 16111 9 ( 46.57 +/- 25.06) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 753 URLValue 28 14532 3103 519 ( 599.02 +/- 136.89) 153904 519 ( 987.14 +/- 210.99) 16:02:50 INFO - 764 UploadLastDir 20 20 1 1 ( 1.00 +/- 0.00) 2 1 ( 1.33 +/- 0.58) 16:02:50 INFO - 774 ValueObserver 36 12780 396 355 ( 215.06 +/- 120.57) 166981 355 ( 1111.44 +/- 87.96) 16:02:50 INFO - 776 VectorImage 76 532 11 7 ( 6.13 +/- 2.67) 1927503 7 ( 10.19 +/- 1.82) 16:02:50 INFO - 781 VolatileBuffer 16 32 641 2 ( 17.40 +/- 13.91) 2568 4 ( 50.77 +/- 41.02) 16:02:50 INFO - 787 WatchdogManager 56 56 1 1 ( 1.00 +/- 0.00) 5 1 ( 1.67 +/- 0.71) 16:02:50 INFO - 790 WeakReference<ImageContainer> 8 424 141 53 ( 65.03 +/- 24.52) 144 53 ( 65.69 +/- 24.55) 16:02:50 INFO - 793 WeakReference<RasterImage> 8 8 5 1 ( 1.89 +/- 0.78) 14 1 ( 3.41 +/- 1.47) 16:02:50 INFO - 795 WeakReference<imgRequestProxy> 8 776 53670 97 ( 1294.20 +/- 825.31) 268056 194 ( 2589.05 +/- 1650.64) 16:02:50 INFO - 796 WeakReference<imgStatusTracker> 8 904 824 113 ( 157.11 +/- 39.03) 2472 226 ( 309.88 +/- 83.69) 16:02:50 INFO - 797 WeakReference<nsDocShell> 8 160 36440 20 ( 192.29 +/- 119.28) 98816 20 ( 290.87 +/- 171.44) 16:02:50 INFO - 822 XBLChildrenElement 80 4720 11523 59 ( 572.09 +/- 249.29) 83612 67 ( 990.50 +/- 411.48) 16:02:50 INFO - 823 XMLDocument 1096 21920 625 20 ( 63.38 +/- 21.21) 2134484 46 ( 383.47 +/- 166.92) 16:02:50 INFO - 826 XMLStylesheetProcessingInstruction 88 1056 612 12 ( 102.45 +/- 78.81) 23594 12 ( 125.89 +/- 87.17) 16:02:50 INFO - 827 XPCContext 28 28 1490 1 ( 18.01 +/- 8.78) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 829 XPCLocaleCallbacks 28 28 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 830 XPCNativeInterface 20 1280 6316 64 ( 151.52 +/- 26.56) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 831 XPCNativeMember 8 512 249593 64 ( 176.05 +/- 34.75) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 832 XPCNativeScriptableInfo 8 1736 28062 217 ( 4708.98 +/- 2394.67) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 833 XPCNativeScriptableShared 188 3008 28174 16 ( 27.97 +/- 7.02) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 834 XPCNativeSet 8 432 16484 54 ( 157.30 +/- 32.08) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 836 XPCWrappedNative 48 13200 274088 275 ( 7827.64 +/- 5251.47) 1897094 275 ( 7736.33 +/- 5140.42) 16:02:50 INFO - 837 XPCWrappedNativeProto 24 1944 64886 81 ( 2052.15 +/- 812.80) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 838 XPCWrappedNativeScope 68 2856 5843 42 ( 338.53 +/- 101.30) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 839 XPTInterfaceInfoManager 116 116 2 1 ( 0.67 +/- 0.58) 1869 1 ( 2.50 +/- 0.50) 16:02:50 INFO - 844 XULDocument 1296 2592 104 2 ( 22.47 +/- 16.40) 2048131 10 ( 227.82 +/- 163.14) 16:02:50 INFO - 851 bundleCacheEntry_t 28 448 20 16 ( 6.08 +/- 5.22) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 869 imgCacheEntry 36 2160 171 60 ( 70.19 +/- 24.45) 2571 60 ( 163.87 +/- 46.73) 16:02:50 INFO - 872 imgDecoderObserver 8 904 824 113 ( 157.11 +/- 39.03) 1569 113 ( 159.26 +/- 43.24) 16:02:50 INFO - 875 imgRequest 136 8160 171 60 ( 73.39 +/- 26.26) 58555 157 ( 1367.64 +/- 835.02) 16:02:50 INFO - 876 imgRequestProxy 64 6208 53670 97 ( 1294.20 +/- 825.31) 1129366 97 ( 1765.08 +/- 920.89) 16:02:50 INFO - 877 imgStatusTracker 60 6780 824 113 ( 157.11 +/- 39.03) 2368974 113 ( 164.77 +/- 20.93) 16:02:50 INFO - 882 mozHunspellDirProvider 12 12 1 1 ( 1.00 +/- 0.00) 782 1 ( 2.50 +/- 0.51) 16:02:50 INFO - 886 mozJSSubScriptLoader 16 16 5 1 ( 2.78 +/- 1.39) 164 1 ( 18.76 +/- 9.73) 16:02:50 INFO - 893 mozilla::css::Declaration 68 150892 65073 2219 ( 3301.74 +/- 704.80) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 903 nsAnnotationService 36 36 1 1 ( 1.00 +/- 0.00) 28 1 ( 6.25 +/- 3.84) 16:02:50 INFO - 907 nsAppFileLocationProvider 16 16 1 1 ( 1.00 +/- 0.00) 780 1 ( 1.50 +/- 0.50) 16:02:50 INFO - 908 nsAppShellService 32 32 1 1 ( 1.00 +/- 0.00) 7396 1 ( 4.51 +/- 0.53) 16:02:50 INFO - 910 nsAppStartup 48 48 1 1 ( 1.00 +/- 0.00) 7326 2 ( 10.61 +/- 6.15) 16:02:50 INFO - 918 nsAtomList 8 26816 20754 3352 ( 3904.06 +/- 788.62) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 920 nsAttrSelector 32 52896 3992 1653 ( 1703.67 +/- 594.84) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 923 nsAuthURLParser 12 24 2 2 ( 1.50 +/- 0.71) 1632076 2227 ( 2359.57 +/- 753.32) 16:02:50 INFO - 925 nsAutoCopyListener 12 12 1 1 ( 1.00 +/- 0.00) 16508 1 ( 71.88 +/- 75.75) 16:02:50 INFO - 928 nsBaseAppShell 68 68 1 1 ( 1.00 +/- 0.00) 2067825 1 ( 6.53 +/- 1.04) 16:02:50 INFO - 932 nsBaseContentList 28 84 15256 3 ( 351.27 +/- 635.16) 24873 3 ( 387.51 +/- 654.12) 16:02:50 INFO - 935 nsBasePrincipal 16 1216 77493 76 ( 232.95 +/- 98.74) 817779 486 ( 860.72 +/- 193.68) 16:02:50 INFO - 939 nsBasicDecoderSupport 20 20 12154 1 ( 33.61 +/- 53.43) 48616 1 ( 34.36 +/- 53.43) 16:02:50 INFO - 941 nsBidiKeyboard 16 16 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 944 nsBindingManager 48 960 6243 20 ( 147.03 +/- 83.38) 96809 20 ( 293.52 +/- 207.93) 16:02:50 INFO - 946 nsBoxLayout 12 24 2 2 ( 1.50 +/- 0.71) 327498 2 ( 375.22 +/- 127.86) 16:02:50 INFO - 958 nsCSSCounterStyleRule 128 6016 47 47 ( 24.00 +/- 13.71) 95 47 ( 24.66 +/- 13.80) 16:02:50 INFO - 960 nsCSSKeyframeRule 44 1584 41 36 ( 22.85 +/- 12.51) 8057 36 ( 40.57 +/- 3.29) 16:02:50 INFO - 961 nsCSSKeyframesRule 52 780 22 15 ( 13.07 +/- 6.37) 52 15 ( 14.08 +/- 6.86) 16:02:50 INFO - 962 nsCSSRect 32 18176 264844 568 ( 682.12 +/- 42.99) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 963 nsCSSRect_heap 40 22720 1481 568 ( 626.43 +/- 216.92) 299435 572 ( 692.68 +/- 42.85) 16:02:50 INFO - 964 nsCSSRuleProcessor 32 672 20223 21 ( 79.91 +/- 22.28) 40408 21 ( 80.43 +/- 22.27) 16:02:50 INFO - 966 nsCSSSelector 40 248640 60791 6216 ( 7270.21 +/- 1346.10) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 967 nsCSSSelectorList 12 47100 50902 3925 ( 4794.52 +/- 835.13) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 970 nsCSSValue::Array 16 10528 187156 658 ( 1041.05 +/- 133.48) 207268 330 ( 520.52 +/- 69.03) 16:02:50 INFO - 971 nsCSSValueFloatColor 24 10800 522 450 ( 288.65 +/- 159.36) 3980 261 ( 290.91 +/- 45.70) 16:02:50 INFO - 972 nsCSSValueGradient 56 3864 83 69 ( 46.84 +/- 25.27) 166 69 ( 44.10 +/- 24.54) 16:02:50 INFO - 973 nsCSSValueGradientStop 16 3280 243 205 ( 135.73 +/- 74.13) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 974 nsCSSValueList 12 23004 49420 1917 ( 2576.64 +/- 306.77) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 975 nsCSSValueList_heap 20 20220 4780 1011 ( 1442.19 +/- 400.76) 542640 1013 ( 1474.86 +/- 150.48) 16:02:50 INFO - 976 nsCSSValuePair 16 3552 32748 222 ( 271.45 +/- 21.76) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 977 nsCSSValuePairList 20 5460 1037 273 ( 318.83 +/- 85.59) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 978 nsCSSValuePairList_heap 28 4424 461 158 ( 200.66 +/- 71.63) 81545 158 ( 231.69 +/- 15.25) 16:02:50 INFO - 979 nsCSSValuePair_heap 24 3672 460 153 ( 183.41 +/- 60.88) 134735 155 ( 198.08 +/- 13.47) 16:02:50 INFO - 980 nsCSSValueSharedList 12 1080 85398 90 ( 319.67 +/- 124.81) 128864 45 ( 277.14 +/- 125.45) 16:02:50 INFO - 981 nsCSSValueTriplet 24 24 11 1 ( 1.95 +/- 0.74) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 982 nsCSSValueTriplet_heap 32 32 1 1 ( 1.00 +/- 0.00) 424 1 ( 1.50 +/- 0.50) 16:02:50 INFO - 994 nsCategoryObserver 60 240 8 4 ( 4.83 +/- 2.12) 620 4 ( 31.90 +/- 8.68) 16:02:50 INFO - 1000 nsChildContentList 28 392 3161 14 ( 296.11 +/- 312.05) 13826 14 ( 465.60 +/- 632.83) 16:02:50 INFO - 1005 nsClipboard 32 32 1 1 ( 1.00 +/- 0.00) 222 1 ( 6.18 +/- 2.89) 16:02:50 INFO - 1018 nsConsoleMessage 32 192 49 6 ( 6.26 +/- 4.50) 124 6 ( 6.63 +/- 4.18) 16:02:50 INFO - 1019 nsConsoleService 72 72 1 1 ( 1.00 +/- 0.00) 1210 3 ( 5.00 +/- 1.52) 16:02:50 INFO - 1023 nsContentList 68 204 10650 3 ( 52.82 +/- 65.82) 15910 3 ( 64.98 +/- 76.06) 16:02:50 INFO - 1024 nsContentPolicy 28 28 1 1 ( 1.00 +/- 0.00) 5352 1 ( 2.54 +/- 0.55) 16:02:50 INFO - 1032 nsCookiePermission 36 36 1 1 ( 1.00 +/- 0.00) 15 1 ( 4.59 +/- 2.21) 16:02:50 INFO - 1033 nsCookieService 84 84 1 1 ( 1.00 +/- 0.00) 122 1 ( 4.38 +/- 1.55) 16:02:50 INFO - 1040 nsDBusService 24 24 1 1 ( 1.00 +/- 0.00) 2 1 ( 1.33 +/- 0.58) 16:02:50 INFO - 1044 nsDNSService 96 96 1 1 ( 1.00 +/- 0.00) 28886 2 ( 24.88 +/- 0.89) 16:02:50 INFO - 1046 nsDOMCSSAttributeDeclaration 32 640 7304 20 ( 589.79 +/- 454.34) 14906 10 ( 517.78 +/- 453.15) 16:02:50 INFO - 1050 nsDOMClassInfo 20 620 31 31 ( 16.00 +/- 9.09) 33681 55 ( 327.99 +/- 258.48) 16:02:50 INFO - 1051 nsDOMConstructor 24 288 834 12 ( 103.75 +/- 86.61) 3688 12 ( 111.81 +/- 93.58) 16:02:50 INFO - 1054 nsDOMMutationObserver 120 360 287 3 ( 41.85 +/- 28.51) 1089 3 ( 44.04 +/- 32.07) 16:02:50 INFO - 1056 nsDOMNavigationTiming 120 240 4975 2 ( 84.46 +/- 60.43) 24139 2 ( 135.52 +/- 89.78) 16:02:50 INFO - 1062 nsDOMTokenList 32 320 906 10 ( 78.25 +/- 59.24) 2879 10 ( 102.69 +/- 84.05) 16:02:50 INFO - 1068 nsDateTimeFormatUnix 68 68 4 1 ( 1.43 +/- 0.53) 11 1 ( 2.05 +/- 0.74) 16:02:50 INFO - 1069 nsDefaultURIFixup 12 12 1 1 ( 1.00 +/- 0.00) 8610 1 ( 13.37 +/- 10.71) 16:02:50 INFO - 1076 nsDirectoryService 56 56 1 1 ( 1.00 +/- 0.00) 3629 1 ( 7.30 +/- 2.65) 16:02:50 INFO - 1119 nsDocShell::InterfaceRequestorProxy 16 48 1488 3 ( 75.27 +/- 60.17) 273028 3 ( 32.58 +/- 32.24) 16:02:50 INFO - 1123 nsDocument 1096 21920 6243 20 ( 145.47 +/- 83.43) 6864791 46 ( 1111.87 +/- 750.93) 16:02:50 INFO - 1133 nsEffectiveTLDService 52 52 1 1 ( 1.00 +/- 0.00) 2794 3 ( 9.51 +/- 5.76) 16:02:50 INFO - 1136 nsEntropyCollector 1048 1048 1 1 ( 1.00 +/- 0.00) 7 1 ( 2.38 +/- 1.04) 16:02:50 INFO - 1137 nsErrorService 44 44 1 1 ( 1.00 +/- 0.00) 5 1 ( 1.67 +/- 0.71) 16:02:50 INFO - 1138 nsEventListenerThisTranslator 12 12 1 1 ( 1.00 +/- 0.00) 4 1 ( 1.71 +/- 0.76) 16:02:50 INFO - 1141 nsExternalHelperAppService 44 44 1 1 ( 1.00 +/- 0.00) 781 1 ( 4.63 +/- 0.98) 16:02:50 INFO - 1144 nsFaviconService 104 104 1 1 ( 1.00 +/- 0.00) 336 1 ( 8.09 +/- 4.77) 16:02:50 INFO - 1159 nsFocusManager 56 56 1 1 ( 1.00 +/- 0.00) 1539 2 ( 14.52 +/- 9.67) 16:02:50 INFO - 1170 nsFrameLoader 92 184 1402 2 ( 36.65 +/- 29.68) 328476 2 ( 50.22 +/- 58.92) 16:02:50 INFO - 1172 nsFrameMessageManager 88 352 769 4 ( 56.42 +/- 31.54) 154440 6 ( 66.65 +/- 58.11) 16:02:50 INFO - 1185 nsGenericDOMDataNode 64 10368 109374 162 ( 3021.63 +/- 3584.94) 1005667 162 ( 4453.18 +/- 7353.39) 16:02:50 INFO - 1186 nsGenericHTMLElement 76 152 65007 2 ( 2850.10 +/- 4231.46) 3123093 2 ( 6195.63 +/- 13373.60) 16:02:50 INFO - 1190 nsGlobalChromeWindow 536 2144 374 4 ( 54.09 +/- 32.61) 3769525 54 ( 690.87 +/- 617.59) 16:02:50 INFO - 1192 nsGlobalWindow 492 1968 7507 4 ( 131.23 +/- 105.63) 9902022 54 ( 1519.33 +/- 1344.11) 16:02:50 INFO - 1195 nsHTMLCSSStyleSheet 44 880 5654 20 ( 145.13 +/- 86.12) 17204 20 ( 160.87 +/- 87.93) 16:02:50 INFO - 1196 nsHTMLDNSPrefetch::nsDeferrals 4136 4136 1 1 ( 1.00 +/- 0.00) 29460 1 ( 2.00 +/- 0.71) 16:02:50 INFO - 1197 nsHTMLDNSPrefetch::nsListener 12 12 1 1 ( 1.00 +/- 0.00) 1 1 ( 1.00 +/- 0.00) 16:02:50 INFO - 1202 nsHTMLStyleSheet 100 2000 5654 20 ( 145.13 +/- 86.12) 17204 20 ( 160.87 +/- 87.93) 16:02:50 INFO - 1203 nsHTMLStyleSheet::GenericTableRule 12 480 11308 40 ( 290.26 +/- 172.23) 11329 40 ( 291.00 +/- 172.19) 16:02:50 INFO - 1208 nsHashPropertyBag 48 960 14629 20 ( 102.57 +/- 43.51) 112545 20 ( 149.07 +/- 70.01) 16:02:50 INFO - 1214 nsHtml5AttributeName 16 9344 3010 584 ( 1443.28 +/- 761.44) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1217 nsHtml5ElementName 16 6368 419 398 ( 218.50 +/- 124.07) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1218 nsHtml5HtmlAttributes 24 24 16264 1 ( 13.04 +/- 29.39) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1252 nsIDNService 72 72 1 1 ( 1.00 +/- 0.00) 7083 3 ( 5.51 +/- 0.57) 16:02:50 INFO - 1253 nsIOService 104 104 1 1 ( 1.00 +/- 0.00) 3467289 3 ( 23.95 +/- 14.51) 16:02:50 INFO - 1261 nsImageFrame::IconLoad 36 36 1 1 ( 1.00 +/- 0.00) 53 1 ( 6.03 +/- 1.86) 16:02:50 INFO - 1273 nsJAR 112 224 62 2 ( 6.80 +/- 4.29) 3143 2 ( 4.09 +/- 2.90) 16:02:50 INFO - 1274 nsJARChannel 236 4720 13029 20 ( 62.21 +/- 20.72) 38796 20 ( 63.86 +/- 22.60) 16:02:50 INFO - 1278 nsJARProtocolHandler 64 64 1 1 ( 1.00 +/- 0.00) 129318 20 ( 65.52 +/- 19.72) 16:02:50 INFO - 1279 nsJARURI 48 1296 45192 27 ( 115.65 +/- 20.94) 308161 27 ( 119.81 +/- 24.37) 16:02:50 INFO - 1280 nsJISx4051LineBreaker 12 12 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 1282 nsJSCID 52 1612 11293 31 ( 466.61 +/- 267.48) 35839 62 ( 1216.66 +/- 703.80) 16:02:50 INFO - 1286 nsJSID 36 144 30180 4 ( 1565.77 +/- 1568.61) 218188 4 ( 4628.90 +/- 4977.79) 16:02:50 INFO - 1287 nsJSIID 20 2440 11345 122 ( 2499.13 +/- 1432.03) 218037 244 ( 5612.13 +/- 3165.97) 16:02:50 INFO - 1300 nsLayoutStatics 1 1 1 1 ( 1.00 +/- 0.00) 12933 29 ( 291.71 +/- 193.38) 16:02:50 INFO - 1301 nsLayoutStylesheetCache 72 72 1 1 ( 1.00 +/- 0.00) 8 1 ( 4.00 +/- 1.93) 16:02:50 INFO - 1306 nsLoadGroup 8 24 1672 3 ( 87.84 +/- 61.50) 383309 20 ( 413.36 +/- 130.22) 16:02:50 INFO - 1307 nsLoadGroupConnectionInfo 20 60 1672 3 ( 87.84 +/- 61.50) 25816 3 ( 52.93 +/- 36.69) 16:02:50 INFO - 1308 nsLocalFile 124 7192 72261 58 ( 209.01 +/- 86.50) 413002 58 ( 266.28 +/- 205.91) 16:02:50 INFO - 1317 nsMappedAttributes 28 28 42397 1 ( 396.86 +/- 835.22) 87607 1 ( 582.01 +/- 817.00) 16:02:50 INFO - 1319 nsMediaList 32 928 578 29 ( 70.58 +/- 26.17) 1054 33 ( 88.58 +/- 39.67) 16:02:50 INFO - 1328 nsMozIconURI 64 384 872 6 ( 11.77 +/- 1.74) 5344 9 ( 17.50 +/- 2.45) 16:02:50 INFO - 1332 nsMutationReceiver 48 96 140 2 ( 13.55 +/- 11.36) 196 2 ( 14.90 +/- 10.99) 16:02:50 INFO - 1345 nsNativeTheme 112 112 1 1 ( 1.00 +/- 0.00) 5358 1 ( 75.57 +/- 107.99) 16:02:50 INFO - 1346 nsNativeThemeGTK 1176 1176 1 1 ( 1.00 +/- 0.00) 5358 1 ( 75.57 +/- 107.99) 16:02:50 INFO - 1347 nsNavBookmarks 208 208 1 1 ( 1.00 +/- 0.00) 1655 1 ( 5.07 +/- 2.15) 16:02:50 INFO - 1348 nsNavHistory 352 352 1 1 ( 1.00 +/- 0.00) 476 1 ( 5.08 +/- 3.05) 16:02:50 INFO - 1355 nsNetworkManagerListener 24 24 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 1356 nsNoAuthURLParser 12 12 1 1 ( 1.00 +/- 0.00) 115792 29 ( 132.97 +/- 20.99) 16:02:50 INFO - 1359 nsNodeInfoManager 44 1100 6262 25 ( 155.13 +/- 84.69) 195221 553 ( 2284.74 +/- 1323.23) 16:02:50 INFO - 1361 nsNodeWeakReference 16 2784 16658 174 ( 2316.40 +/- 1896.50) 124605 174 ( 1854.35 +/- 1096.44) 16:02:50 INFO - 1362 nsNullPrincipal 20 580 14598 29 ( 190.17 +/- 111.76) 147838 29 ( 221.47 +/- 148.31) 16:02:50 INFO - 1363 nsNullPrincipalURI 40 1120 34059 28 ( 157.71 +/- 102.14) 120137 28 ( 144.15 +/- 95.30) 16:02:50 INFO - 1366 nsObserverService 52 52 1 1 ( 1.00 +/- 0.00) 500411 3 ( 35.52 +/- 26.24) 16:02:50 INFO - 1374 nsOnloadBlocker 12 240 6243 20 ( 146.55 +/- 83.55) 82945 20 ( 166.98 +/- 97.00) 16:02:50 INFO - 1385 nsParserService 12 12 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 1393 nsPermissionManager 100 100 1 1 ( 1.00 +/- 0.00) 87752 2 ( 9.18 +/- 2.84) 16:02:50 INFO - 1394 nsPersistentProperties 80 1760 57 22 ( 27.50 +/- 11.92) 171 22 ( 25.88 +/- 12.67) 16:02:50 INFO - 1408 nsPrefBranch 76 228 328 3 ( 24.47 +/- 5.65) 3261 3 ( 31.59 +/- 12.49) 16:02:50 INFO - 1410 nsPreflightCache 44 44 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1411 nsPreflightCache::CacheEntry 32 3200 129 100 ( 47.72 +/- 37.54) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1414 nsPrincipal 32 2432 77378 76 ( 231.24 +/- 98.14) 816156 486 ( 859.24 +/- 193.23) 16:02:50 INFO - 1415 nsProfiler 20 20 1 1 ( 1.00 +/- 0.00) 722 1 ( 6.18 +/- 1.49) 16:02:50 INFO - 1417 nsProperties 8 480 171 60 ( 73.38 +/- 26.26) 354 60 ( 70.62 +/- 28.40) 16:02:50 INFO - 1420 nsPseudoClassList 12 11664 30944 972 ( 1394.67 +/- 557.95) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1421 nsRDFResource 28 252 428 9 ( 82.16 +/- 37.16) 30307 9 ( 339.86 +/- 126.03) 16:02:50 INFO - 1429 nsRect 16 64 251422343 4 ( 3725.73 +/- 3435.46) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1434 nsRepeatService 24 24 1 1 ( 1.00 +/- 0.00) 68 1 ( 3.05 +/- 0.86) 16:02:50 INFO - 1442 nsRunnable 12 36 1673100 3 ( 52.18 +/- 159.32) 5782439 3 ( 48.69 +/- 145.29) 16:02:50 INFO - 1450 nsSMILAnimationController 160 320 195 2 ( 26.70 +/- 14.95) 274 2 ( 26.70 +/- 13.81) 16:02:50 INFO - 1454 nsSVGElement 84 1512 8114 18 ( 3409.94 +/- 2217.61) 1276292 62 (27970.50 +/- 13887.33) 16:02:50 INFO - 1461 nsSVGRenderingObserver 16 112 108 7 ( 37.39 +/- 19.94) 108 7 ( 37.39 +/- 19.94) 16:02:50 INFO - 1467 nsSampleWordBreaker 12 12 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 1473 nsScriptError 100 24400 4999 244 ( 245.61 +/- 23.10) 20139 244 ( 244.51 +/- 29.82) 16:02:50 INFO - 1475 nsScriptLoader 64 1280 6243 20 ( 146.31 +/- 83.33) 28207 20 ( 129.46 +/- 67.86) 16:02:50 INFO - 1476 nsScriptNameSpaceManager 92 184 2 2 ( 1.50 +/- 0.71) 154 1 ( 2.15 +/- 0.69) 16:02:50 INFO - 1477 nsScriptSecurityManager 36 36 1 1 ( 1.00 +/- 0.00) 89918 4 ( 13.88 +/- 2.29) 16:02:50 INFO - 1487 nsSimpleNestedURI 80 240 2481 3 ( 88.06 +/- 57.86) 189465 7 ( 556.63 +/- 396.81) 16:02:50 INFO - 1489 nsSimpleURI 72 1224 18869 17 ( 379.86 +/- 219.96) 635655 31 ( 1240.67 +/- 875.94) 16:02:50 INFO - 1494 nsSocketTransportService 148 148 1 1 ( 1.00 +/- 0.00) 194734 1 ( 23.82 +/- 6.17) 16:02:50 INFO - 1497 nsStandardURL 184 415104 488969 2256 ( 2492.60 +/- 772.23) 20783958 3580 ( 5483.15 +/- 1422.13) 16:02:50 INFO - 1499 nsStaticCaseInsensitiveNameTable 48 288 6 6 ( 3.50 +/- 1.87) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1502 nsStorageStream 48 288 303 6 ( 94.04 +/- 76.02) 3752 6 ( 104.76 +/- 74.74) 16:02:50 INFO - 1508 nsStringBuffer 8 101224 3906100 12653 (33560.23 +/- 16398.77) 11940639 16929 (58171.87 +/- 31436.71) 16:02:50 INFO - 1509 nsStringBundle 52 1144 62 22 ( 28.42 +/- 12.68) 40997 24 ( 52.04 +/- 9.12) 16:02:50 INFO - 1510 nsStringBundleService 76 76 1 1 ( 1.00 +/- 0.00) 59762 2 ( 6.45 +/- 4.11) 16:02:50 INFO - 1544 nsSupportsCStringImpl 24 1440 4508 60 ( 154.49 +/- 31.98) 16542 60 ( 154.08 +/- 32.10) 16:02:50 INFO - 1554 nsSynthVoiceRegistry 56 56 1 1 ( 1.00 +/- 0.00) 17 1 ( 4.15 +/- 1.42) 16:02:50 INFO - 1555 nsSystemPrincipal 16 16 1 1 ( 1.00 +/- 0.00) 94439 336 ( 1010.12 +/- 555.46) 16:02:50 INFO - 1556 nsTArray_base 4 44976 72927609 11244 (169777.20 +/- 88520.85) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1559 nsTextEditorState 80 480 12605 6 ( 79.53 +/- 88.04) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1560 nsTextFragment 8 1296 109374 162 ( 3024.46 +/- 3584.01) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1563 nsTextNode 68 3128 103024 46 ( 2806.03 +/- 3634.45) 953226 46 ( 4264.46 +/- 7503.09) 16:02:50 INFO - 1566 nsThread 124 372 2267 3 ( 36.45 +/- 6.30) 1831422 9 ( 437.84 +/- 139.72) 16:02:50 INFO - 1571 nsTimerImpl 68 340 113771 5 ( 96.64 +/- 35.64) 717399 5 ( 124.95 +/- 42.13) 16:02:50 INFO - 1583 nsURIHashKey 8 14328 20870 1791 ( 1158.82 +/- 490.73) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1587 nsUnicodeNormalizer 12 12 1 1 ( 1.00 +/- 0.00) 3 1 ( 1.40 +/- 0.55) 16:02:50 INFO - 1598 nsVariant 48 96 66622 2 ( 196.15 +/- 69.37) 326925 2 ( 198.36 +/- 68.65) 16:02:50 INFO - 1599 nsVersionComparatorImpl 12 12 1 1 ( 1.00 +/- 0.00) 20 1 ( 6.10 +/- 2.75) 16:02:50 INFO - 1603 nsVoidArray 4 6948 101195 1737 (13745.47 +/- 11224.33) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1606 nsWeakReference 16 544 43649 34 ( 847.29 +/- 460.07) 797040 80 ( 1834.88 +/- 944.71) 16:02:50 INFO - 1612 nsWindowDataSource 64 64 1 1 ( 1.00 +/- 0.00) 191 1 ( 4.95 +/- 0.80) 16:02:50 INFO - 1613 nsWindowMediator 60 60 1 1 ( 1.00 +/- 0.00) 17535 1 ( 5.87 +/- 7.68) 16:02:50 INFO - 1617 nsWindowWatcher 44 44 1 1 ( 1.00 +/- 0.00) 15410 1 ( 4.10 +/- 5.44) 16:02:50 INFO - 1621 nsXBLDocumentInfo 32 576 47 18 ( 24.42 +/- 9.83) 234517 104 ( 2442.77 +/- 1281.87) 16:02:50 INFO - 1622 nsXBLEventHandler 16 1392 125 87 ( 72.91 +/- 36.85) 291714 87 ( 787.96 +/- 337.20) 16:02:50 INFO - 1623 nsXBLKeyEventHandler 24 240 18 10 ( 10.73 +/- 4.96) 16301 10 ( 101.84 +/- 33.67) 16:02:50 INFO - 1625 nsXBLProtoImpl 32 2496 104 78 ( 59.85 +/- 30.87) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1626 nsXBLProtoImplField 24 6144 286 256 ( 155.56 +/- 87.10) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1627 nsXBLProtoImplMethod 20 9040 557 452 ( 314.50 +/- 169.18) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1628 nsXBLProtoImplProperty 32 8992 365 281 ( 209.10 +/- 110.10) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1629 nsXBLPrototypeBinding 88 10032 181 114 ( 104.02 +/- 49.81) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1630 nsXBLPrototypeResources 12 276 42 23 ( 24.77 +/- 11.68) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1631 nsXBLResource 20 40 48 2 ( 6.50 +/- 2.48) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1632 nsXBLResourceLoader 36 828 42 23 ( 24.77 +/- 11.68) 50 23 ( 26.90 +/- 11.24) 16:02:50 INFO - 1633 nsXBLService 16 16 1 1 ( 1.00 +/- 0.00) 1 1 ( 1.00 +/- 0.00) 16:02:50 INFO - 1634 nsXBLSpecialDocInfo 24 24 1 1 ( 1.00 +/- 0.00) 6 1 ( 2.91 +/- 1.30) 16:02:50 INFO - 1638 nsXBLWindowKeyHandler 28 140 358 5 ( 54.35 +/- 37.70) 47942 35 ( 104.82 +/- 129.28) 16:02:50 INFO - 1643 nsXMLElement 72 13968 27903 194 ( 683.54 +/- 291.27) 536514 738 ( 1734.50 +/- 1155.99) 16:02:50 INFO - 1650 nsXPCComponents 56 2240 1048 40 ( 264.68 +/- 92.64) 35976 43 ( 535.01 +/- 85.70) 16:02:50 INFO - 1651 nsXPCComponentsBase 28 1120 1163 40 ( 265.19 +/- 88.58) 36325 43 ( 539.79 +/- 85.34) 16:02:50 INFO - 1652 nsXPCComponents_Classes 20 640 773 32 ( 206.62 +/- 78.77) 30720 38 ( 854.78 +/- 237.48) 16:02:50 INFO - 1654 nsXPCComponents_Constructor 20 60 274 3 ( 56.33 +/- 33.87) 3014 3 ( 109.41 +/- 53.23) 16:02:50 INFO - 1655 nsXPCComponents_Exception 20 40 3 2 ( 2.00 +/- 0.82) 319 2 ( 9.96 +/- 2.23) 16:02:50 INFO - 1656 nsXPCComponents_ID 20 100 73 5 ( 37.45 +/- 20.08) 1147 5 ( 130.22 +/- 79.28) 16:02:50 INFO - 1657 nsXPCComponents_Interfaces 24 840 911 35 ( 227.93 +/- 82.52) 248731 41 ( 968.96 +/- 216.27) 16:02:50 INFO - 1658 nsXPCComponents_Results 20 420 586 21 ( 141.22 +/- 61.06) 17461 27 ( 506.16 +/- 172.63) 16:02:50 INFO - 1659 nsXPCComponents_Utils 20 720 632 36 ( 233.94 +/- 98.30) 27560 40 ( 697.61 +/- 182.08) 16:02:50 INFO - 1663 nsXPCWrappedJS 60 1140 55467 19 ( 1454.11 +/- 1400.69) 1832582 33 ( 1809.98 +/- 1413.98) 16:02:50 INFO - 1664 nsXPCWrappedJSClass 44 440 6137 10 ( 49.51 +/- 5.27) 548929 19 ( 939.44 +/- 993.80) 16:02:50 INFO - 1665 nsXPConnect 36 36 1 1 ( 1.00 +/- 0.00) 3940213 2 ( 7.48 +/- 0.96) 16:02:50 INFO - 1666 nsXULCommandDispatcher 28 56 104 2 ( 19.40 +/- 13.64) 28304 2 ( 15.70 +/- 14.05) 16:02:50 INFO - 1668 nsXULElement 76 170696 222129 2246 (15601.82 +/- 13499.83) 12726201 4610 (24124.03 +/- 23438.63) 16:02:50 INFO - 1670 nsXULPopupListener 24 936 2109 39 ( 358.43 +/- 254.65) 10513 39 ( 399.32 +/- 296.77) 16:02:50 INFO - 1671 nsXULPopupManager 76 76 1 1 ( 1.00 +/- 0.00) 143 1 ( 4.14 +/- 1.11) 16:02:50 INFO - 1673 nsXULPrototypeAttribute 8 25672 5005 3209 ( 2647.00 +/- 1191.97) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1674 nsXULPrototypeCache 236 236 1 1 ( 1.00 +/- 0.00) 4 1 ( 2.29 +/- 1.11) 16:02:50 INFO - 1675 nsXULPrototypeDocument 48 240 19 5 ( 8.09 +/- 2.85) 1066 14 ( 152.81 +/- 109.83) 16:02:50 INFO - 1676 nsXULPrototypeNode 16 17184 2154 1074 ( 961.67 +/- 357.05) 8837 1074 ( 829.43 +/- 406.53) 16:02:50 INFO - 1677 nsXULTooltipListener 48 48 1 1 ( 1.00 +/- 0.00) 8876 35 ( 467.53 +/- 269.68) 16:02:50 INFO - 1679 nsZipArchive 1084 4336 156 4 ( 13.59 +/- 8.56) 1328 2 ( 108.68 +/- 28.55) 16:02:50 INFO - 1684 nsZipReaderCache 76 76 1 1 ( 1.00 +/- 0.00) 15 1 ( 1.90 +/- 0.72) 16:02:50 INFO - 1708 xpc::CompartmentPrivate 36 1620 5843 45 ( 342.00 +/- 105.22) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - 1710 xptiInterfaceInfo 20 2360 3141 118 ( 337.36 +/- 74.66) 126596 196 ( 2525.30 +/- 1521.23) 16:02:50 INFO - 1711 xptiWorkingSet 88 88 2 1 ( 1.33 +/- 0.58) 0 0 ( 0.00 +/- 0.00) 16:02:50 INFO - nsTraceRefcnt::DumpStatistics: 1711 entries 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 AnimationTimeline (64 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 AsyncLatencyLogger (36 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 AsyncStatement (260 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1940 AtomImpl (46560 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 AudioChannelService (160 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 37 BackstagePass (1480 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 BufferRecycleBin (120 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 53 CSSStyleSheet (4664 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 36 CSSStyleSheetInner (2880 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 CSSSupportsRule (56 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 CacheObserver (24 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 CalculateFrecencyFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 63 CallbackObject (1512 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 92 Comment (6256 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 CondVar (16 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 Connection (224 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 DOMStorageObserver (28 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 DR_State (32 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 DataSourceSurfaceRawData (88 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 DataStoreService (148 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 Database (140 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 53 DecodeRequest (1908 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 DirectoryProvider (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 DocumentRule (44 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 6 DocumentType (624 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 838 EventListenerManager (77096 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 22 ExpirationTrackerObserver (352 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 FallbackEncoding (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 FixupURLFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 24 FontFamilyList (384 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2527 FragmentOrElement (151620 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 53 FrameSequence (424 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 FrecencyNotificationFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 GenerateGUIDFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 GenericFactory (32 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 GetUnreversedHostFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 42 GroupRule (1512 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 HTMLInputElement (1380 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 HTMLStyleElement (200 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 HTMLTextAreaElement (244 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 Image (260 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 ImageContainer (380 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 ImageFactory (40 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 20 ImageLoader (2400 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 5 ImageObserver (40 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 60 ImageURL (15360 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 59 ImageValue (4012 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 4 ImportRule (208 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 85 ImportantRule (1360 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 2 InMemoryDataSource (240 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 886 JSEventHandler (21264 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 LiteralImpl (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 21 Loader (2016 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 LocalStoreImpl (40 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 MaskLayerImageCache (32 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 MatchAutoCompleteFunction (12 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 25 MediaRule (1100 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 178 MiscContainer (2848 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 78 Mutex (936 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 38 NameSpaceRule (1824 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 548 NodeInfo (41648 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 Preferences (32 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 18 ProcessingInstruction (1224 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 42 ProtoAndIfaceCache (336 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 1 RDFServiceImpl (276 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 53 RasterImage (14840 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 85 ReentrantMonitor (1360 bytes) 16:02:50 INFO - TEST-INFO | leakcheck | leaked 21 RuleHash (3108 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 7 SVGDocumentWrapper (280 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 10 SVGGraphicsElement (1280 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 SVGSVGElement (536 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 SameOriginChecker (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 SandboxPrivate (120 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 Service (64 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 SharedScriptableHelperForJSIID (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 51 SourceSurfaceCairo (1836 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 StringAdopt (2 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2183 StyleRule (96052 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 TelemetryImpl (320 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 ThirdPartyUtil (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 9 URIPrincipalAndCORSModeHashKey (144 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 519 URLValue (14532 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 UploadLastDir (20 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 355 ValueObserver (12780 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 7 VectorImage (532 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 VolatileBuffer (32 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 WatchdogManager (56 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 53 WeakReference<ImageContainer> (424 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 WeakReference<RasterImage> (8 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 97 WeakReference<imgRequestProxy> (776 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 113 WeakReference<imgStatusTracker> (904 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 WeakReference<nsDocShell> (160 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 59 XBLChildrenElement (4720 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 XMLDocument (21920 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 12 XMLStylesheetProcessingInstruction (1056 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 XPCContext (28 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 XPCLocaleCallbacks (28 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 64 XPCNativeInterface (1280 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 64 XPCNativeMember (512 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 217 XPCNativeScriptableInfo (1736 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 16 XPCNativeScriptableShared (3008 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 54 XPCNativeSet (432 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 275 XPCWrappedNative (13200 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 81 XPCWrappedNativeProto (1944 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 42 XPCWrappedNativeScope (2856 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 XPTInterfaceInfoManager (116 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 XULDocument (2592 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 16 bundleCacheEntry_t (448 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 60 imgCacheEntry (2160 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 113 imgDecoderObserver (904 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 60 imgRequest (8160 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 97 imgRequestProxy (6208 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 113 imgStatusTracker (6780 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 mozHunspellDirProvider (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 mozJSSubScriptLoader (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2219 mozilla::css::Declaration (150892 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsAnnotationService (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsAppFileLocationProvider (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsAppShellService (32 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsAppStartup (48 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3352 nsAtomList (26816 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1653 nsAttrSelector (52896 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsAuthURLParser (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsAutoCopyListener (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsBaseAppShell (68 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsBaseContentList (84 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 76 nsBasePrincipal (1216 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsBasicDecoderSupport (20 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsBidiKeyboard (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsBindingManager (960 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsBoxLayout (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 47 nsCSSCounterStyleRule (6016 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 36 nsCSSKeyframeRule (1584 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 15 nsCSSKeyframesRule (780 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 568 nsCSSRect (18176 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 568 nsCSSRect_heap (22720 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 21 nsCSSRuleProcessor (672 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6216 nsCSSSelector (248640 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3925 nsCSSSelectorList (47100 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 658 nsCSSValue::Array (10528 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 450 nsCSSValueFloatColor (10800 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 69 nsCSSValueGradient (3864 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 205 nsCSSValueGradientStop (3280 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1917 nsCSSValueList (23004 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1011 nsCSSValueList_heap (20220 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 222 nsCSSValuePair (3552 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 273 nsCSSValuePairList (5460 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 158 nsCSSValuePairList_heap (4424 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 153 nsCSSValuePair_heap (3672 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 90 nsCSSValueSharedList (1080 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsCSSValueTriplet (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsCSSValueTriplet_heap (32 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsCategoryObserver (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 14 nsChildContentList (392 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsClipboard (32 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6 nsConsoleMessage (192 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsConsoleService (72 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsContentList (204 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsContentPolicy (28 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsCookiePermission (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsCookieService (84 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsDBusService (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsDNSService (96 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsDOMCSSAttributeDeclaration (640 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 31 nsDOMClassInfo (620 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 12 nsDOMConstructor (288 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsDOMMutationObserver (360 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsDOMNavigationTiming (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 10 nsDOMTokenList (320 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsDateTimeFormatUnix (68 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsDefaultURIFixup (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsDirectoryService (56 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsDocShell::InterfaceRequestorProxy (48 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsDocument (21920 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsEffectiveTLDService (52 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsEntropyCollector (1048 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsErrorService (44 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsEventListenerThisTranslator (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsExternalHelperAppService (44 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsFaviconService (104 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsFocusManager (56 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsFrameLoader (184 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsFrameMessageManager (352 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 162 nsGenericDOMDataNode (10368 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsGenericHTMLElement (152 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsGlobalChromeWindow (2144 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsGlobalWindow (1968 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsHTMLCSSStyleSheet (880 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsHTMLDNSPrefetch::nsDeferrals (4136 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsHTMLDNSPrefetch::nsListener (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsHTMLStyleSheet (2000 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 40 nsHTMLStyleSheet::GenericTableRule (480 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsHashPropertyBag (960 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 584 nsHtml5AttributeName (9344 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 398 nsHtml5ElementName (6368 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsHtml5HtmlAttributes (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsIDNService (72 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsIOService (104 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsImageFrame::IconLoad (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsJAR (224 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsJARChannel (4720 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsJARProtocolHandler (64 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 27 nsJARURI (1296 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsJISx4051LineBreaker (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 31 nsJSCID (1612 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsJSID (144 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 122 nsJSIID (2440 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsLayoutStatics (1 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsLayoutStylesheetCache (72 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsLoadGroup (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsLoadGroupConnectionInfo (60 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 58 nsLocalFile (7192 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsMappedAttributes (28 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 29 nsMediaList (928 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6 nsMozIconURI (384 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsMutationReceiver (96 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNativeTheme (112 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNativeThemeGTK (1176 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNavBookmarks (208 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNavHistory (352 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNetworkManagerListener (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsNoAuthURLParser (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 25 nsNodeInfoManager (1100 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 174 nsNodeWeakReference (2784 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 29 nsNullPrincipal (580 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 28 nsNullPrincipalURI (1120 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsObserverService (52 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsOnloadBlocker (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsParserService (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsPermissionManager (100 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 22 nsPersistentProperties (1760 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsPrefBranch (228 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsPreflightCache (44 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 100 nsPreflightCache::CacheEntry (3200 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 76 nsPrincipal (2432 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsProfiler (20 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 60 nsProperties (480 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 972 nsPseudoClassList (11664 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 9 nsRDFResource (252 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsRect (64 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsRepeatService (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsRunnable (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsSMILAnimationController (320 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 18 nsSVGElement (1512 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 7 nsSVGRenderingObserver (112 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsSampleWordBreaker (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 244 nsScriptError (24400 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 20 nsScriptLoader (1280 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsScriptNameSpaceManager (184 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsScriptSecurityManager (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsSimpleNestedURI (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 17 nsSimpleURI (1224 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsSocketTransportService (148 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2256 nsStandardURL (415104 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6 nsStaticCaseInsensitiveNameTable (288 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6 nsStorageStream (288 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 12653 nsStringBuffer (101224 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 22 nsStringBundle (1144 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsStringBundleService (76 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 60 nsSupportsCStringImpl (1440 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsSynthVoiceRegistry (56 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsSystemPrincipal (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 11244 nsTArray_base (44976 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 6 nsTextEditorState (480 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 162 nsTextFragment (1296 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 46 nsTextNode (3128 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsThread (372 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 5 nsTimerImpl (340 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1791 nsURIHashKey (14328 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsUnicodeNormalizer (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsVariant (96 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsVersionComparatorImpl (12 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1737 nsVoidArray (6948 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 34 nsWeakReference (544 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsWindowDataSource (64 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsWindowMediator (60 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsWindowWatcher (44 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 18 nsXBLDocumentInfo (576 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 87 nsXBLEventHandler (1392 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 10 nsXBLKeyEventHandler (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 78 nsXBLProtoImpl (2496 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 256 nsXBLProtoImplField (6144 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 452 nsXBLProtoImplMethod (9040 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 281 nsXBLProtoImplProperty (8992 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 114 nsXBLPrototypeBinding (10032 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 23 nsXBLPrototypeResources (276 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsXBLResource (40 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 23 nsXBLResourceLoader (828 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXBLService (16 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXBLSpecialDocInfo (24 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 5 nsXBLWindowKeyHandler (140 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 194 nsXMLElement (13968 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 40 nsXPCComponents (2240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 40 nsXPCComponentsBase (1120 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 32 nsXPCComponents_Classes (640 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3 nsXPCComponents_Constructor (60 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsXPCComponents_Exception (40 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 5 nsXPCComponents_ID (100 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 35 nsXPCComponents_Interfaces (840 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 21 nsXPCComponents_Results (420 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 36 nsXPCComponents_Utils (720 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 19 nsXPCWrappedJS (1140 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 10 nsXPCWrappedJSClass (440 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXPConnect (36 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2 nsXULCommandDispatcher (56 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 2246 nsXULElement (170696 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 39 nsXULPopupListener (936 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXULPopupManager (76 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 3209 nsXULPrototypeAttribute (25672 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXULPrototypeCache (236 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 5 nsXULPrototypeDocument (240 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1074 nsXULPrototypeNode (17184 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsXULTooltipListener (48 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 4 nsZipArchive (4336 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 nsZipReaderCache (76 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 45 xpc::CompartmentPrivate (1620 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 118 xptiInterfaceInfo (2360 bytes) 16:02:51 INFO - TEST-INFO | leakcheck | leaked 1 xptiWorkingSet (88 bytes) 16:02:51 WARNING - TEST-UNEXPECTED-FAIL | leakcheck | 2319383 bytes leaked (AnimationTimeline, AsyncLatencyLogger, AsyncStatement, AtomImpl, AudioChannelService, ...)
Can I use DMD to figure this out? Can I reproduce this locally?
So it doesn't look like I can just flat out reproduce this locally by
running fullscreen tests… at least, not under dom/tests/mochitest.
Ok, boot up my Ubuntu VM and try to reproduce there.
22:53
(khuey)
mconley: I really doubt that xbl:implements nsISupportsWeakReference does the right thing
22:53
(khuey)
so I would start with that
22:54
(mconley)
ah
22:54
(mconley)
khuey: thanks for the pointer. :)
DAMNIT. Nope.
But the ownsWeak stuff I added in browser-child… hrm…
_EXCEPT_ that browser-child should never be opened, since I don't do e10s testing. Garrr.
AH HAH. It's just the fullscreen stuff.
But _which_ fullscreen stuff…
AH HAH.
Relationship to PointerLock
The reason I bring this up is because of:
http://hg.mozilla.org/mozilla-central/file/104254bd1fc8/browser/base/content/browser-fullScreen.js#l374
Where browser-fullScreen.js sends a notification to tell everybody that fullscreen was approved by the user. We pass the document around there… why?
http://hg.mozilla.org/mozilla-central/file/a5a720259d79/content/base/src/nsDocument.cpp#l11574
That's where the notification is handled, in the nsDocument that is the subject of the notification.
Where is gPendingPointerLockRequest coming from? Hm… appears to be a global mozilla::StaticRefPtr on nsPointerLockPermissionRequest.
Ah. That gets added in RequestPointerLock: http://hg.mozilla.org/mozilla-central/file/a5a720259d79/content/base/src/nsDocument.cpp#l11623It's a Runnable, defined here: http://hg.mozilla.org/mozilla-central/file/a5a720259d79/content/base/src/nsDocument.cpp#l11387 . It also implements nsIContentPermissionRequest.
AH-HAH. Here's some code that bails out of the pointer lock permission
request early if it sees that we're trying to enter into Fullscreen,
and we're still waiting on permission:
http://hg.mozilla.org/mozilla-central/file/a5a720259d79/content/base/src/nsDocument.cpp#l11410
So I think that's the other half of the code that's handling the
"fullscreen-approved" notification. We've got this runnable just kinda
sitting there until fullscreen-approved notification is sent. Once
fullscreen-approved is sent, we check to see if we've got a
gPendingPointerLockRequest hanging around that bailed early, and if we
do, we create a clone of it (dunno why we clone, but we do), and then
re-dispatch it.
So this code runs again, and we get past the first check to see if
we're waiting on fullscreen approval because the doc is approved for
fullscreen!
http://hg.mozilla.org/mozilla-central/file/a5a720259d79/content/base/src/nsDocument.cpp#l11418
<-- we go ahead and allow. Boom.
OH… so maybe what I really need to do is send the fullscreen-approved
notification down to the child process by listening for the
notification, and broadcasting my way down.
So the first big problem is that the MozDomEnteredFullscreen event,
which populates FullScreen's fullscreenDoc member, does it by getting
the event target. The problem here is that the event target is the
XULDocument for browser.xul, since the actual full screening is
occurring via DOMWindowUtils.
How come when we request fullscreen from an iframe hosted somewhere else, we don't get permission request?
I think this is because the notification stuff doesn't allow us to tell the difference between documents / origins.
How does the current implementation differentiate between the origins of documents requesting fullscreen?
What goes on is that the C++ code that's doing the fullscreen checks to
see if we're already in fullscreen, and if so, compares the principals
between the previously full screened doc and the new doc. If they're the
same, then we don't fire the MozEnteredDomFullscreen event.
So really, fullscreen-origin-change supplants MozEnteredDomFullscreen.
What I really want to solve in this first iteration is the showing of permission dialogs for subframes requesting permission.
16:58 mconley: billm: hey - do we have any patterns / examples of us
passing unique identifiers for documents back and forth from content to
parent?
16:58 mconley: nsIDocuments
16:59 billm: mconley: you can just pass a cpow I guess
16:59 billm: mconley: what do you need it for
16:59 billm: ?
16:59 mconley: billm: in the fullscreen API, non-e10s relies on a
MozEnteredDomFullScreen event targeted at the requesting document to
bubble up so that we can switch into fullscreen and request permission
from the user
17:00 mconley: on permission approval, sent a observer notification passing the document around
17:00 mconley: and the document listens for that observer
notification, recognizes itself as the subject, and marks itself as
approved
17:00 mconley: kinda hairy
17:00 mconley: (that last bit is in native code)
17:01 billm: mconley: yeah, a cpow should work for that. just keep in
mind that it won't keep the document alive, but I think that's probably
what you want.
17:01 billm: mconley: just pass a cpow for the document to the parent, and then send it back down again later
17:02 mconley: billm: well, it's _slightly_ more tricky than that, I'm
afraid. :/ The b2g team already worked around this by using an observer
notification on the child side, and sending fullscreen events to the
parent. Which is fine, except they don't pass the document around - just
the origin
17:03 billm: mconley: how do they find the document if permission is approved?
17:03 mconley: cpearce said I should probably work off of that, which I
did - I listen for the message from the child, and then use
DOMWindowUtils to trigger fullscreen mode in the parent, which bubbles
MozEnteredDomFullScreen properly (after some tweaking), but the target
is the XUL document of browser.xul, and not the document that actually
requested fullscreen
17:04 mconley: billm: if permission is approved, they do nothing. The
DOM Fullscreen API works by entering you into fullscreen, and _then_
asking for forgiveness with a dialog. So if the user denies permission,
the parent process sends a message to all of the children to rollback
17:05 billm: mconley: I'm having a hard time following. why won't the b2g code work for us?
17:06 mconley: billm: I think it's because we have to do more stuff
17:06 mconley: let me grab a b2g device to test - 1 sec
17:06 billm: mconley: the marking you mentioned?
17:06 mconley: yeah, I think so
17:06 mconley: let me just make sure
17:07 billm: mconley: can you point me to the code?
17:07 mconley: sure, 1 sec
17:10 billm: mconley: actually, give me 5 mins. I'll be right back.
17:10 mconley: np
17:25 billm: mconley: ok, back
17:25 mconley: billm: still getting my ducks in order. :)
17:25 mconley: 5 more minutes from me
17:29 mconley: billm: took me a while to get a Flame that'd work properly - I'm surrounded by busted phones. :/
17:29 mconley: anywho
17:30 mconley: I just tested a Flame, and the DOM Fullscreen API
support is quite a bit less sophisticated than what desktop has
17:30 mconley: and I think that's why I'm running into difficulty
17:31 billm: mconley: ok. so is the issue that cpearce wants you to
use the b2g code, but it doesn't support passing documents around?
17:32 mconley: billm: 100% correct.
17:32 billm: mconley: where is the b2g code?
17:32 mconley: lemme dig that up
17:33 mconley: billm: after some indirection, we end up here after we
call someElement.mozRequestFullScreen():
http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#11061
17:34 mconley: billm: here's the notification that b2g sends out:
http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#11244
17:34 mconley: it's passing the origin around
17:34 mconley: BrowserElementChildPreload.js hears that notification:
http://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChildPreload.js#292
17:35 mconley: sends the async message to the parent
17:35 mconley: which gets handled here:
http://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.jsm#827
17:36 billm: mconley: do you know why you need the document?
17:36 mconley: I think so
17:36 billm: mconley: the b2g code can figure out what tab it's for, which seems like it should be enough
17:37 mconley: the approval dialog that desktop shows is more
complicated than gaia's. In Gaia, if the user denies, we just exit
fullscreen on the last thing that requested fullscreen.
17:37 mconley: on desktop, we do the same thing, except we also allow the user to remember the approval
17:38 mconley: Desktop also supports nested documents requesting
fullscreen, and if the origins are the same, we don't ask for permission
again
17:38 billm: mconley: it seems like you might be able to handle that with the b2g API
17:39 billm: mconley: the permissions manager only cares about the origin I think
17:39 mconley: so if you have a document hosted at
mikeconley.ca
, and an iframe hosted at
mozilla.org
, which has an iframe hosted also at
mozilla.org
, requesting fullscreen permissions on the first
mozilla.org
iframe makes the second iframe also have permission - and that's a thing I don't think b2g supports.
17:39 mconley: almost
17:39 mconley: let me show you were the nsDocument listens for the notification
17:40 mconley: if the document is us, we set a member bool that marks
us as approved, and we do some pointer lock stuff which I think we can
ignore since pointer lock is totally busted right now
17:42 billm: mconley: it looks like maybe that flag is only really needed for the pointer lock business.
http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.h#1565
17:43 mconley: oh. Hm...
17:43 billm: mconley: for most documents it sounds like the permissions API is enough
17:43 mconley: and the permissions API uses origins, right?
17:43 mconley: I would imagine so
17:43 billm: mconley: yeah, pretty much
17:44 mconley: ok. Interesting. That clears things up a bit.
17:44 billm: mconley: it sounds like we'll have to support this
eventually, but maybe only once we support pointer locking (whatever
that is)
17:44 mconley: Although now I might have to re-engineer some pointer
lock stuff if I want to fix this and not break non-e10s...
17:44 billm: mconley: although maybe it would be best to fix pointer locking at the same time?
17:44 billm: I dunno
17:44 mconley: yeah, I also don't know.
17:44 mconley: billm: ok, thanks for the guidance. Much appreciated. :)
17:45 billm: sure
So how about instead of passing a document around, we pass an origin
around. We rewrite the DOM Fullscreen implementation to do the
following:
Either remove MozEnteredDOMFullscreen, or deprecate it in favour of the
fullscreen-origin-change notification. We pass origins instead of
documents.
On approval, we don't send a fullscreen-approved notification. Instead,
we send an async message through the message manager saying that we've
approved the request…
Then content.js picks up that approval, and notifies with its document. This will work for both e10s and non-e10s. Phew.
17:49
(mconley)
billm: hey - do you know what the difference is between
browser/content/content.js and browser/content/browser-child.js? Both
are frame scripts that are run in "content"... but can I assume that
browser-child only ever runs when the content is being run in a separate
process?
17:50
(mconley)
since browser-child.js seems to only ever get loaded in the remote-browser constructor
17:50
(billm)
mconley: yeah, browser-child.js is for stuff we don't use in non-e10s
17:50
(billm)
mconley: content.js and browser-content.js are for both
17:50
(mconley)
I see
17:50
(mconley)
what is the difference between content.js and browser-content.js?
17:51
(billm)
mconley: the last two only differ in that one is for toolkit-level stuff and the other is browser-level stuff
Attack plan:
Don't fire fullscreen-approved in browser-fullScreen.js. Instead, send
async message to current browser that fullscreen was approved.
In content.js, listen for that message, and then send the fullscreen-approved notification, passing the document.
Ensure that fullscreen works for non-e10s.
Switch browser-fullScreen to use the fullscreen-origin-change
notification to trigger the warning instead of MozEnteredDOMFullscreen.
So here we are again with not being able to verify which document is requesting fullscreen.
I wonder if we should be passing the document around as a CPOW instead of the origin, or along _with_ the origin…
What's the scenario here? User triggers fullscreen mode, fullscreen
mode is entered, but before we show the approval dialog, the user
changes the active document. We need to detect this by the time that
enterDomFullscreen is entered, and if we're looking at a different
document, we need to bail out of fullscreen entirely.
So if I'm going to pass the document around… do I want to do that
_with_ the origin? That'd save some CPOW stuff for b2g… I wonder if
there's prior art on passing a JS object thing as data through
nsObserverService from C++? Er, nope - aData has to be a string. No
pointers allowed, except on the subject.
Hm - I can pass the subject up from the fullscreen-origin-change
observer in browser-child.js, and that'd be a CPOW for the document. The
problem is that the responder to that message in remote-browser.xml
calls into nsIDOMWindowUtils remoteFrameFullscreenChanged method,
and I can't pass that CPOW in as the first argument, because that'd fail
this test:
NS_ASSERTION(aElement,"Must pass non-null element to nsDocument::RequestFullScreen");if (!aElement || aElement == GetFullScreenElement()) {return;}if (!aElement->IsInDoc()) {LogFullScreenDenied(true, "FullScreenDeniedNotInDocument", this);return;}if (aElement->OwnerDoc() != this) {LogFullScreenDenied(true, "FullScreenDeniedMovedDocument", this);return;}
Since the ownerDoc in this case would not be the XUL Document, which this is.
Hm, so what are we gonna do? How else can we verify that the document
for which fullscreen-origin-change is firing is still the one that's
being looked at by the user?
14:38
(mconley)
when content requests fullscreen, we enter fullscreen mode, and then
request permission (or rather, forgiveness!) from the user with the
Approve / Deny dialog on top of the fullscreened page
14:39
(mconley)
nsDocuments, after triggering FullScreen in both the document that's
requested fullscreen, as well as the XUL document (which kicks off the
OS's fullscreen support), bubble up a MozEnteredDomFullscreen event,
where the subject is the document that requested fullscreen
14:40
(mconley)
that event is sent directly to the chrome event handler. The code in
browser-fullScreen.js is what listens for that event, and displays the
UI for approving / denying the fullscreen attempt
14:40
(mconley)
so that's the state of the world on non-e10s
14:40
(mrbkap)
ok
14:41
(mconley)
b2g had to solve the multiprocess fullscreen problem. They couldn't
rely on a MozEnteredDomFullscreen event somehow bubbling up to the gaia
system stuff
14:41
(mrbkap)
I guess we don't propagate DOM events via the frame loader?
14:42
(mconley)
their solution was to fire an observer notification with the origin
of the page requesting fullscreen. An observer elsewhere in the child
process hears that notification, and sends an async message to the
parent with the origin
14:42
(mconley)
mrbkap: seems like we don't, no - and even if we did, we'd need access to the document which was the target of the event
14:42
(mrbkap)
ah, true.
14:43
(mconley)
the parent process hears the message, and uses DOMWindowUtils to trigger fullscreen in the parent process
14:43
(mconley)
which triggers yet another notification, which the b2g shell stuff listens for, and bubbles up to gaia
14:43
(mconley)
so
14:43
(mconley)
cpearce suggested I follow the b2g route, and listen for those notifications
14:43
(mconley)
which I have done, and most things are working nicely
14:43
(mconley)
however
14:44
(mconley)
we have some code in browser-fullscreen.js that ensures that the
document that sends the MozEnteredDomFullscreen event still has its
DocShell active before we carry out showing the approval dialog. If it's
not active, we cancel fullscreen entirely.
14:45
(mconley)
I'm not sure where the asynchronicity is in there, but I suppose its
possible for the user to switch tabs or something before the fullscreen
transition completes and the MozEnteredDomFullscreen event is handled by
browser-fullscreen.js.
14:45
(mconley)
Anyhow
14:45
(mconley)
the notifications that b2g uses (and now I use for e10s) do not pass the document - they just pass the origin
14:45
(mconley)
and so I don't think I have a nice way of ensuring that the document
that's requesting fullscreen (which I don't have a reference) still has
its docshell active
14:45
(mconley)
all I have is the origin.
14:46
alex_tz has left IRC (Quit: Leaving.)
14:46
(mrbkap)
mconley: Wait, what's triggering you? This is a message manager message, right?
14:46
(mconley)
I considered passing the document up as a CPOW, but then I realized
that the thing that causes the parent process to enter fullscreen mode,
via nsIDOMWindowUtils, is going to fail out, since it's going to try to
make sure that the document element passed in is a child of the current
document
14:46
(mconley)
mrbkap: yep
14:47
(mrbkap)
mconley: I assume b2g skips the "active" check altogether, huh?
14:47
(mconley)
mrbkap: seems to, yes - their fullscreen implementation seems quite a bit simpler / less developed than desktops.
14:48
(mrbkap)
mconley: I was going to suggest using the message manager's
frameload or something to that effect, but then I realized that this
could be an iframe requesting full screen.
14:48
(mrbkap)
mconley: Or, can iframe's do that?
14:48
(mconley)
yes, iframes can do that
14:48
(mconley)
ooh, wait, that's interesting
14:49
(mconley)
yes, iframes do that, but I think there's a request for fullscreen
that goes up amongst the parents as well. I _think_. The iframe case
isn't too clear to me.
14:50
(mconley)
but that's interesting - I wonder if I can pass the frameloader to
nsIDOMWindowUtils. That way, the subject that I get in the observer
notification I can check against the currently selected tab
frameloader... hmm...
14:50
alex_tz has joined (Adium@
moz-DFAA4E15.p2p.sfo1.mozilla.com
)
14:50
(mconley)
mrbkap: let me give this frameloader thing a shot. I'll probably want to ask cpearce about the iframe case.
14:50
(mconley)
mrbkap: thanks for the idea. :)
So mrbkap's idea is that maybe I can pass along the frame loader to
nsIDOMWindowUtils… and that will get sent out in the
fullscreen-origin-changed notification instead of the Document.
But what about the non-e10s case? What's going to be passed, in that
case, is very much the nsDocument. Maybe we can get it to target the
FrameLoader instead?
The problem is that nsDocument is just going to spew out the XUL document again in the parent process notification. BLARGH.
Hm… I have it working if I notify with the subject being the element requesting fullscreen.
Now, how do I differentiate between windows requesting fullscreen? I
need some way of only notifying in the browser-child where the element
is a child of the content document. How is that going to work for
elements in iframes though?
My solution to that last bit is to compare docshell tree owners.
So… so how come we now run the enterDomFullscreen _before_ the OS
goes into fullscreen? That's screwing up the order of events - we
should enter OS fullscreen first, and THEN ask for approval.
nsCocoaWindow::MakeFullScreen
Not unlike in bug 1050447 that I'm working on simultaneously, I seem
to have rearranged the order of events here. It looks like the thing
that kicks off the fullscreen transition on OSX is occurring… after
enterDomFullscreen runs? Is that even true? Only one way to find out
(whips out debugger). Not a great experience with Browser Toolbox
because I'm using Xcode as well to detect the call to enter OS X's
fullscreen mode, and this is all slow as molasses. *sigh*. I'd
connect a remote, but that seems to be busted on hitting breakpoints…
Blargh, no good - that's hiding the race. Printf it is… I feel like I'm banging rocks together.
nsCocoaWindow::MakeFullScreen setting it to: true
Entered enterDomFullscreen
nsCocoaWindow::MakeFullScreen setting it to: false
MakeFullScreen bailing early 2
windowDidEnterFullScreen
nsCocoaWindow::EnteredFullScreen setting it to: true
nsCocoaWindow::MakeFullScreen setting it to: true
MakeFullScreen bailing early 2
So I think what's happening here is that we ask OS X to enter
fullscreen, and it starts the transition, and then we say "EXIT FULL
SCREEN", and OS X goes, well, I'm not in there yet. And then it
completes the fullscreen transition.
How come this doesn't happen without my patch? Does it have to do with
the timing of when MozEnteredDomFullscreen was being fired?
Ah… MozEnteredDomFullscreen is fired asynchronously with our old
friend AsyncEventDispatcher… and the fullscreen-origin-change
notifications are sent synchronously. I think that's probably it.
Let me confirm… *sigh*, means switching back out of my branch and
recompiling AGAIN. I really should have a separate build folder for this
thing.
Confirmed - this is exactly what's going on:
nsGlobalWindow::SetFullScreenInternal called with true
nsGlobalWindow::SetFullScreenInternal called with true
sCocoaWindow::MakeFullScreen called with: true
sCocoaWindow::EnteredFullScreen called with: true
nsGlobalWindow::SetFullScreenInternal called with true
enterDomFullscreen entered - MozEnteredDomFullScreen must have been called!
I've created an AsyncObserverNotification thing, and that seems
to be helping. I need to figure out how to hold the aSomeData string
inside it. C strings. JOY! Ok… nsDependentString seems to be what I
wanted… to convert from const char16_t* to nsAString& and back
again.
What's the difference between browser-content.js and content.js?
17:49 mconley: billm: hey - do you know what the difference is between
browser/content/content.js and browser/content/browser-child.js? Both
are frame scripts that are run in "content"... but can I assume that
browser-child only ever runs when the content is being run in a separate
process?
17:50 mconley: since browser-child.js seems to only ever get loaded in the remote-browser constructor
17:50 billm: mconley: yeah, browser-child.js is for stuff we don't use in non-e10s
17:50 billm: mconley: content.js and browser-content.js are for both
17:50 mconley: I see
17:50 mconley: what is the difference between content.js and browser-content.js?
17:51 billm: mconley: the last two only differ in that one is for toolkit-level stuff and the other is browser-level stuff
17:51 mconley: ah hah
17:51 mconley: OK
17:51 mconley: I understand. Thanks.
browser-child.js - one per remote-browser
(e10s-only)
content.js - browser-level - 1 per browser.
(both)
browser-content.js - toolkit-level - 1 per browser.
(both)
Memory Leak
billm wants me to go back to using a strong reference for the observer
for "ask-children-to-exit-fullscreen" in browser-fullScreen.js,
but I suspect that will re-add my leak. I need to figure that one out.
Whoa… it seems that if I keep an initting state in FullScreen, that
fixes the leak. Weird… is it possible that FullScreen.init() is getting
called twice? Or, rather, that FullScreen.uninit() is getting called
before FullScreen.init(), and that's causing breakage somehow? Weird!
So I've posted the patch, and let's see what the others think. Asked for review from smaug, billm and felipe.
Hm. Now I'm not so sure how I feel about this solution. I don't like
the fact that I have to do the notification "is this element mine" dance
every time.
What would I do in a perfect world?
In a perfect world…
My document would know whether or not it HasCrossProcessParent…
If cross process parent:
In child:
Bubble up the MozEnteredDomFullscreen, and somehow pass the origin along.
Have browser-child.js hear the event, and dispatch a message to its remote-browser parent, passing the origin.
In parent:
Receive message, call remoteFrameFullscreenChanged which passes the origin
Cause MozEnteredDomFullscreen to be dispatched, this time… passing the origin that remoteFrameFullscreenChanged got.
Hear the message, trigger fullscreen in such a way that we show approval message and can bail out.
Else:
I would bubble an event up, but for Chrome consumers only, passing the origin of the document somehow.
Common:
browser-fullScreen.js sees MozEnteredDomFullscreen and the origin. The
target of the event is either a remote browser some other DOM element.
If remote browser, make sure that it's the currently selected browser
(and bail out of fullscreen if not). If DOM element, see if the docshell
this element belongs to is active (and bail out of fullscreen if not).
Use the origin attached to the MozEnteredDomFullscreen event to display the approval message.
Hrm. I'm not sure how easy it is to attach an origin to an event like
this. You can stash a string in a detail in JS, but it looks harder to
do in C++ land, where this stuff is all done.
Ok, what else.
If cross process parent:
In child:
Find the frame loader owner of the document, and send an async message saying, "request fullscreen", passing origin.
In parent:
Receive message, call remoteFrameFullscreenChanged which passes the origin
Call FullScreen.enterDomFullscreen with origin.
Else:
I have no frame loader owner...
Common:
browser-fullScreen.js sees MozEnteredDomFullscreen and the origin.
The target of the event is either a remote browser some other DOM
element. If remote browser, make sure that it's the currently selected
browser (and bail out of fullscreen if not). If DOM element, see if the
docshell this element belongs to is active (and bail out of fullscreen
if not).
Use the origin attached to the MozEnteredDomFullscreen event to display the approval message.
Maybe model it after DOMWebNotificationClicked?
Let's try this:
MozEnteredDomFullscreen event gets fired in content (whether in a
content process or not). content.js hears about it, and informs
tabbrowser.xml. Tabbrowser.xml then:
- Detects if the browser we got this message from is a remote browser. If so, kicks off the fullscreen transition with DOMWindowUtils
- Calls FullScreen.enterDomFullscreen passing the browser and origin
We take advantage of the fact that the MozEnteredDomFullscreen event
will not be seen by content if chrome kicks it off with DOMWindowUtils.
I think… I think this will work.
What about the other signal though?: "ask-children-to-exit-fullscreen"… I think current approach will work.
Ok, so how do I adapt my current patch to this? I think… I actually think I can throw most of it away. :/
Let's take a look at the current patch and see what I can revert.
Test that content.js can hear MozEnteredDomFullscreen for both e10s and non-e10s, or else this plan falls apart. IT WORKS.
Remove fullscreen-origin-change observer from browser-fullScreen.js
Make enterDomFullscreen take a browser and origin instead. Just make sure the browser is currently active.
Remove AsyncObserverNotification thing.
Revert changes to fullscreen-origin-change notifications.
In content.js, add event listener for MozEnteredDomFullscreen that
sends message to parent, passing the origin of the requesting document.
In tabbrowser.xml add handler for MozEnteredDomFullscreen, which
resolves to browser, and then calls FullScreen.enterDomFullscreen with
browser and origin.
In browser-child.js, rename DOMFullscreenObserver to DOMFullscreenManager.
Test the fullscreen-approval is getting handled by the right document!
Remember:
browser-child.js - one per remote-browser
(e10s-only)
content.js - browser-level - 1 per browser.
(both)
browser-content.js - toolkit-level - 1 per browser.
(both)
Test failure
5240 09:53:04 INFO - 1910 INFO TEST-PASS |
/tests/content/html/content/test/ |
Shouldn't be able to set window fullscreen from content
5241 09:53:04 INFO - 1911 INFO must wait for focus
5242 09:53:04 INFO - 1912 INFO must wait for focus
5243 09:53:04 INFO - 1913 INFO TEST-FAIL |
/tests/content/html/content/test/test_fullscreen-api.html |
fullscreenchange before entering fullscreen complete!
window.fullScreen=true normal=(500,529) outerWidth=500 width=1600
outerHeight=529 height=1200
5244 09:53:04 INFO - 1914 INFO TEST-FAIL |
/tests/content/html/content/test/test_fullscreen-api.html |
fullscreenchange before entering fullscreen complete!
window.fullScreen=true normal=(500,529) outerWidth=500 width=1600
outerHeight=529 height=1200
5245 09:53:04 INFO - 1915 INFO TEST-UNEXPECTED-FAIL |
/tests/content/html/content/test/test_fullscreen-api.html | [multiple]
Both windows should be fullscreen concurrently
Review Feedback
It turns out some of the stuff I added to nsDocument.cpp isn't
necessary. The check for IsRootContentDocument is over the top, and has a
lot of b2g specific stuff in it. Since we've already determined in that
function that there is no document parent, this must be the root
document.
billm came back with some feedback too:
::: toolkit/content/browser-child.js
@@ +399,5 @@
> + // windows' content. We should ignore those. We differentiate by comparing
> + // the docshell tree owners of the element and this browser's content. This
> + // will not be necessary once we fix bug 1053413 and stop using observer
> + // notifications for this stuff.
> + let elementDocShellTreeOwner = aSubject.ownerGlobal
I think we usually use defaultView instead of ownerGlobal for this sort of thing. As far as I know they mean the same thing. And usually we do this sort of comparison with |document.defaultView.top !== content|.
@@ +399,5 @@
> + // windows' content. We should ignore those. We differentiate by comparing
> + // the docshell tree owners of the element and this browser's content. This
> + // will not be necessary once we fix bug 1053413 and stop using observer
> + // notifications for this stuff.
> + let elementDocShellTreeOwner = aSubject.ownerGlobal
I think we usually use defaultView instead of ownerGlobal for this sort of thing. As far as I know they mean the same thing. And usually we do this sort of comparison with |document.defaultView.top !== content|.
::: browser/base/content/browser-fullScreen.js
@@ +227,3 @@
> }
> +
> + case "ask-children-to-exit-fullscreen": {
I think it would be cleaner to put the observer in remote-browser.xml. The code seems to fit better there. Generally there's a connection:
browser.js <-> content.js
remote-browser.xml <-> browser-child.js
browser.xml <-> browser-content.js
And, in general, it's nice if the only code sending messages to a content script on the right is the code on the left. Otherwise the message becomes part of the API, which doesn't seem great.
@@ +454,5 @@
> rememberCheckbox.removeAttribute("hidden");
>
> // Note we only allow documents whose principal's URI has a host to
> // store permission grants.
> + let uri = BrowserUtils.makeURI(aOrigin);
Why not move this up and leave the uri/host stuff as is?
@@ +438,4 @@
> let hostLabel = document.getElementById("full-screen-domain-text");
> let rememberCheckbox = document.getElementById("full-screen-remember-decision");
> let isApproved = false;
> + if (aOrigin) {
It seems like you're changing the meaning of this test. Previously we tested whether the URI has a null host (like a file: URL I'm guessing). Now we're just testing if the URI is empty.
::: browser/base/content/content.js
@@ +586,5 @@
> + handleEvent: function(aEvent) {
> + if (aEvent.type == "MozEnteredDomFullscreen") {
> + this._fullscreenDoc = aEvent.target;
> + sendAsyncMessage("MozEnteredDomFullscreen", {
> + origin: this._fullscreenDoc.documentURI.toLowerCase(),
Why toLowercase()? Also, I usually think of an origin as some combination of the host and port, whereas this is the full URI. Maybe change the name to documentURI?
@@ +227,3 @@
> }
> +
> + case "ask-children-to-exit-fullscreen": {
I think it would be cleaner to put the observer in remote-browser.xml. The code seems to fit better there. Generally there's a connection:
browser.js <-> content.js
remote-browser.xml <-> browser-child.js
browser.xml <-> browser-content.js
And, in general, it's nice if the only code sending messages to a content script on the right is the code on the left. Otherwise the message becomes part of the API, which doesn't seem great.
@@ +454,5 @@
> rememberCheckbox.removeAttribute("hidden");
>
> // Note we only allow documents whose principal's URI has a host to
> // store permission grants.
> + let uri = BrowserUtils.makeURI(aOrigin);
Why not move this up and leave the uri/host stuff as is?
@@ +438,4 @@
> let hostLabel = document.getElementById("full-screen-domain-text");
> let rememberCheckbox = document.getElementById("full-screen-remember-decision");
> let isApproved = false;
> + if (aOrigin) {
It seems like you're changing the meaning of this test. Previously we tested whether the URI has a null host (like a file: URL I'm guessing). Now we're just testing if the URI is empty.
::: browser/base/content/content.js
@@ +586,5 @@
> + handleEvent: function(aEvent) {
> + if (aEvent.type == "MozEnteredDomFullscreen") {
> + this._fullscreenDoc = aEvent.target;
> + sendAsyncMessage("MozEnteredDomFullscreen", {
> + origin: this._fullscreenDoc.documentURI.toLowerCase(),
Why toLowercase()? Also, I usually think of an origin as some combination of the host and port, whereas this is the full URI. Maybe change the name to documentURI?
I just ended up getting the fullscreenDoc's nodePrincipal origin instead and passing that.
::: browser/base/content/tabbrowser.xml
@@ +3108,5 @@
> this.selectedTab = tab;
> window.focus();
> break;
> }
> + case "MozEnteredDomFullscreen": {
Why put this here? It seems like it would fit better in browser-fullScreen.js.
> this.selectedTab = tab;
> window.focus();
> break;
> }
> + case "MozEnteredDomFullscreen": {
Why put this here? It seems like it would fit better in browser-fullScreen.js.
Hmm… so maybe put the window-level message listener in browser-fullScreen.js?
Feedback addressed. Let's see what billm says.
He likes it! And apparently, he has browser review powers on stuff
he's comfortable with, which includes this. So I'm good to land.
I think I'll do one more try push to be safe though.
Ha, whoops - pushed an extra patch that broke the world.
remote: You can view the progress of your build at the following URL:
remote: https://tbpl.mozilla.org/?tree=Try&rev=91f00f0a73c1
remote: Alternatively, view them on Treeherder (experimental):
remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=91f00f0a73c1
remote: https://tbpl.mozilla.org/?tree=Try&rev=91f00f0a73c1
remote: Alternatively, view them on Treeherder (experimental):
remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=91f00f0a73c1
FINGERS CROSSED.
Checklist
Clean up the delayedStartup fullscreen stuff and global events, toss them into FullScreen off of init()
Split into 2 patches - AsyncEventDispatcher stuff, and then Fullscreen stuff
Run fullscreen tests for non-e10s and make sure we're still good. Do a try build maybe.
Examine try build results:
https://tbpl.mozilla.org/?tree=Try&rev=5bd8fdb00133
Examine more try build results - now with hopefully less leakage:
https://tbpl.mozilla.org/?tree=Try&rev=cb08301796ea
AGAIN. Now with even MORE less leakage.
https://tbpl.mozilla.org/?tree=Try&rev=b3c0a484bfdb
Ok… just the fullscreen stuff, without event changes:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=0fbeb24db287
And just the AsyncDispatch stuff...
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=043be49589fa
Neutered fullscreen stuff:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=2d2372260b07
Put the FullScreen.init stuff back to see if that's where it's coming from…:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=70caadcacaca
Make the FullScreen object support weak references:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=07650f6e814c
Make sure the altogether try push isn't leaky and passes all tests:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=f6ee3cb79df0
Find a reviewer for the fullscreen stuff
Address all review feedback
See if leak is fixed:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=edfdc1db1eef
See if the if(initted) thing fixed the leak.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=68ccd71d037e
Fix leak…
Fix tests
See if tests are fixed:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=857d380eb369
Maybe re-organize things now that I understand content.js and browser-content.js more now.
Testing