Bug 1722880 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to :Gijs (he/him) from comment #7)
> (In reply to Bob Owen (:bobowen) from comment #6)

...
> > The **really** weird thing is to quote from my previous comment - "This appears to work, but the really bizarre bit is, if I try and debug this, when the `PDFJS:Parent:removeEventListener` message arrives in `receiveMessage` in the debugger, both `this._boundToFindbar` and `this._boundToTab` are already null, so it doesn't appear to remove any listeners in either scenario. But I think they must be being removed otherwise things would still be broken."
> 
> I would add logging to check the same thing, to see if it's a debugger thing. I don't really know exactly how it works, but I think the debugger doesn't fully pause the parent process (if it did, its own debugging code couldn't run) and so weird things can happen if other C++ code ends up triggering more JS code that runs while the debugger is "paused" on the JS code you're debugging.

Good call, when I added logging, `_removeEventListener` was being called twice once from `receiveMessage` (from the child) and once from `didDestroy`???
The debugger was only catch the one in  `receiveMessage` and the other had already happened.

So, I commented out the send of `PDFJS:Parent:removeEventListener` in `PdfjsChild` (the unload listener was still there) and sure enough `didDestroy` was still called and the findbar worked after the navigation.

However I then removed the unload listener in `PdfjsChild` and `didDestroy` stopped being called in `PdfjsParent`.
(Which in a weird way I was quite happy about because I could have sworn it wasn't working originally and indeed it wasn't.)
So, somehow having the unload listener in the child causes `didDestroy` to be called in the parent - does that give you any more of a clue?
(In reply to :Gijs (he/him) from comment #7)
> (In reply to Bob Owen (:bobowen) from comment #6)

...
> > The **really** weird thing is to quote from my previous comment - "This appears to work, but the really bizarre bit is, if I try and debug this, when the `PDFJS:Parent:removeEventListener` message arrives in `receiveMessage` in the debugger, both `this._boundToFindbar` and `this._boundToTab` are already null, so it doesn't appear to remove any listeners in either scenario. But I think they must be being removed otherwise things would still be broken."
> 
> I would add logging to check the same thing, to see if it's a debugger thing. I don't really know exactly how it works, but I think the debugger doesn't fully pause the parent process (if it did, its own debugging code couldn't run) and so weird things can happen if other C++ code ends up triggering more JS code that runs while the debugger is "paused" on the JS code you're debugging.

Good call, when I added logging, `_removeEventListener` was being called twice, once from `receiveMessage` (from the child) and once from `didDestroy`???
The debugger was only catch the one in  `receiveMessage` and the other had already happened.

So, I commented out the send of `PDFJS:Parent:removeEventListener` in `PdfjsChild` (the unload listener was still there) and sure enough `didDestroy` was still called and the findbar worked after the navigation.

However I then removed the unload listener in `PdfjsChild` and `didDestroy` stopped being called in `PdfjsParent`.
(Which in a weird way I was quite happy about because I could have sworn it wasn't working originally and indeed it wasn't.)
So, somehow having the unload listener in the child causes `didDestroy` to be called in the parent - does that give you any more of a clue?
(In reply to :Gijs (he/him) from comment #7)
> (In reply to Bob Owen (:bobowen) from comment #6)

...
> > The **really** weird thing is to quote from my previous comment - "This appears to work, but the really bizarre bit is, if I try and debug this, when the `PDFJS:Parent:removeEventListener` message arrives in `receiveMessage` in the debugger, both `this._boundToFindbar` and `this._boundToTab` are already null, so it doesn't appear to remove any listeners in either scenario. But I think they must be being removed otherwise things would still be broken."
> 
> I would add logging to check the same thing, to see if it's a debugger thing. I don't really know exactly how it works, but I think the debugger doesn't fully pause the parent process (if it did, its own debugging code couldn't run) and so weird things can happen if other C++ code ends up triggering more JS code that runs while the debugger is "paused" on the JS code you're debugging.

Good call, when I added logging, `_removeEventListener` was being called twice, once from `receiveMessage` (from the child) and once from `didDestroy`???
The debugger was only catching the one in  `receiveMessage` and the other had already happened.

So, I commented out the send of `PDFJS:Parent:removeEventListener` in `PdfjsChild` (the unload listener was still there) and sure enough `didDestroy` was still called and the findbar worked after the navigation.

However I then removed the unload listener in `PdfjsChild` and `didDestroy` stopped being called in `PdfjsParent`.
(Which in a weird way I was quite happy about because I could have sworn it wasn't working originally and indeed it wasn't.)
So, somehow having the unload listener in the child causes `didDestroy` to be called in the parent - does that give you any more of a clue?

Back to Bug 1722880 Comment 9