Hmmm... I just closed the tab Was on golem.de with machine under heavy load (building) after activating the Flash on the page. Huh… looks like all of the browsers are missing their webNavigation. TabSwitcher assumes the browser we're switching to has a currentURI… but the one I'm looking at doesn't seem to ahve one. The browser doesn't seem to have destructed… https://people.mozilla.org/~sguo/cleopatra/#report=8cd32dddd817eb7d5d2439c95f47b165d6020dec Theory: The <xul:browser> binding has been removed, but the browser is still being referred to. Question: Could this have something to do with pinned tabs? Mossop just saw a loss of aBrowser.webProgress after a crash for his pinned tabs in bug 1175023 , and I see that kbrosnan has pinned tabs in his screenshot:

So perhaps I'll try along that front. Hrm. Nothing yet… blassey has suggested I add and land some logging / instrumentation to try to confirm or discount some theories. There are, as far as I can tell, only two ways an XBL binding can be removed:

Let's look at this second case. What are the bindings we care about: In order: browser.xml#browser
remote-browser.xml#remote-browser
tabbrowser.xml#tabbrowser-remote-browser Where are these styles applied? browser.xml is applied to every <xul:browser>.
remote-browser.xml is never actually applied (except for the view-source case), but extended by tabbrowser-remote-browser.
tabbrowser-remote-browser is only applied when a browser with the remote attribute set to true is a child of .browserStack. Perhaps the problem resides somewhere in the async tab switcher. This thing has some logging facilities… maybe I can augment them. Could it be that the async tab switcher is not prepared for cases where tabs / browsers stop existing?

Come up with logging for theories

Ok, logging is in Nightly's. The trap is set. Let's see what happens. Margaret ran into this during Whistler. I was able to dig into the busted newtab browser with the Browser Toolbox. The bug appears to be that the tabbrowser-browser binding is properly attached, but the binding that we're extending, the base browser binding, is NOT attached.

OK, we can remove the trap now. Or maybe modify it.

let utils = Cc["@mozilla.org/inspector/dom-utils;1"].getService(Ci.inIDOMUtils);

let urls = utils.getBindingURLs(browser);

Ok, new instrumentation patch written. Up for review.

Aaaand landed on integration. Let's see what we get.

Just happened again! But to tabs and not browsers! WTF!

The binding URLs are:

"chrome://browser/content/tabbrowser.xml#tabbrowser-tab"

"chrome://global/content/bindings/tabbox.xml#tab"

"chrome://global/content/bindings/general.xml#control-item"

"chrome://global/content/bindings/general.xml#basetext"

"chrome://global/content/bindings/general.xml#basecontrol"

"ATTRIBUTE_NODE, CDATA_SECTION_NODE, COMMENT_NODE, DOCUMENT_FRAGMENT_NODE, DOCUMENT_NODE, DOCUMENT_POSITION_CONTAINED_BY, DOCUMENT_POSITION_CONTAINS, DOCUMENT_POSITION_DISCONNECTED, DOCUMENT_POSITION_FOLLOWING, DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC, DOCUMENT_POSITION_PRECEDING, DOCUMENT_TYPE_NODE, ELEMENT_NODE, ENTITY_NODE, ENTITY_REFERENCE_NODE, NOTATION_NODE, PROCESSING_INSTRUCTION_NODE, TEXT_NODE, TelemetryStopwatch, _animStartTime, _fullyOpen, _lastAccessed, _mouseenter, _mouseleave, _selected, _tPos, accessKey, addEventListener, align, allowEvents, appendChild, attributes, baseURI, baseURIObject, blur, boxObject, builder, childElementCount, childNodes, children, classList, className, click, clientHeight, clientLeft, clientTop, clientWidth, cloneNode, closest, collapsed, command, compareDocumentPosition, contains, contextMenu, controllers, convertPointFromNode, convertQuadFromNode, convertRectFromNode, crop, database, datasources, dir, disabled, dispatchEvent, doCommand, firstChild, firstElementChild, flex, flexGroup, focus, fontSizeInflation, frameLoader, getAnimations, getAttribute, getAttributeNS, getAttributeNode, getAttributeNodeNS, getBoundMutationObservers, getBoundingClientRect, getBoxQuads, getClientRects, getElementsByAttribute, getElementsByAttributeNS, getElementsByClassName, getElementsByTagName, getElementsByTagNameNS, getEventHandler, getUserData, hasAttribute, hasAttributeNS, hasAttributes, hasChildNodes, height, hidden, id, image, innerHTML, insertAdjacentHTML, insertBefore, isDefaultNamespace, isEqualNode, label, lastAccessed, lastChild, lastElementChild, left, linkedBrowser, localName, lookupNamespaceURI, lookupPrefix, mCorrespondingMenuitem, mOverCloseButton, matches, maxHeight, maxWidth, menu, minHeight, minWidth, mozMatchesSelector, mozRequestFullScreen, mozRequestPointerLock, mozScrollSnap, namespaceURI, nextElementSibling, nextSibling, nodeName, nodePrincipal, nodeType, nodeValue, normalize, observes, onabort, onblur, oncanplay, oncanplaythrough, onchange, onclick, oncontextmenu, ondblclick, ondrag, ondragend, ondragenter, ondragleave, ondragover, ondragstart, ondrop, ondurationchange, onemptied, onended, onerror, onfocus, ongotpointercapture, oninput, oninvalid, onkeydown, onkeypress, onkeyup, onload, onloadeddata, onloadedmetadata, onloadstart, onlostpointercapture, onmousedown, onmouseenter, onmouseleave, onmousemove, onmouseout, onmouseover, onmouseup, onmozfullscreenchange, onmozfullscreenerror, onmozpointerlockchange, onmozpointerlockerror, onpause, onplay, onplaying, onpointercancel, onpointerdown, onpointerenter, onpointerleave, onpointermove, onpointerout, onpointerover, onpointerup, onprogress, onratechange, onreset, onresize, onscroll, onseeked, onseeking, onselect, onshow, onstalled, onsubmit, onsuspend, ontimeupdate, onvolumechange, onwaiting, onwheel, ordinal, orient, outerHTML, owner, ownerDocument, ownerGlobal, pack, parentElement, parentNode, persist, pinned, prefix, previousElementSibling, previousSibling, querySelector, querySelectorAll, ref, releaseCapture, releasePointerCapture, remove, removeAttribute, removeAttributeNS, removeAttributeNode, removeChild, removeEventListener, replaceChild, resource, scroll, scrollBy, scrollByNoFlush, scrollHeight, scrollIntoView, scrollLeft, scrollLeftMax, scrollTo, scrollTop, scrollTopMax, scrollWidth, setAttribute, setAttributeNS, setAttributeNode, setAttributeNodeNS, setCapture, setEventHandler, setIsPrerendered, setPointerCapture, setUserData, statusText, style, swapFrameLoaders, tabIndex, tagName, textContent, tmp, tooltip, tooltipText, top, value, visibleLabel, width"

12:07 PM < Enn > f

12:21 PM < mconley > Enn: let me know if there's anything else I can try

OH SHIT - dholbert just saw this with non-e10s. RUH ROH.

Not an e10s bug!

Patches are up, fools!

GAH. Oranges. 😔 Hitting my assertion a lot. Why? Okay, let’s try to narrow it...

[browser_bug553455.js]

skip-if = buildapp == 'mulet' # Bug 1066070 - I don't think either popup notifications nor addon install stuff works on mulet?

[browser_bug567306.js]

Scope:

GLOBAL: 0x7f6cefc6c060

cached binding: 0x496a470

cached prototype binding: 0x42699b0

cached implementation: 0x426a010

cached binding docinfo: 0x4268f10

cached binding manager: 0x3783f60

The nsXBLBinding that causes the registration of the prototype: 0x5e629c0

It looks as if there’s a stale XBL doc info sticking around… and that’s what we’re getting the out-of-date XBL binding prototype from, and that’s what we’re stashing into the WeakMap...

new binding:  0x26756a0

new binding docinfo: 0x2529760

Document for the docinfo: 0x248cef0

New binding docinfo is created after the flush… put into 0x17c3670… and 0x6082e00...

Why did the XBLDocumentInfo get changed for the bound document? Like, why is the new docinfo needed?

Back to first principles: theories, tests, results.

Theory: After the cache flush, with the XULPrototypeCache empty, nsXBLService::LoadBindingDocumentInfo tries to load up that general.xml binding, doesn’t find it, and so create a new nsXBLDocumentInfo for those bindings, and shoves that into the cache.

Later on, when a pre-existing bound document attempts to create a binding, it checks the cache, and finds the NEW prototype. The problem is that the new prototype doesn’t match the one in the WeakMap.

THE NEW one is in the XULPrototypeCache because of the NEW nsXBLDocumentInfo that gets put in there.

Question:

How and why is the OLD nsXBLDocumentInfo / cachedBinding put into the WeakMap?

Because there is a pre-existing BindingManager for this document scope, and it has its own cache of nsXBLDocumentInfo’s. When the binding is installed for that scope, we use that nsXBLDocumentInfo in order to get at the nsXBLPrototypeBinding.

That happens to get used first, so that’s what gets put into the WeakMap.

Then… how come the new one shows up? Like, how come we do get the same nsXBLDocumentInfo when we try to install the binding that calls the assertion failure?

There’s only one binding manager. And it has a nsXBLDocumentInfo table that never gets cleared. So once it’s set, it’s set.

We load the original nsXBLDocumentInfo and put it in the cache.

We put the nsXBLDocumentInfo into the never-cleared nsXBLDocumentInfo cache.

Cache is flushed.

New nsXBLDocumentInfo X is constructed and put into the cache.

Then, later, a binding for our original nsBindingManager is required, and when it starts to load it, it checks the XUL prototype cache first, and gets a hit! So it uses the NEW one, when in fact, we’d already done a write to the WeakMap using the original.

What is the stack when we add the out-of-date nsXBLPrototypeBinding to the WeakMap after the cache flush?

Front-runner theory:

There are a few players here:

Here’s why I think I’m hitting my assertion:

Huh. If that’s true, why do we even need to clear the WeakMaps?

Okay, now I’ve made it so that we prioritize getting at the nsBindingManager nsXBLDocumentInfo - but I’m still asserting in some cases. What gives?

global: 0x7f07bb39c380

cached binding document info URI: chrome://global/content/bindings/general.xml#iframe

cached binding document info: 0x3bc0be0

cached binding prototype: 0x23bae50

cached binding manager: 0x4c2b410

new binding document info URI: chrome://global/content/bindings/general.xml

new binding document info: 0x53775a0

new binding prototype: 0x6e8f250

new binding manager: 0x4c2b410

new binding bound document: 0x295fc20

new binding manager: 0x50d46a0

When content process starts: 41728

Interesting event: 22769

scope: 0x7f6c6756c060

Proto binding for menulist: 0x42eb1c0

…whoa - maybe _actual_ proto binding for menulist: 0x42ef9d0

Doc info: 0x42e9850

Proto binding manager?: 0x32c27b0