Safari XHR Error

[MC]

Newslist Folks,

The code below works for IE9, Chrome, Firefox but fails on Safari 5 on
Windows.

Line1: var action = (the specific webservice ie, /ws/WSAPI199B.jsp)
Line2: var myXHR = (function to get browser compliant XHR)
Line3: myXHR.open("POST","/ws/"+action+".jsp");
Line4: myXHR.onreadystatechange=AISUS.APPLICATION.handleResponse;

Line2 gets a valid XHR object. Inspecting using the Safari debugger
shows that Line3 seems to 'null' the XHR object. Line4 gets the
following error:
INVALID_STATE_ERR: DOM Exception 11: An attempt was made to use an
object that is not, or is no longer, usable.

Any ideas on whats going on?

Thank you,
MC

[MC]

On 3/29/2012 9:45 AM, Tim Streater wrote:
> In article <4bd1f$4f7476a3$cf9b42fc$12...@ALLTEL.NET>,

> Any particular reason you're not waiting for the right status (200) and
> readyState (4) ?
>
> Precisely which version of Safari?
>

Tim,

This is Safari 5.1.4 on Win7-64. The handleResponse method waits for
readyState(4), but never gets called. The problem here is the XHR.open
method seems to invalidate the object, at least thats what the debugger
is saying.

FYI, Line5: is myXHR.send(myRequest); which gets the same error as Line3.

MC

[Gregor Kofler]

Am 2012-03-29 16:37, MC meinte:

> Newslist Folks,
>
> The code below works for IE9, Chrome, Firefox but fails on Safari 5 on
> Windows.
>
> Line1: var action = (the specific webservice ie, /ws/WSAPI199B.jsp)
> Line2: var myXHR = (function to get browser compliant XHR)
> Line3: myXHR.open("POST","/ws/"+action+".jsp");
> Line4: myXHR.onreadystatechange=AISUS.APPLICATION.handleResponse;

Do you intend to do a synchronous request? Try it with a "real" URL
including protocol and domain, instead of a relative path.

> Line2 gets a valid XHR object. Inspecting using the Safari debugger
> shows that Line3 seems to 'null' the XHR object. Line4 gets the
> following error:
> INVALID_STATE_ERR: DOM Exception 11: An attempt was made to use an
> object that is not, or is no longer, usable.
>
> Any ideas on whats going on?

At least you are not alone:

<https://www.google.com/search?q=safari+INVALID_STATE_ERR%3A+DOM+Exception+11+xmlhttprequest>

Gregor


--
http://vxweb.net

[MC]

I found a solution for the problem.

It seems that Safari will accepts a relative URL for the XHR but does
NOT post it to the root domain. Setting the the the URL to
"https://mydomain.com/ws/myaction.jsp" worked. It appears Safari was
posting relative, ie, my calling resource is located at
https://mydomain.com/someDir/somePage.html such that a URL of
"/ws/myaction.jsp" is posted to
"https://mydomain.com/someDir/ws/myaction.jsp".

None of the other browsers do this..bug???

[Gregor Kofler]

Am 2012-03-29 19:05, MC meinte:

They are only forgiving and assuming:

http://www.w3.org/TR/XMLHttpRequest/#the-open-method

The draft requests a _URL_

<http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url>

Gregor


--
http://vxweb.net

[MC]

Gregor,

The RFC3986 regarding URL's regards a relative URL references as valid,
if there is a - "'base URI'" exists against which
the relative reference is applied".

It appears that Safari does indeed have a bug as it resolves the base
URI differently (incorrectly) from the other browsers.

MC

[Gregor Kofler]

Am 2012-03-29 21:26, MC meinte:

I'd still consider this not a bug. Anyway, you can use the information
provided by the location object and safely obtain "compatible" absolute
URIs.

Gregor

[MC]

Gregor,

Thank you for the suggestion which pointed me to a workaround. Numerous
scripts use relative URL and Google did not help. I also would say that
an XHR.open() with a relative URL should not cause the XHR to become
invalid in Safari debugger, that too is an error.

MC

[Eric Bednarz]

You've only shown some dummy code. The best guess is that you are doing
something wrong.

(Or something silly, like specifying a base URI with a BASE element.)

[Richard Cornford]

MC wrote:
> Newslist Folks,
>
> The code below works for IE9, Chrome, Firefox but fails on Safari
> 5 on Windows.
>
> Line1: var action = (the specific webservice ie, /ws/WSAPI199B.jsp)

I suspect that the above does not represent meaningful information about
the (string?) value stored in the variable - action -. The purported
value begins with a slash and ends with ".jsp".

> Line2: var myXHR = (function to get browser compliant XHR)
> Line3: myXHR.open("POST","/ws/"+action+".jsp");

<snip>

Yet in this above line the string concatenated to the beginning of -
action - ends with a slash, and a second ".jsp" is concatenated to its
end. This would give the URL "/ws//ws/WSAPI199B.jsp.jsp", which is a URL
that could be expected to be problematic.

If the information you provide about your issues is any of incomplete,
ambiguous or inaccurate the odds are that any answers given would only
be useful by coincidence.

Richard.

[MC]

Richard,

The Line3: myXHR.open("POST","/ws/"+action+".jsp"); resolves to a
relative URL of "/ws/WSAPI199B.jsp". Its not that hard. What is hard is
trying to figure out why Safari is bugging out.

Thanks for condescending and not helping.

MC

[David Mark]

On Mar 29, 5:07 pm, MC <n...@aisus.com> wrote:
> Richard,

This is a newsgroup, not the bottom of a blog post.

>
> The Line3: myXHR.open("POST","/ws/"+action+".jsp"); resolves to a
> relative URL of "/ws/WSAPI199B.jsp".

But that's not what you indicated in the original post, which is all
we have to go on.

> Its not that hard.

Insulting those who are trying to help you is unlikely to further your
cause.

> What is hard is
> trying to figure out why Safari is bugging out.

Certainly is for those who have to interpret unknowns like this:-

var myXHR = (function to get browser compliant XHR)

>

> Thanks for condescending and not helping.
>

(Some things never change.)

You've gotten your share of answers, based on the incomplete
information furnished. If you can't figure out what to do next, you
should probably find another pursuit.

I'll help you out a bit by making it a multiple choice question:-

Should you...

A. Post insults
B. Whine and play the victim
C. Give up and download jQuery
D. Post more specific information about your problem

?

[Scott Johnson]

Actually what he was telling you is correct and wanted to make sure the
information you provided was correct to those who would freely give
their time to try to help.

Line1: var action = (the specific webservice ie, /ws/WSAPI199B.jsp)

So:

Line3: myXHR.open("POST","/ws/"+action+".jsp");

would resolve to "/ws//ws/WSAPI199B.jsp.jsp" if the info you gave in
line1 was correct.

Stating that it resolved to "/ws/WSAPI199B.jsp" means that the info you
gave for line1 was not what we would of expected it to be.

And it may not of helped you in this instance, but maybe in the future
when you ask for help, it may have planted the seed to provide accurate
details which again will help those who give their time FREELY.

Scotty

[Richard Cornford]

MC wrote:
> Richard,
>
> The Line3: myXHR.open("POST","/ws/"+action+".jsp"); resolves to a
> relative URL of "/ws/WSAPI199B.jsp".

So you say but you have not provided any evidence that that is actually
the case, and have instead suggested otherwise with the code(ish) that
you posted.

> Its not that hard.

Mindreading?

> What is hard is trying to figure out why Safari is bugging out.

No it wouldn't be. You either have to do it for yourself or provide
enough information to allow others to easily reproduce the issue.

> Thanks for condescending and not helping.

If you say so.

Richard.

[David Mark]

On Mar 29, 4:28 pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:

> MC <n...@aisus.com> writes:
> > It seems that Safari will accepts a relative URL for the XHR but does
> > NOT post it to the root domain. Setting the the the URL to
> > "https://mydomain.com/ws/myaction.jsp" worked. It appears Safari was
> > posting relative, ie, my calling resource is located at

> >https://mydomain.com/someDir/somePage.htmlsuch that a URL of

> > "/ws/myaction.jsp" is posted to
> > "https://mydomain.com/someDir/ws/myaction.jsp".
>
> > None of the other browsers do this..bug???
>
> You've only shown some dummy code. The best guess is that you are doing
> something wrong.
>
> (Or something silly, like specifying a base URI with a BASE element.)

Yes, that element should be written out of the playbook. It adds
nothing but miserable complications.