[Qt] Fix C++11 build with gcc 4.4 and 4.5
https://bugs.webkit.org/show_bug.cgi?id=119736

Reviewed by Anders Carlsson.

Don't force C++11 mode off anymore.

* Target.pri:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154002 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplify RadioNodeList's anonymous indexed getter
https://bugs.webkit.org/show_bug.cgi?id=119725

Reviewed by Darin Adler.

Simplify RadioNodeList's anonymous indexed getter by dropping [IsIndex]
IDL extended attribute from its parameter and making it mandatory.

This change has strictly no impact on the generated bindings code
but it simplifies the IDL.

No new test, no behavior change.

* html/RadioNodeList.idl:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154003 268f45cc-cd09-0410-ab3c-d52691b4dbfc
On request error, always fire events on the XMLHttpRequestUpload before the XMLHttpRequest
https://bugs.webkit.org/show_bug.cgi?id=119714

Reviewed by Alexey Proskuryakov.

Source/WebCore:

On request error, fire events on the XMLHttpRequestUpload object before the XMLHttpRequest
object as per the latest specification:
http://xhr.spec.whatwg.org/#request-error

This specification change was made in Sept 2010:
http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h

It addresses the following comment:
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0777.html

IE10 and since recently Blink behave according to specification but WebKit was firing the
events on the XMLHttpRequest object BEFORE the XMLHttpRequestUpload object in case of
'network error' or 'abort error'. WebKit was however behaving according to specification
in case of 'timeout error', which was inconsistent.

Test: http/tests/xmlhttprequest/upload-request-error-event-order.html

* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::networkError):
(WebCore::XMLHttpRequest::abortError):

LayoutTests:

Add a layout test to validate the order in which the events are fired in case
of a xhr request error. Also update an existing test which was relying on the
outdated firing order.

* http/tests/xmlhttprequest/simple-cross-origin-progress-events-expected.txt:
* http/tests/xmlhttprequest/simple-cross-origin-progress-events.html:
* http/tests/xmlhttprequest/upload-request-error-event-order-expected.txt: Added.
* http/tests/xmlhttprequest/upload-request-error-event-order.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154004 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLSelectElement.item() does not behave according to specification
https://bugs.webkit.org/show_bug.cgi?id=119738

Reviewed by Darin Adler.

Source/WebCore:

Make HTMLSelectElement.item() behave according to specification:
http://www.w3.org/TR/html51/forms.html#dom-select-item
http://dom.spec.whatwg.org/#dom-htmlcollection-item

Namely, we no longer throw if the offset argument is negative. Also,
the argument is now mandatory.

IE10, Firefox and Blink do not throw when HTMLSelectElement.item() is
called with a negative value (as per the specification).

The argument is mandatory in Firefox and Blink, but optional in IE10
(it returns null when called without argument). This looks like a bug
in IE because other item() getters' argument is usually mandatory in IE
(e.g. NodeList.item()).

Test: fast/dom/HTMLSelectElement/select-element-item-argument.html

* html/HTMLSelectElement.idl:

LayoutTests:

Add a new layout test to check that the HTMLSelectElement.item() indexed getter's
parameter is correctly validated.
Also update fast/dom/non-numeric-values-numeric-parameters.html now that the
argument is mandatory.

* fast/dom/HTMLSelectElement/select-element-item-argument-expected.txt: Added.
* fast/dom/HTMLSelectElement/select-element-item-argument.html: Added.
* fast/dom/non-numeric-values-numeric-parameters-expected.txt:
* fast/dom/script-tests/non-numeric-values-numeric-parameters.js:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154005 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Curl] Possible infinite loop while downloading.
https://bugs.webkit.org/show_bug.cgi?id=119744

Patch by peavo@outlook.com <peavo@outlook.com> on 2013-08-13
Reviewed by Darin Adler.

If adding/removing curl handles fails, the download thread
can end up in an endless loop trying to update the curl handle list.

* platform/network/curl/CurlDownload.cpp:
(WebCore::CurlDownloadManager::updateHandleList): Avoid infinite loop by ignoring return value.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154006 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Autotools] Don't compare $CC, $CXX to exact compiler names
https://bugs.webkit.org/show_bug.cgi?id=119683

Reviewed by Gustavo Noronha Silva.

Instead of comparing $CC and $CXX to exact compiler names (like 'gcc', 'clang++' etc.),
use the compiler version checks to also specify the broader compiler collection of which
the used compiler is a member of. This avoids failures in some border-line cases where
the user would still use either a GCC or a Clang compiler but provide it through a symbolic
link that was specified via the CC/CXX environment variables.

* Source/autotools/CheckSystemAndBasicDependencies.m4: Store the detected C/C++ compiler collection
in c_compiler/cxx_compiler. Throw an error if no supported compiler was found.
* Source/autotools/SetupCompilerFlags.m4: Test for a specific compiler by checking against
c_compiler/cxx_compiler rather than CC/CXX values.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154007 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Autotools] Unicode's CFLAGS enforce -D_FORTIFY_SOURCE=2, -D_REENTRANT=1, causing faulty Clang builds
https://bugs.webkit.org/show_bug.cgi?id=119685

Reviewed by Gustavo Noronha Silva.

icu-config includes '-D_FORTIFY_SOURCE=2 -D_REENTRANT=1' when printing out C preprocessor flags that are used
as the C compiler flags to avoid other unwanted compiler options. This causes problems when building optimized
builds with Clang because of a bug in that compiler:
http://llvm.org/bugs/show_bug.cgi?id=16821

To avoid that, the C preprocessor search flags, as printed by `icu-config --cppflags-searchpath` are now used
the Unicode dependency's C compiler flags, avoiding unconditionally specifying the two macros.

To adjust for that, the `-pthread` flag is added to the global CFLAGS and CXXFLAGS variables, ensuring
the _REENTRANT define is set to 1 and declaring the flag globally instead of relying on Glib dependency's
C compiler flags to do so for us. -D_FORTIFY_SOURCE=2 is only added to the CFLAGS and CXXFLAGS variables if
the compiler in use is gcc or g++, preventing the Clang builds to malfunction.

* Source/autotools/FindDependencies.m4:
* Source/autotools/SetupCompilerFlags.m4:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154008 268f45cc-cd09-0410-ab3c-d52691b4dbfc