1106154 - [e10s] closing tab JUST in the moment it loads and starts rendering (the DOM) freezes Nightly!

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Filip Rydlo]

Attachment: Closing tab - frozen Nightly

1. Use TeamView (if possible) to access the target PC: Any modern AMD CPU, Windows 8.1 (ENGLISH) x64 (clean install, fully updated) with Nightly version 36.0a1_2014-11-22 (x64!) installed.

2. Go to "Options" - "General" and check "Enable E10S (multi-process)". And restart Nighly, to be sure it has fully taken effect from the start of it.
3. Click on the yellow question-mark down there directly in the Options. Or ANY OTHER website will do! ...
4. Click "x" of the new tab while it is still *loading*.
5. Repeat steps 3 and 4 again and AGAIN... , untill you HIT the "X" just in the right milisecond WHEN it has loaded AND has just started to render DOM!

Outcome: Nightly will FREEZ forever. Unresponsive to any clicks or keys, the tab will STILL remain opened, but you cannot switch tabs nor do anything. You have frozen the Nightly - *indefinitely*. (use task manager to kill it).
Expected behavior: Tab should close like it normally does.

Note: There *might* be some race-condition involved! This might be very uneasy to spot and debug.


Suggested FIX:  When the EVENT "close tab" is generated, it should first *check* whether the loading process of the TAB being closed is NOT in any critical phase (careful, it is out of sync = running in a different thread! Use mutex/lock...for data exchange about the phase of loading).
If it is detected that for example the construction of the DOM is in ongoing process, it should "wait"  or generate whole ANOTHER event "POSTPONED CLOSE TAB" and send it to the TAB....... and when the tab finishes any phase, it can CHECK there ... if such an EVENT has been sent to it - and close itself safely FROM WITHIN the same *thread* that is constructing/loading the TAB!  This should work thread-safely. Well, in theory at least... :)

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey Filip - are you able to reproduce this behaviour without connecting to the machine with TeamViewer? Like, are you able to reproduce this if you're sitting in front of the target machine?

Comment 2

[Filip Rydlo]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #1)
> Hey Filip - are you able to reproduce this behaviour without connecting to
> the machine with TeamViewer? Like, are you able to reproduce this if you're
> sitting in front of the target machine?

No. At least not yet. I cannot reproduce it on the *latest* version of Nightly x64 at all. It might be fixed already as a side-effect of some change or some other bugfix.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Assuming TeamViewer was hitting our accessibility API (like RDP does), is it possible that some recent e10s-related change in the accessibility API fixed this, tbsaunde?

Comment 4

[Trevor Saunders (:tbsaunde)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #3)
> Assuming TeamViewer was hitting our accessibility API (like RDP does), is it
> possible that some recent e10s-related change in the accessibility API fixed
> this, tbsaunde?

seems unlikely, but its pretty hard to say anything without a stack or profile.

Comment 5

[Chris Peterson [:cpeterson]]

duping to e10s RDP bug 1096834

Comment 6

[Trevor Saunders (:tbsaunde)]

(In reply to Chris Peterson (:cpeterson) from comment #5)
> duping to e10s RDP bug 1096834


What evidence do we have this is a dup?

Comment 7

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598