1372811 - Some websites show a spinning wheel and never finish loading

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[yxu]

E.g: http://dict.hjenglish.com/jp/
Use Firefox to access then tab show a spinning wheel and never finish loading.
Use Chrome will not.

Comment 1

[Honza Bambas (:mayhemer)]

Your report is too wage.  

Please state on what update channel you are and test with the latest Nightly as this very much sounds like duplicate of bug 1370340.

Comment 2

[yxu]

In today's latest version of Nightly: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 20170614030206 problem still exists.

I tested on release channel yesterday.

Comment 3

[Shian-Yow Wu [:swu]]

According to comment 2, this seems a different issue from bug 1370340.

Comment 4

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

[STR]

- open http://dict.hjenglish.com/jp/

[EXPECTED]

- loading animation will stopped after web page loaded

[ACTUAL BEHAVIOR]

- loading icon, a.k.a the spinning wheel, will not disappear.


100% reproducible on Nightly in both e10s and non-e10s window.

Comment 5

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: spinning wheel.png

Comment 6

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Also reproduced on Firefox 53.

Comment 7

[Honza Bambas (:mayhemer)]

The report was too vague to notice the difference.  Yes, I can reproduce, but this is definitely not a networking issue...  Clearly all channels and transactions are done and released on the parent process as well as on the child process.  I have to log the load group and see which request is left in it.

No major issue, so don't expect a quick answer.

Comment 8

[Honza Bambas (:mayhemer)]

I was able to track this down to a wyciwyg channel being added to a loadgroup but never asyncopenned, called from:

 	xul.dll!mozilla::net::nsLoadGroup::AddRequest(0x169479e8, 0x00000000) Line 451	C++
>	xul.dll!nsHTMLDocument::CreateAndAddWyciwygChannel() Line 2416	C++
 	xul.dll!nsHTMLDocument::Open(0x0151e800, {...}, {...}, {...}) Line 1782	C++
 	xul.dll!mozilla::dom::HTMLDocumentBinding::open(0x0151e800, {...}, 0x1c3a1000, {...}) Line 527	C++
 	xul.dll!mozilla::dom::GenericBindingMethod(0x0151e800, 2, 0x00d3cd40) Line 2964	C++


0 renderFrame(t = "119", e = [object HTMLIFrameElement]) ["http://res.hjfile.cn/lib/uzhi/uzt.min.js":1]
    this = [object Object]
1 proxy/<("119", [object HTMLIFrameElement]) ["http://res.hjfile.cn/lib/uzhi/uzt.min.js":1]
    this = [object Window]
2 onload(event = [object Event]) ["http://dict.hjenglish.com/jp/":1]
    this = [object HTMLIFrameElement]


There are 3 loadgroups having unopened wyciwyg channels in this state.  Apparently nsHTMLDocument::RemoveWyciwygChannel is never called, hence the loadgroup spins forever.


Apparently - the content script doesn't call document.close()...  Checked in debugger.

Firefox behaves correctly.