[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Synchronous XMLHttpRequest deprecated

Chuck Anderson

4/4/2015 11:35:00 PM

The current Firefox displays this warning in the console when I use a
synchronous XMLHttpRequest.

"Synchronous XMLHttpRequest on the main thread is deprecated because of
its detrimental effects to the end user's experience. For more help
http://xhr.spec.whatwg....

I've read about the reasoning and understand the logic, ... although I
believe this should be a decision left up to the page designer and not
dictated by the browser developers.

That said, ... most all of my synchronous "ajax" requests can be
converted to asynchronous with no detrimental effect.

I do have one case, though, that needs to be synchronous. I have
written a file synch/backup web application for myself using Php, and
JavaScript . It compares - then copies (sync/backup) a list of files on
a local server or on a remote server (using FTP).

During the copy process I provide progress feedback on the list of files
being copied by opening an overlaying div with a table and using
JavaScript to:

1. Create a new table row with the name of the file, it's size and a
faux progress meter (animated gif).

2. Send a synchronous XMLHttpRequest to the local server to actually
delete the file (local, LAN, or FTP remote).

3. Display the result ("deleted or failed") from the synchronous
XMLHttpRequest response.

4. Repeat the above process for every file in the list

Yes, it "locks up" my app during the process, but this is exactly what I
want it to do so I can visualize the progress and see if there any
errors or warnings from the Php copy process.

What it usually does it race through the list, displaying a summary at
the end.

I like the way I implemented this, but it appears it will ultimately
stop working in major browsers. I tried an asynchronous approach, but
it is too complex trying to keep track of the separate XMLHttpRequest
responses - spaghetti.

Is there a way to make this synchronous copy process not be "in the main
thread?"

Is there another way I should implement this - like move to an iframe
(not div) and call a Php script that processes the whole list in one
instance? (I don't like using iframes - and won't it have the same
effect anyway - lock up the page while it processes the list?)

Yes, this could leave the boundaries of a JavaScript forum, but the
XMLHttpRequests are where it starts.

(I also created a web app with Php/JavaScript to play Rummy (with a
local or remote opponent) and it requires synchronous calls so the
display of cards on the screen stays in synch with the players moves.
Losing synchronous requests will destroy that entire app.)

--
*****************************
Chuck Anderson â?¢ Boulder, CO
http://cyclet...
Turn Off, Tune Out, Drop In
*****************************
27 Answers

Richard Maher

4/5/2015 12:10:00 AM

0

On 4/5/2015 7:34 AM, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg....
>

Thanks for the heads-up!

I agree with most of your other points. There must be more behind this.
Synchronous must be interfering with some infrastructure functionality
rather than local app sepcific issues.

Luuk

4/5/2015 4:06:00 PM

0

On 5-4-2015 01:34, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg....
>

"User agents are strongly encouraged to *warn* about
such usage in *developer* tools "

Since when is Firefox a developer tool?



Michael Haufe (\"TNO\")

4/5/2015 5:43:00 PM

0

On Sunday, April 5, 2015 at 11:06:47 AM UTC-5, Luuk wrote:
> On 5-4-2015 01:34, Chuck Anderson wrote:
> > The current Firefox displays this warning in the console when I use a
> > synchronous XMLHttpRequest.
> >
> > "Synchronous XMLHttpRequest on the main thread is deprecated because of
> > its detrimental effects to the end user's experience. For more help
> > http://xhr.spec.whatwg....
> >
>
> "User agents are strongly encouraged to *warn* about
> such usage in *developer* tools "
>
> Since when is Firefox a developer tool?

Since last November there has existed a developer version of the browser:

<https://www.mozilla.org/en-US/firefox/deve...

I doubt that was what was intended by the quote anyway...

Luuk

4/5/2015 8:05:00 PM

0

On 5-4-2015 19:42, Michael Haufe (TNO) wrote:
> On Sunday, April 5, 2015 at 11:06:47 AM UTC-5, Luuk wrote:
>> Since when is Firefox a developer tool?
>
> Since last November there has existed a developer version of the browser:
>
> <https://www.mozilla.org/en-US/firefox/deve...
>
> I doubt that was what was intended by the quote anyway...
>

Ah, a version with:
* What's New
- Developer Edition theme
* Known Issues
- Firebug theme is not compatible with Developer Edition theme
(source: https://www.mozilla.org/en-US/firefox/35.0a2/au... )

That must be better than the non-developer-edition......

(sigh)

;)


Christoph M. Becker

4/5/2015 9:00:00 PM

0

Luuk wrote:

> On 5-4-2015 01:34, Chuck Anderson wrote:
>> The current Firefox displays this warning in the console when I use a
>> synchronous XMLHttpRequest.
>>
>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>> its detrimental effects to the end user's experience. For more help
>> http://xhr.spec.whatwg....
>>
>
> "User agents are strongly encouraged to *warn* about
> such usage in *developer* tools "
>
> Since when is Firefox a developer tool?

Firefox is a user agent, and the console is one of its developer tools.

--
Christoph M. Becker

Silvio

4/5/2015 9:41:00 PM

0

On 04/05/2015 01:34 AM, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg....
>
> I've read about the reasoning and understand the logic, ... although I
> believe this should be a decision left up to the page designer and not
> dictated by the browser developers.
>

It is a bad decision to not leave it to the developer. There is an
important use of synchronous requests that can not be emulated using
asynchronous ones:

- user triggers an event (onclick for example)
- event code does a synchronous requests
- the response is used to open a new browser window with a URL that is
part of the response

The last part can be any action that is rejected outside user initiated
code. This will not work with any async scenario since an async response
handler does not count as user initiated.

Who came up with this idea for deprecatio?. Can someone point me to the
place where this is (or has been) discussed?

Silvio

Chuck Anderson

4/6/2015 5:10:00 AM

0

Christoph M. Becker wrote:
> Luuk wrote:
>
>> On 5-4-2015 01:34, Chuck Anderson wrote:
>>> The current Firefox displays this warning in the console when I use a
>>> synchronous XMLHttpRequest.
>>>
>>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>>> its detrimental effects to the end user's experience. For more help
>>> http://xhr.spec.whatwg....
>>>
>> "User agents are strongly encouraged to *warn* about
>> such usage in *developer* tools "
>>
>> Since when is Firefox a developer tool?
>
> Firefox is a user agent, and the console is one of its developer tools.
>

Precisely. I use Firefox for surfing, but I also develop web apps and
find the error console a useful tool.

The idea of eliminating synchronous requests seems to have a strong
foothold in W3.org, Chrome and Mozilla so I'm looking for a simple,
logical alternative to my usage.

Personally ... I think it is a bad idea and not a decision for browser
developers. Web designers should have the right to create a slow
loading page if they so wish.



--
*****************************
Chuck Anderson â?¢ Boulder, CO
http://cyclet...
Turn Off, Tune Out, Drop In
*****************************

Tim Streater

4/6/2015 10:21:00 AM

0

In article <mft4cv$csj$1@dont-email.me>, Chuck Anderson
<seemysig@thisis.invalid> wrote:

>Christoph M. Becker wrote:
>> Luuk wrote:
>>
>>> On 5-4-2015 01:34, Chuck Anderson wrote:
>>>> The current Firefox displays this warning in the console when I use a
>>>> synchronous XMLHttpRequest.
>>>>
>>>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>>>> its detrimental effects to the end user's experience. For more help
>>>> http://xhr.spec.whatwg....
>>>>
>>> "User agents are strongly encouraged to *warn* about
>>> such usage in *developer* tools "
>>>
>>> Since when is Firefox a developer tool?
>>
>> Firefox is a user agent, and the console is one of its developer tools.

>
>Precisely. I use Firefox for surfing, but I also develop web apps and
>find the error console a useful tool.
>
>The idea of eliminating synchronous requests seems to have a strong
>foothold in W3.org, Chrome and Mozilla so I'm looking for a simple,
>logical alternative to my usage.
>
>Personally ... I think it is a bad idea and not a decision for browser
>developers. Web designers should have the right to create a slow
>loading page if they so wish.

Given that almost no browser feature has ever been eliminated from a
browser, the likelihood of it actually being removed as a feature is
low. Doing so would likely break a number of websites. Further, there
are times when it is important to be able to serialise some actions. I
rely on this when closing down my app, for example.

--
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Thomas 'PointedEars' Lahn

4/6/2015 12:12:00 PM

0

Silvio wrote:

> On 04/05/2015 01:34 AM, Chuck Anderson wrote:
>> The current Firefox displays this warning in the console when I use a
>> synchronous XMLHttpRequest.
>>
>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>> its detrimental effects to the end user's experience. For more help
>> http://xhr.spec.whatwg....
>>
>> I've read about the reasoning and understand the logic, ... although I
>> believe this should be a decision left up to the page designer and not
>> dictated by the browser developers.
>
> It is a bad decision to not leave it to the developer.

They who can read have the advantage here. It is a *warning*, not an error
message. The developer can disable the display of warnings. They do not
even have to use the Console.

> There is an important use of synchronous requests that can not be emulated
> using asynchronous ones:
>
> - user triggers an event (onclick for example)
> - event code does a synchronous requests
> - the response is used to open a new browser window with a URL that is
> part of the response
>
> The last part can be any action that is rejected outside user initiated
> code. This will not work with any async scenario since an async response
> handler does not count as user initiated.

I do not see your point. Why exactly can that not be done in a user-
friendly, non-blocking, asychronous way?

> Who came up with this idea for deprecatio?. Can someone point me to the
> place where this is (or has been) discussed?

It has been the standing recommendation for several years now, here and
elsewhere.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Tim Streater

4/6/2015 1:23:00 PM

0

In article <3049656.CVpVeAz9R9@PointedEars.de>, Thomas 'PointedEars'
Lahn <PointedEars@web.de> wrote:

>I do not see your point. Why exactly can that not be done in a user-
>friendly, non-blocking, asychronous way?

Termination actions. If the user closes the window in my app, the
unbeforeunload handler runs. This is my last chance to tidy up, and I
need to be able to run a PHP script and, crucially, to have it
complete, before the handler exits.

Making an async XMLHttpRequest will mean that the handler will complete
right away and my PHP script will be aborted by apache. So I make a
sync request and all behaves as required.

--
"The problem with defending the purity of the English language is that English
is about as pure as a cribhouse whore. We don't just borrow words; on occasion,
English has pursued other languages down alleyways to beat them unconscious
and rifle their pockets for new vocabulary." -- James Nicoll, rasfw