567831 - [e10s] fennec appears to have an infinite throbber, loads page but doesn't fire onload

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

I have updated my checkout of elecctrolysis (project central) and mobile (pavlov repo) on Saturday night and after a full clobber rebuild, I ended up with a fennec that loads a web page, but the throbber continues to spin (appearing like it is loading forever).

I saw this while running mochitests, but tested on a plain run (fresh profile) with www.google.com.

As a note, this is similar to what I was experiencing before with NECKO_E10S_HTTP=1, so in my testing, I had turned it off and ignored PAC.  That code is checked in now, so there could be something related.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

This problem seems directly related to "chrome-only necko" that is now default. The webprogress listeners are not receiving the correct state flags. I notice that about: pages load fine, they receive STATE_IS_REQUEST, STATE_IS_DOCUMENT, STATE_IS_WINDOW, STATE_IS_NETWORK flags at the appropriate times.

Web content pages only seem to receive STATE_IS_REQUEST flags.

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #1)
> This problem seems directly related to "chrome-only necko" that is now default.
> The webprogress listeners are not receiving the correct state flags. I notice
> that about: pages load fine, they receive STATE_IS_REQUEST, STATE_IS_DOCUMENT,
> STATE_IS_WINDOW, STATE_IS_NETWORK flags at the appropriate times.
> 
> Web content pages only seem to receive STATE_IS_REQUEST flags.

I've take a look and it seems to me that the page never receive the STATE_STOP. I'll look at that.

Comment 3

[Jason Duell]

So far I'm seeing that in m-c, a simple HTTP page load results in nsDocShell::OnStateChange seeing:

state=f0001: STATE_START STATE_IS_REQUEST STATE_IS_DOCUMENT STATE_IS_NETWORK STATE_IS_WINDOW
state=30004: STATE_TRANSFERRING STATE_IS_REQUEST STATE_IS_DOCUMENT
state=20010: STATE_STOP STATE_IS_DOCUMENT
state=c0010: STATE_STOP STATE_IS_NETWORK STATE_IS_WINDOW

While in the e10s tree, we get 

state=20010: STATE_STOP STATE_IS_DOCUMENT
state=c0010: STATE_STOP STATE_IS_NETWORK STATE_IS_WINDOW
state=f0001: STATE_START STATE_IS_REQUEST STATE_IS_DOCUMENT STATE_IS_NETWORK STATE_IS_WINDOW
state=30004: STATE_TRANSFERRING STATE_IS_REQUEST STATE_IS_DOCUMENT

I.e., for some reason the STOP states are getting delivered first.  I'm looking into why.

Comment 4

[Jason Duell]

Whoops, wrong bug report.

Comment 5

[Doug Turner (:dougt)]

nsDocLoader::doStopURLLoad is firing, but doStopDocumentLoad isn't.

I am attempting to load the most simple page I can:  

http://people.mozilla.org/~dougt/index.html

The data is read from the network.

DocLoaderIsEmpty is called twice.
  the first time mIsLoadingDocuemnt is false.
  the second time mLoadGroup IsPending returns it is busy.

Shouldn't we be removing the channel from the load group during RecvOnStopRequest()?

Comment 6

[Doug Turner (:dougt)]

Attachment: patch v.1

Comment 7

[Jason Duell]

Comment on attachment 448105 [details] [diff] [review]
patch v.1

Very nice!  I was just starting to figure that out myself.

Comment 8

[Jason Duell]

http://hg.mozilla.org/projects/electrolysis/rev/dcfeadea0cba

Comment 10

[Joel Maher ( :jmaher ) (UTC -8)]

this fixes the throbber, but onload is never fired?  Should I fire a new bug?