1282265 - Spinner spins forever after switching application, and [x] window caption button would not respond

Status: RESOLVED DUPLICATE of bug 1282580

(Firefox :: Protections UI, defect)

Description

[Alice0775 White]

When I test Bug Bug 1279293 comment#2, I encounter the problem.

Reproducible: always

Steps To Reproduce:
1. enable e10s
2. enable "Tracking Protection" (Options->Privacy:  'Always')

3. Open http://www.mayoclinic.org/diseases-conditions/retrograde-ejaculation/basics/definition/con-20030795 in foreground [Tab 1]
4. Open https://www.mozilla.org/en-US/firefox/50.0a1/tracking-protection/start/?step=2  in foreground [Tab 2]
5. Open http://www.mayoclinic.org/diseases-conditions/retrograde-ejaculation/basics/definition/con-20030795 in foreground [Tab 3]

6. Switch another application, and wait for a while(20-30sec)
7. Back to Nightly by clicking Taskbar Button
8. Close [Tab 2], [Tab3] by click [x] on the tab


Actual Results:
Spinner spins forever

Expected Results:
Not so.

Comment 1

[Alice0775 White]

Attachment: Screenshot

It is fatal as web browser.

Comment 2

[Ciprian Muresan [:cmuresan], Ecosystem QA]

User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0

I have managed to reproduce this issue on the latest Nightly (50.0a1, Build ID 20160629030209).

I got a gecko profile https://cleopatra.io/#report=8db0863a9cc523725f4a86013ed5784b8e7d1a62&selection=0,89,90,91,92,93,94,1,95,96,97,98,99,100,101,102,103,104,197,255,198,256,257,258,259

And I got a regression range:
Last good revision: 83f519eb1a3a (2014-08-09)
First bad revision: 70be728521e3 (2014-08-10)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83f519eb1a3a&tochange=70be728521e3

Bug 1044181 stands out a bit, possibly https://hg.mozilla.org/mozilla-central/rev/bde52b0b5431.

Comment 3

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

That profile in comment 2 is super useful. It looks like the content process is spending a ton of time doing some busy JS on that mayoclinic page.

I would suspect that in non-e10s mode, the same STR from comment 0 would result in the whole browser just locking up.

Comment 4

[Tracy Walker [:tracy]]

I am unable to reproduce this in e10s or non-e10s on Win 10 (Surface), Win 7 (VM) or Mac 10.11 with latest Nightly builds. The page loads fine, no spinner at all.

Comment 5

[Tracy Walker [:tracy]]

On latest version of Dev-Ed on Mac (49.0a2
20160714004054, Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0)

Per triage discussion, Tracking Protection is probably causing content slowness with the reporters test url. not an e10s issue. For e10s we're concerned with the content blocking responsiveness of chrome. As such, this what I have found.

* running while(true){} in the web console, on any page that is running remotely:
** I get a slow response to closing the Window; about 5 seconds from click of the window [X] to visual close of the window. (jimm, is that slow enough to block on?)
or
** requires a double click to close the tab under script load. (I think blassey said this is expected)

Comment 6

[Jim Mathies [:jimm]]

(In reply to Tracy Walker [:tracy] from comment #5)
> On latest version of Dev-Ed on Mac (49.0a2
> 20160714004054, Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0)
> Gecko/20100101 Firefox/49.0)
> 
> Per triage discussion, Tracking Protection is probably causing content
> slowness with the reporters test url. not an e10s issue. For e10s we're
> concerned with the content blocking responsiveness of chrome. As such, this
> what I have found.
> 
> * running while(true){} in the web console, on any page that is running
> remotely:
> ** I get a slow response to closing the Window; about 5 seconds from click
> of the window [X] to visual close of the window. (jimm, is that slow enough
> to block on?)

Nope.

> or
> ** requires a double click to close the tab under script load. (I think
> blassey said this is expected)

Thanks.