| Age | Commit message (Collapse) | Author |
|---|
|
|
|
current working
Reviewed by Richard - http://codereview.lindenlab.com/6011001/
|
|
|
|
This requires some cooperation between the plugin and the host, and will only work for specific messages.
The way it works is as follows:
* the plugin sends a message containing the key "blocking_request" (with any value)
* this will cause the "send message" function to block (continuing to pull incoming messages off the network socket and queue them) until it receives a message from the host containing the key "blocking_response"
** NOTE: if the plugin sends a blocking_request that isn't set up to cause the host to send back a blocking_response, it will block forever
* the blocking_response message will be handed to the plugin's "receive message" function _immediately_ (before the "send message" function returns)
** this means that the plugin can extract response data for use by the the code that sent the message (but is still blocked inside the "send message" call)
** NOTE: this BREAKS the invariant stating that the plugin's "receive message" function will never be called recursively, and the plugin MUST be prepared to deal with this
* after the plugin finishes processing the blocking_response message, the "send message" function that was called with the blocking_request message will return to the plugin
* any queued messages will be delivered after the outer invocation of the plugin's "receive message" function returns (as normal)
Inside the viewer, the code can tell when a plugin is in this blocked state by calling LLPluginProcessParent::isBlocked(). LLPluginClassMedia uses this to avoid sending mouse-move and size-change messages to blocked plugins.
|
|
LLPluginClassMedia queue it up before initializing its LLPluginProcessParent.
Made all existing plugins send their texture_params message from this init message instead of the LLPLUGIN_MESSAGE_CLASS_BASE "init" message. (This ensures that they won't start to receive 'size_change' messages until after the init has happened.)
Added "set_user_data_path" and "set_language_code" messages to LLPluginClassMedia.
Made webkit plugin deal with the new messages, when they're sent before it receives the media "init".
Removed the user_data_path and language_code arguments from the init function calls throughout the hierarchy.
Made LLViewerMediaImpl queue up the language code and user data path messages before initializing the media.
Reviewed by Callum at http://codereview.lindenlab.com/687006 .
|
|
(implemented via JavaScript - not in ua string)
(for B5) Fix for EXT-5314 "Inworld Browser blanks out at credit card entry"
Note: also includes an update to install.xml that points to a new version of LLQtWebKit that is required for these fixes
|
|
Checker: UNINIT_CTOR
Function: LLPluginProcessChild::LLPluginProcessChild()
File: /indra/llplugin/llpluginprocesschild.cpp
|
|
tree (mostly media stuff)
propagate the parent app's OSUserAppDir (i.e. ~/.secondlife/) all the way down to plugins, if they need persistant user data/settings (like the webkit plugin needs a place to put its cache).
|
|
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/media-on-a-prim/moap-7
Merging branches/media-on-a-prim/moap-7 down to viewer-2.0.
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/moss/pluginapi_05-merge@129910
svn merge -r 129913:131718 svn+ssh://svn.lindenlab.com/svn/linden/branches/pluginapi/pluginapi_05
Some branch shenannigans in the pluginapi_05 branch caused this to become a two-part merge.
|
