Bugzilla

I debugged this a bit more (great work on the earlier debugging BTW). This can only happen because we spin the event loop under the e10s printing code (we should stop doing that, see bug 14328006). Because of that we can end up doing things like processing the a10y events while in the middle of recording the printer output that is to be sent to the parent process. That by itself wouldn't be enough to cause this bug, but what appears to be happening is that the e11y code is running in the statically cloned document that we create to print from. I'm not familiar with the a11y code, but it really shouldn't be touching these static documents at all. I tested adding an early return to NotificationController::WillRefresh and that appears to stop the crash. Let's see what the a11y peers think.

I debugged this a bit more (great work on the earlier debugging BTW). This can only happen because we spin the event loop under the e10s printing code (we should stop doing that, see bug 1432806). Because of that we can end up doing things like processing the a10y events while in the middle of recording the printer output that is to be sent to the parent process. That by itself wouldn't be enough to cause this bug, but what appears to be happening is that the e11y code is running in the statically cloned document that we create to print from. I'm not familiar with the a11y code, but it really shouldn't be touching these static documents at all. I tested adding an early return to NotificationController::WillRefresh and that appears to stop the crash. Let's see what the a11y peers think.

I debugged this a bit more (great work on the earlier debugging BTW). This can only happen because we spin the event loop under the e10s printing code (we should stop doing that, see bug 1432806). Because of that we can end up doing things like processing the a10y events while in the middle of recording the printer output that is to be sent to the parent process. That by itself wouldn't be enough to cause this bug, but what appears to be happening is that the a10y code is running in the statically cloned document that we create to print from. I'm not familiar with the a11y code, but it really shouldn't be touching these static documents at all. I tested adding an early return to NotificationController::WillRefresh and that appears to stop the crash. Let's see what the a11y peers think.

I debugged this a bit more (great work on the earlier debugging BTW). This can only happen because we spin the event loop under the e10s printing code (we should stop doing that, see bug 1432806). Because of that we can end up doing things like processing the a11y events while in the middle of recording the printer output that is to be sent to the parent process. That by itself wouldn't be enough to cause this bug, but what appears to be happening is that the a11y code is running in the statically cloned document that we create to print from. I'm not familiar with the a11y code, but it really shouldn't be touching these static documents at all. I tested adding an early return to NotificationController::WillRefresh and that appears to stop the crash. Let's see what the a11y peers think.