Merge r165745 - [GTK] Don't busy loop when the socket is full
https://bugs.webkit.org/show_bug.cgi?id=129802

Patch by Giovanni Campagna <gcampagna@src.gnome.org> on 2014-03-17
Reviewed by Carlos Garcia Campos.

When the socket is full and we see EAGAIN or EWOULDBLOCK
(because the socket is non blocking), don't busy loop by
tring to write again, instead poll() until the socket
becomes writable.

* Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::Connection::sendOutgoingMessage):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165878 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r164808 - [GTK][WK2] Blocks when fetching plugins information
https://bugs.webkit.org/show_bug.cgi?id=115650

Reviewed by Gustavo Noronha Silva.

Use a persistent cache to store the plugins metadata to avoid
having to load all the plugins everytime a plugin is used for the
first time.

* GNUmakefile.am:
* GNUmakefile.list.am:
* PlatformGTK.cmake:
* Shared/Plugins/Netscape/NetscapePluginModule.h:
* Shared/Plugins/Netscape/x11/NetscapePluginModuleX11.cpp:
(WebKit::NetscapePluginModule::parseMIMEDescription): Make this
method public.
(WebKit::NetscapePluginModule::buildMIMEDescription): Added this
helper to build the MIME description string.
* UIProcess/Plugins/gtk/PluginInfoCache.cpp: Added.
(WebKit::PluginInfoCache::shared):
(WebKit::PluginInfoCache::PluginInfoCache):
(WebKit::PluginInfoCache::~PluginInfoCache):
(WebKit::PluginInfoCache::saveToFileIdleCallback):
(WebKit::PluginInfoCache::saveToFile):
(WebKit::PluginInfoCache::getPluginInfo):
(WebKit::PluginInfoCache::updatePluginInfo):
* UIProcess/Plugins/gtk/PluginInfoCache.h: Added.
* UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp:
(WebKit::PluginInfoStore::getPluginInfo): Check first if we have
metadata of the plugin in the cache and update the cache if we
loaded the plugin to get its metadata.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165879 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r164980 - [GTK] webkit_dom_range_compare_boundary_points fails when 0 is passed as how parameter
https://bugs.webkit.org/show_bug.cgi?id=129145

Patch by Tomas Popela <tpopela@redhat.com> on 2014-03-03
Reviewed by Carlos Garcia Campos.

While generating GObject DOM API the generator should skip non pointer
types while generating the g_return_val_if_fail macro.
This will avoid the situation when Range.START_TO_START is defined as 0,
thus the webkit_dom_range_compare_boundary_points function will fail
everytime it is called with 0 as how value.

* bindings/scripts/CodeGeneratorGObject.pm:
(GenerateFunction):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165880 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r165182 - [GTK] Close the page when the view is disposed instead of when finalized
https://bugs.webkit.org/show_bug.cgi?id=129783

Reviewed by Sergio Villar Senin.

Source/WebKit2:

When a GtkWidget is destroyed, the GObject is disposed, but not
finalized if it has additional references. When the destroyed
widget is leaked by the application, we leak the page proxy and
what is more important the web process in multi-process mode.

* UIProcess/API/gtk/WebKitWebViewBase.cpp:
(webkitWebViewBaseDispose): Close the WebPageProxy.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165881 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r165489 - [GTK] Runtime error when page is closed while print operation is in progress
https://bugs.webkit.org/show_bug.cgi?id=129869

Reviewed by Anders Carlsson.

Sometimes when the page is closed right after printing the web
process aborts with the runtime message "pure virtual method
called terminate called without an active exception".
This happens because the page is closed when the pages have been
printed, but print job is still ongoing sending the data to the
printer. When print job finishes, we try to notify the UI process
sending the print callback message using WebPage::send(), but the
web page object has been destroyed. The virtual method it complains
about is probably MessageSender::messageSenderDestinationID() used
by send(). Since our print operation is always asynchronous, we
need a way to notify the web page when the print operation has
actually finished to clean it up, but also notify the print
operation when the page has been closed to not try to notify the
UI process in that case.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close): Call disconnectFromPage to notify the
print operation in case there's an ongoing print job.
(WebKit::WebPage::endPrinting): Do not cleanup the print operation
here, since the print opertation might not have finished yet.
(WebKit::WebPage::didFinishPrintOperation): Send
PrintFinishedCallback message to the Ui process and cleanup the
print operation.
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp:
(WebKit::WebPrintOperationGtk::disconnectFromPage): Set m_webPage
to nullptr.
(WebKit::WebPrintOperationGtk::printDone): Call
didFinishPrintOperation() is the web page hasn't been closed.
* WebProcess/WebPage/gtk/WebPrintOperationGtk.h:

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165883 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r165371 - [GTK] The web process can finish while a print operation is still ongoing
https://bugs.webkit.org/show_bug.cgi?id=129871

Reviewed by Martin Robinson.

This can happen when the last page is closed while the print job
is sending data to the printer.

* WebProcess/WebPage/gtk/WebPrintOperationGtk.cpp: Disable web
process termination when the print job is sending data to the
printer and enable it again when job finishes.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165884 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r165550 - [GTK] Close the connection when we fail to read from the socket for any unhandled error
https://bugs.webkit.org/show_bug.cgi?id=130191

Reviewed by Martin Robinson.

We currently show an error message, but we should close the
connection avoid entering an infinite loop. Also provide more
information in the error message to help when debugging the issue.

* Platform/IPC/unix/ConnectionUnix.cpp:
(IPC::Connection::readyReadHandler):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165885 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Merge r165812 - [GTK] Race condition when the socket event source is cancelled
https://bugs.webkit.org/show_bug.cgi?id=130395

Reviewed by Martin Robinson.

In some cases when the socket event source is cancelled the socket
event source callback is called with the condition of the previous
poll instead of 0. This can happen sometimes when the source is
cancelled from the socket event source callback. Once the socket
event source is cancelled, it's dispatched by glib without
polling, so the condition is never reset again and the callback is
called again and again with the previous condition. When the
condition is G_IO_IN, the source is re-scheduled entering into an
infinite loop. We should always check if the source has been
cancelled at the beginning of the callback to destroy the source
instead of relying on the condition being 0.

* Platform/gtk/WorkQueueGtk.cpp:
(WorkQueue::SocketEventSource::isCancelled):
(WorkQueue::SocketEventSource::eventCallback):

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165886 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Update NEWS and Versions.m4 for 2.2.6 release.

.:

* Source/autotools/Versions.m4: Bump version numbers.

Source/WebKit/gtk:

* NEWS: Add release notes.

git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.2@165887 268f45cc-cd09-0410-ab3c-d52691b4dbfc