Open Bug 312418 Opened 19 years ago Updated 2 years ago

XMLHttpRequest activity should be reflected by the throbber

Categories

(Core :: XML, enhancement)

x86
Windows XP
enhancement

Tracking

()

People

(Reporter: anko.com+bugzilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

When XMLHttpRequest fetches information from a site, the page loading icon (icon
below the minimise/maximise/close icons on windows) should move to signifiy page
activity.

More and more sites are using XMLHttpRequest to load page content, and the user
has no indication that this is happening. Some sites such as Gmail
(http://www.gmail.com) provide a loading indication, but this 1) shouldn't be
left upto page design and 2) does not give any indication if the network stalls
or the client has stopped trying.

Reproducible: Always

Steps to Reproduce:
This is easy if you have a gmail account
1. Login to gmail
2. open a conversation thread
3. click on a message that is hidden (only it's titlebar is showing)

Actual Results:  
notice that it shows loading, the progress icon does not change to a loading
state but the XMLHttpRequest causes network activity.

Expected Results:  
The progress icon should show network activity when the XMLHttpRequest is called.
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Summary: XMLHttpRequest activity should be shown by the page loading icon → XMLHttpRequest activity should be reflected by the throbber
Version: unspecified → Trunk
The way it is currently implemented is actually by design.

But having said that, what you said is true and in many cases it would be useful
to get an indication a load is happening in the background. Before starting work
on this one should check if the WHATWG has anything to say about this, and
perhaps ask their opinion. Also, it should be checked that all the other "hidden
loading" cases work similarly (loading in hidden iframe and whatnot).
Another way we could fix this temporarily is to allow throbber access from unprivledged javascript.  Is there a way to do this now?
I've asked the whatwg mailing list and basically as far as anyone know it's an implementation issue. The most helpful comment:

>As Lachlan points out, this is out of scope for the specification. User 
>agents are mostly free to do whatever they like in their interface. I 
>recommend performing usability testing to determine the optimal course of 
>action in this case.

If this is indeed the course of action we should undertake, does anyone have suggestions on testcases and is anyone able to submit a patch/extension?
Two thoughts for discussion here.

1. It's the role of the AJAX client to present progress information to the client. I can see valid use cases where the user doesn't need to know that xmlhttprequest-stuff is happening (eg: some  entirely background and opportunistic function) Webpages-as-applications is still very new, of course, so I don't think we can depend on authors being completely sensitive to interactive UI requirements. Hm.

2. What is our throbber representing? Page loading or network activity? Hm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #4)
> 1. It's the role of the AJAX client to present progress information to the
> client. I can see valid use cases where the user doesn't need to know that
> xmlhttprequest-stuff is happening (eg: some  entirely background and
> opportunistic function) Webpages-as-applications is still very new, of course,
> so I don't think we can depend on authors being completely sensitive to
> interactive UI requirements. Hm.

The main problem with each developer representing AJAX progress info themselves is that it gives the user a new interface for each website.  A common user interface would be a lot better for usability.

Also, when the network connection has stalled, it looks from the user's point of view as though the webpage is still loading. AFAIK XMLHttpRequest's fail silently - and even if there is a cross platform way to handle failures, the effort is duplicated across all AJAX websites.

Imagine if the same argument was made for the original throbber?  Developers had to implement their own? The web would be a lot less useable than it is today.

I know that there are the cases that you mention where XMLHttpRequest is being used to load something in the background.. A good solution would be an optional extra parameter to XMLHttpRequest called useThrobber or something.  The default would be true, so developers had to specificly turn it off for background loads/server status checks.  Any suggestions/problems with this approach? Anyone got a link to the official standard?

> 
> 2. What is our throbber representing? Page loading or network activity? Hm.
> 

Well really they are largely the same thing.  

But the key thing here is what does the common user think they are representing?
I think it's that more of the page is still on it's way.
Blocks: 328702
In theory the throbber represents that "the browser is doing something, sorry user, please expect possible delays".

I currently have a problem with synchronous ajax calls where the ajax app, by design, doesn't want the user doing anything on the page until the ajax call is finished. The trouble is that during this ajax process the throbber does nothing, giving the user the impression that the browser is doing nothing and has hung.

(Should the synchronous ajax call hang for any reason, then the browser truly does hang, but that's a different problem).

If inclusion in the throbber could be made default, with an optional switch to turn it off, it will improve usability IMO.
Assignee: xml → nobody
QA Contact: ashshbhatt → xml
Please wontfix. Opera had this feature (more or less, with some variations) early on, had to remove it because users found it very annoying. And I mean VERY.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.