1414123 - Firefox shows loading state when XHR request is loading in background

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P3)

Description

[Jakub Mareda]

Attachment: Behavior in google chrome

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171002220106

Steps to reproduce:

I initiate XHR request before website has loaded, using oboe.js library. The request streams data for 5 seconds.

Example I made:http://u8.8u.cz/test_xhr/



Actual results:

Firefox shows loading animation and document.readyState is "interactive"


Expected results:

document.readyState should not be influenced by background XHR. 

Compare: 
 - Google Chrome: https://i.stack.imgur.com/cZiLU.png
 - Firefox: https://i.stack.imgur.com/cDqPv.png

Comment 1

[Shian-Yow Wu [:swu]]

Shawn, do you have any comments about this XHR issue?

Comment 2

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

The spec said:
Returns "loading" while the Document is loading, "interactive" once it is finished parsing but still loading subresources, and "complete" once it has loaded.


So if the browser is getting subresources, readyState should be interactive.

Anne, the specification doesn't seem to define subresources clearly in HTML5 specification, FWIW things except for documents and worker scripts are subresources. Not sure it's the same term like Fetch spec (https://fetch.spec.whatwg.org/#subresource-request). I guess this is the correct behavior. Do you have any comment?

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Based on the specification.
6. Spin the event loop until there is nothing that delays the load event in the Document.
7. Queue a task to run the following substeps:
    Set the current document readiness to "complete".

Hmm. XHR shouldn't block load event, right?

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I'm not sure how the specification defined subresoures, so i think if xhr request can considering subresources then interactive makes sense. Maybe it's different from what I know about fetch subresource request.

Comment 5

[Anne (:annevk)]

The green box you quote from is non-normative and only there to help web developers get an idea what the feature does (that's why it says "Note", but perhaps we need to make that more clear). We might want to make the box more precise though, as you note (please file an issue on that).

The actual normative definition here is

> The readyState IDL attribute must, on getting, return the current document readiness.

and the modification of "current document readiness" throughout the loading pipeline. I think only HTML defines which resources delay the load event and XMLHttpRequest is indeed not among them.

Hope that helps.

Comment 6

[Edgar Chen [:edgar]]

Attachment: Bug 1414123 - Don't try to scroll image if the image document is not visible;

Review commit: https://reviewboard.mozilla.org/r/197054/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/197054/

Comment 7

[Edgar Chen [:edgar]]

Comment on attachment 8925854 [details]
Bug 1414123 - Don't try to scroll image if the image document is not visible;

sorry, wrong bug ...

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Anne (:annevk) from comment #5)
> > The readyState IDL attribute must, on getting, return the current document readiness.
> 
> and the modification of "current document readiness" throughout the loading
> pipeline. I think only HTML defines which resources delay the load event and
> XMLHttpRequest is indeed not among them.
> 
> Hope that helps.
Thanks for the explanation.
Sometimes normative definition is too short and concise, and MDN also mentioned what the "green box" defines.
I will investigate why we are setting readyState is "interactive", in theory unless something delays the load events.

Comment 9

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Anne (:annevk) from comment #5)
> The green box you quote from is non-normative and only there to help web
> developers get an idea what the feature does (that's why it says "Note", but
> perhaps we need to make that more clear). We might want to make the box more
> precise though, as you note (please file an issue on that).
https://github.com/whatwg/html/issues/3214

Comment 10

[u408661]

I don't believe this is a necko bug, likely more of a docshell bug.