1445655 - Blocked network request in embedded iframe

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Damien Goujard]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce:

I've noticed in our CMS that when we open in modal our "file browser" (iframe on url with js/css dependencies) the loading of the file browser url take more time when we re-open it. It can take up to 45s to load one simple html file.


Actual results:

In the network inspector we can see that the more consuming time is the blocking state. When we reopen the modal with the iframe it take more and more time. We didn't load other ressources as the same time.
When we open in new windows popup we didn't notice slowdown.
It's seems similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1430659 but we disabled our ipv6 connexion to test it.

Comment 1

[Damien Goujard]

Attachment: Capture d’écran 2018-03-14 à 16.10.33.png

Blocked request

Comment 2

[Damien Goujard]

When we test the same program on other browsers like Chrome or Safari we didn't had this slowdown. 
You can find an network log here : https://mega.nz/#!Cg4S3SJT!ucvoZsfTYjD4b9U2AEflrveznFR2QIywY6-QuxKKg6Y (too big for bugzilla)

Comment 3

[Damien Goujard]

After digging i found that an ajax request was send every second after file selection and iframe close. The file manager didn't send this request after file selection on other browser (and there are no ajax request in file selection callback). This request isn't showed in network monitor (but i found it in apache log et mitmproxy) When the firefox tab is closed the reqests are still sended. To resolved this bug i destroy angular app before close the iFrame, but i didn't think it's a normal to send request on closed tab.

Comment 4

[Ciprian Muresan [:cmuresan], Ecosystem QA]

@Jason, could you please take a look at the network log from comment 2?

Comment 5

[Jason Duell]

Honza, can you take a look at this?  I'm not convinced this is a necko issue, but it might be.

The log is weird--turns quickly into just a zillion repeated lines like this:

   V/nsHttp   0x1fa4cc800

Comment 6

[Honza Bambas (:mayhemer)]

There is a huge number of pending transactions (requests) to adminv2.actipage.net, not bound to a window.  Those are POSTs for /fichiers/images/files with referrer being http://adminv2.actipage.net/fichiers/modal/images and apparently those are XHR requests.

This is not a necko issue.

Comment 7

[Honza Bambas (:mayhemer)]

I'm not sure about this component, but it seems there is either a bug in the page code or we are doing something unexpected in DOM or JS.

Comment 8

[Henri Sivonen (:hsivonen)]

Reporter, is there a public Web page that demonstrates the problem?