Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27191 > unrolled thread

Synchronous XMLHttpRequest deprecated

Back to article view | Back to comp.lang.javascript

Contents

  Synchronous XMLHttpRequest deprecated Chuck Anderson <seemysig@thisis.invalid> - 2015-04-04 17:34 -0600
    Re: Synchronous XMLHttpRequest deprecated Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-04-05 08:09 +0800
    Re: Synchronous XMLHttpRequest deprecated Luuk <luuk@invalid.lan> - 2015-04-05 18:06 +0200
      Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-04-05 10:42 -0700
        Re: Synchronous XMLHttpRequest deprecated Luuk <luuk@invalid.lan> - 2015-04-05 22:04 +0200
      Re: Synchronous XMLHttpRequest deprecated "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-05 22:59 +0200
        Re: Synchronous XMLHttpRequest deprecated Chuck Anderson <seemysig@thisis.invalid> - 2015-04-05 23:09 -0600
          Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 10:20 +0000
    Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-05 23:41 +0200
      Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 14:11 +0200
        Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 13:23 +0000
          Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 15:36 +0200
            Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 18:26 +0000
              Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 20:18 +0200
              Re: Synchronous XMLHttpRequest deprecated Denis McMahon <denismfmcmahon@gmail.com> - 2015-04-06 18:35 +0000
                Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 21:51 +0000
                  Re: Synchronous XMLHttpRequest deprecated "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-06 23:33 +0200
                Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 01:13 +0200
        Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 09:16 +0200
          Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 12:51 +0200
            Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 14:55 +0200
              Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-07 14:23 +0000
                Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 17:41 +0200
              Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 15:37 +0200
                Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 16:53 +0200
                  Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-07 16:03 +0000
                    Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 17:47 +0200

Page 1 of 2  [1] 2  Next page →

#27191 — Synchronous XMLHttpRequest deprecated

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.org/"

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://cycletourist.com
   Turn Off, Tune Out, Drop In
  *****************************

[toc] | [next] | [standalone]

#27192

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.org/"
>

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.

[toc] | [prev] | [next] | [standalone]

#27196

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.org/"
>

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

Since when is Firefox a developer tool?

[toc] | [prev] | [next] | [standalone]

#27197

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.org/"
> >
> 
> "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/developer/>

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

[toc] | [prev] | [next] | [standalone]

#27198

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/developer/>
>
> 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/auroranotes/ )

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

(sigh)

;)

[toc] | [prev] | [next] | [standalone]

#27199

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.org/"
>>
> 
> "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

[toc] | [prev] | [next] | [standalone]

#27202

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.org/"
>>>
>> "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://cycletourist.com
   Turn Off, Tune Out, Drop In
  *****************************

[toc] | [prev] | [next] | [standalone]

#27203

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.org/"
>>>>
>>> "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

[toc] | [prev] | [next] | [standalone]

#27200

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.org/"
>
> 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

[toc] | [prev] | [next] | [standalone]

#27204

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.org/"
>>
>> 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.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27205

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

[toc] | [prev] | [next] | [standalone]

#27206

Tim Streater wrote:

> […] Thomas 'PointedEars' Lahn […] 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.

Your application is badly designed if it relies on a “beforeunload” event 
listener triggering a synchronously-handled HTTP request.

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

[toc] | [prev] | [next] | [standalone]

#27208

In article <1787376.QsvDXBBI4c@PointedEars.de>, Thomas 'PointedEars'
Lahn <PointedEars@web.de> wrote:

>Tim Streater wrote:
>
>> […] Thomas 'PointedEars' Lahn […] 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.
>
>Your application is badly designed if it relies on a “beforeunload” event 
>listener triggering a synchronously-handled HTTP request.

Gee, I'll have to smack those users harder, then, so they don't click
on the little red X in the top corner of the window.

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

[toc] | [prev] | [next] | [standalone]

#27209

Tim Streater wrote:

> […] Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Tim Streater wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
>> Your application is badly designed if it relies on a “beforeunload” event
>> listener triggering a synchronously-handled HTTP request.
> 
> Gee, I'll have to smack those users harder, then, so they don't click
> on the little red X in the top corner of the window.

No, you have to change the design of your application.

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

[toc] | [prev] | [next] | [standalone]

#27210

On Mon, 06 Apr 2015 18:26:57 +0000, Tim Streater wrote:

> Gee, I'll have to smack those users harder, then, so they don't click on
> the little red X in the top corner of the window.

I guess that technically what you should do is redesign the browser UI 
component and the back end so that the back end data is never in an 
inconsistent state .....

I know, it's a lot easier said than done.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#27211

In article <mfujmf$qns$3@dont-email.me>, Denis McMahon
<denismfmcmahon@gmail.com> wrote:

>On Mon, 06 Apr 2015 18:26:57 +0000, Tim Streater wrote:
>
>> Gee, I'll have to smack those users harder, then, so they don't click on
>> the little red X in the top corner of the window.
>
>I guess that technically what you should do is redesign the browser UI 
>component and the back end so that the back end data is never in an 
>inconsistent state .....
>
>I know, it's a lot easier said than done.

That would mean, for instance, that if (as I do) I have a data entry
area into which the user has typed a load of stuff, and I want them not
to lose that if they close the window, I'd have to be more or less
sending every keystroke to the backend. Remember, once they click on
the little red +, the window is going away whether I like it or not.

Personally I prefer a more pragmatic approach.

-- 
"I am enclosing two tickets to the first night of my new play; bring a
friend.... if you have one." - GB Shaw to Churchill "Cannot possibly
attend first night, will attend second...  if there is one." - Winston
Churchill, in response.

[toc] | [prev] | [next] | [standalone]

#27212

Tim Streater wrote:

> In article <mfujmf$qns$3@dont-email.me>, Denis McMahon
> <denismfmcmahon@gmail.com> wrote:
> 
>> On Mon, 06 Apr 2015 18:26:57 +0000, Tim Streater wrote:
>>
>>> Gee, I'll have to smack those users harder, then, so they don't click on
>>> the little red X in the top corner of the window.
>>
>> I guess that technically what you should do is redesign the browser UI
>> component and the back end so that the back end data is never in an
>> inconsistent state .....
>>
>> I know, it's a lot easier said than done.
> 
> That would mean, for instance, that if (as I do) I have a data entry
> area into which the user has typed a load of stuff, and I want them not
> to lose that if they close the window, I'd have to be more or less
> sending every keystroke to the backend. Remember, once they click on
> the little red +, the window is going away whether I like it or not.
> 
> Personally I prefer a more pragmatic approach.

A simple solution would be to use the beforeunload event to signal to
the user that there are unsaved changes, giving him/her the chance to
stay on the page (i.e. this document), and to save the changes if desired.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#27214

Denis McMahon wrote:

> On Mon, 06 Apr 2015 18:26:57 +0000, Tim Streater wrote:
>> Gee, I'll have to smack those users harder, then, so they don't click on
>> the little red X in the top corner of the window.
> 
> I guess that technically what you should do is redesign the browser UI
> component and the back end so that the back end data is never in an
> inconsistent state .....
> 
> I know, it's a lot easier said than done.

Appeal to ridicule.

Christoph has already made a good suggestion.  There are other possibilities 
to not having to use the *user-unfriendly* synchronous XHR, but they depend 
on the use-case.  For example, if you wanted to make sure that a user is 
logged out, you could keep a server-side session alive in the background 
(using asynchronous XHR if possible, an image or a reloading hidden frame if 
necessary) and end it automagically when there is no further request (by 
short session lifetime).  And on the client-side, you can use a session 
cookie or Session Storage.

It should also be noted that Firefox/Gecko is unique in its behavior of 
purportedly trying to be “user-friendly”.  This can have unforeseen 
consequences.  For example, there is no good reason why I should not be able 
to request fullscreen mode from a timeout, why I should get the  following 
warning instead if I first wanted to play a sound from a HTML5 audio 
element, then request full-screen:

| Request for full-screen was denied because Element.mozRequestFullScreen() 
| was not called from inside a short running user-generated event handler. 

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

[toc] | [prev] | [next] | [standalone]

#27215

On 04/06/2015 02:11 PM, Thomas 'PointedEars' Lahn wrote:
>
> 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.
>

The warning is not the problem. But the underlying sentiment is that the 
feature is benign and it expresses at least the desire to remove the 
feature at some point.

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

Chrome, Safari, IE and Firefox all consider a window.open or 
window.alert from asynch response handler code (i.e. not user initiated) 
to be a 'popup' and will block it by default. That is far from 
user-friendly. If the synchronous request is part of user initiated code 
then the code handling the response is still user initiated and does not 
suffer from this disadvantage.

The notion that a synchronous request on its own is not user-friendly is 
nonsense. That is only the case if it takes long to complete. That is 
something the programmer can make so unlikely a user is not affected.

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

I know but I have never seen good arguments for the recommendation, only 
people echoing what some browser devs once yelled.

Forcing a sufficiently short (user configurable) timeout on a 
synchronous request would be easy to do and would only break cases that 
are indeed not user friendly.

No limit is imposed on how long event handling code may run but when it 
does a synchronous event then that is considered bad. I see a lot of 
crummy web pages that behave hostile towards users by means of embedded 
JS. Hardly ever are synchronous requests the culprit.

[toc] | [prev] | [next] | [standalone]

#27217

Silvio wrote:

> On 04/06/2015 02:11 PM, Thomas 'PointedEars' Lahn wrote:
>> 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.
> 
> The warning is not the problem. But the underlying sentiment is that the
> feature is benign

Gibberish.

> and it expresses at least the desire to remove the feature at some point.

Non sequitur.  It says that those requests *in the main thread* are 
deprecated.

>> I do not see your point.  Why exactly can that not be done in a user-
>> friendly, non-blocking, asychronous way?
> 
> Chrome, Safari, IE and Firefox all consider a window.open or
> window.alert from asynch response handler code (i.e. not user initiated)
> to be a 'popup' and will block it by default.

True.

> That is far from user-friendly.

*Popups* are not user-friendly, which is why they are blocked by default.

> If the synchronous request is part of user initiated code then the code 
> handling the response is still user initiated and does not suffer from 
> this disadvantage.
> 
> The notion that a synchronous request on its own is not user-friendly is
> nonsense. That is only the case if it takes long to complete. That is
> something the programmer can make so unlikely a user is not affected.

No, the programmer cannot foresee how long it takes a server to respond.

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

Then why are you asking?

> but I have never seen good arguments for the recommendation, only
> people echoing what some browser devs once yelled.

Your short attention span and/or insufficient research is *your* problem.  
The fact that synchronous request handling in the main thread *blocks* the 
browser and effectively *prevents the user from using their software*, or
at least a browser tab or window, until the response is received, and that 
asynchronous request handling does not have that disadvantage, sounds like
a good argument to me.

> Forcing a sufficiently short (user configurable) timeout on a
> synchronous request would be easy to do and would only break cases that
> are indeed not user friendly.

You cannot know if the timeout occurred because the server could not respond 
in time or because it could not respond at all.  How many synchronous 
requests are you going to make in order to find out, blocking the user with 
each one?
 
> No limit is imposed on how long event handling code may run but when it
> does a synchronous event then that is considered bad. I see a lot of
> crummy web pages that behave hostile towards users by means of embedded
> JS. Hardly ever are synchronous requests the culprit.

That does not mean it is a good thing.  Your logic is flawed.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web