838126 - Can't unlock phone at all ("can't access dead object")

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Andrew Overholt [:overholt]]

Attachment: logcat

I was using my phone as normal (calls, SMSes, browsing, etc.) and it had an uptime of probably a day or two.  The the screen locked due to me leaving it idle for a few minutes.  I went back to it and couldn't unlock it at all.  I can swipe up to reveal the unlock/camera buttons but pressing either of them has no effect.

Bobby said that this means that chrome is touching content.

It's doubtful that I can reproduce this but I thought I'm nom it to get on the radar.

Comment 1

[Justin Lebar (not reading bugmail)]

I don't think we can blocking+ or tracking+ a bug without STR.

The "can't touch dead object" error is coming from BrowserElementScrolling:

>  _resetActive: function cp_resetActive() {
>    let elt = this.target || this.pointerDownTarget;
>    let root = elt.ownerDocument || elt.document;  // <--- error thrown here
>    this._setActive(root.documentElement);
>  },

What this error means is that elt belongs to a document which has since been
destroyed.  In Gaia, this almost certainly means that elt came from an iframe
that has since been navigated or removed from the DOM.

There are a lot of things we don't understand here.  Among them are two key
questions:

1. Why does elt come from a document which has been destroyed?  It seems that
either

  a) this.target / this.pointerDownTarget somehow started pointing to a dead
     document, and then got stuck there.  But we don't see how this could
     happen, since onTouchStart overwrites both this.target and
     this.pointerDownTarget.
     
     Perhaps onTouchStart or one of the functions it calls is throwing an
     exception that is not being reported in logcat for some reason, and
     that's why this.target / this.pointerDownTarget don't change.

  b) this.target / this.pointerDownTarget gets overwritten on every
     touchStart, but then before the touchEnd, the document that the element came
     from gets destroyed.
     
     It seems unlikely that this is happening, because we get the error when
     we swipe up the bar to show the lock/camera buttons and then let go.
     There shouldn't be any iframe creation/deletion involved in that.

2. Why does this exception in BrowserElementScrolling prevent content (i.e.,
Gaia) from handling the touch?  Perhaps the exception in
BrowserElementScrolling is only a symptom of what's going wrong, and not the
cause.

I can paper over this exception in BrowserElementScrolling by checking
Cu.isDeadWrapper() before we touch the element.  That probably won't make the
code any less correct than it currently is.  But given (2), I am not confident
that change would fix anything.

FWIW bz says that _setActive as implemented is dangerous and can cause
incorrect behavior in the event state manager.

>  _setActive: function cp_setActive(elt) {
>    const kStateActive = 0x00000001;
>    this._domUtils.setContentState(elt, kStateActive);
>  },

_domUtils is an instance of the inIDOMUtils interface, which is designed for
debugging only.  In particular, it can cause two nodes to be active at once,
which will cause the event state manager to behave incorrectly.  We don't know
if this is what's causing the problem in this bug.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Fwiw, seems moderately unlikely that the kStateActive thing would cause the issue seen here, now that I have more context...

Comment 3

[Andrew Overholt [:overholt]]

I'm clearing the nom due to no STR on my part.

Comment 4

[BMO Automation]

Firefox OS is not being worked on