Age | Commit message (Collapse) | Author |
|
small to read
|
|
|
|
|
|
|
|
|
|
new LLCEFLib
|
|
developer console (Inspector)
|
|
misbeahving plugin.
|
|
|
|
and move cache to same place as viewer cache
|
|
|
|
|
|
|
|
|
|
|
|
scrolled or closed once opened
|
|
|
|
|
|
|
|
repository.
|
|
|
|
|
|
debugger to help content creators
Viewer side changes to enable Web debugger.
|
|
progress etc. to make debugging problems easier
|
|
|
|
current state of the SL client, such as avatar location
|
|
orientation out to LLQtWebKit
|
|
current state of the SL client, such as avatar location
|
|
links in web profile
Also fixes SOCIAL-521 and SOCIAL-428
|
|
and Help if S3 content or web content is not available.
(Included refs to new LLQtWebKit that supports functionality)
|
|
current working
Reviewed by Richard - http://codereview.lindenlab.com/6011001/
|
|
Reviewed by Callum
|
|
Reviewed by Callum at http://codereview.lindenlab.com/5636001
|
|
web apps
Completes MVP
|
|
Added the necessary plumbing to get link_hovered events from the webkit plugin through to the viewer UI.
This requires a llqtwebkit library built from revision 1799a899e06d or later in http://hg.secondlife.com/llqtwebkit to function. The viewer source changes are backwards-compatible with earlier versions of llqtwebkit, it just won't see any link_hovered events with previous revisions.
Reviewed by Callum.
|
|
and symbol instead of just symbol
The issue seems to be Mac-only, so I've put the fix inside #if LL_DARWIN. Windows' handling of ALT is very different, so the fix might not be appropriate there.
|
|
Reviewed by CB
|
|
The plugin system will now keep a spare running webkit plugin process around and use it when it needs a webkit instance. This should hide some large portion of the setup time when creating a new webkit plugin (i.e. opening the search window, etc.)
|
|
Added support to the webkit media plugin and llpluginclassmedia for passing through the auth request/response. We still need an updated build of llqtwebkit for all platforms, as well as some UI work in the viewer to actually display the auth dialog.
|
|
(Monroe's code - I made a patch and copied it over from viewer-skylight branch)
|
|
from javascript.
This includes a Mac build of llqtwebkit from the following sources:
revision aacdf69cbf5aa12d77c179296e31ef643ed1ef4a of http://qt.gitorious.org/+lindenqt/qt/lindenqt (currently head of the 'lindenqt' branch)
revision 81ab5ae326f0 of http://hg.secondlife.com/llqtwebkit (currently head of the default branch)
Reviewed by Callum.
|
|
|
|
picker on the plugin's behalf.
Reviewed by Callum.
|
|
|
|
|
|
|
|
[secondlife-bin llpluginclassmedia.cpp:158]
|
|
events to blocked plugins.
|
|
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.
|
|
Added LLPluginCookieStore, which manages the central list of cookies.
New Mac and Windows versions of llqtwebkit, built from the tip of the cookie-api branch on http://bitbucket.org/lindenlab/llqtwebkit/ (currently revision f35a5eab8c2f).
Added "set_cookies" and "cookie_set" messages to the media_browser message class in the plugin API, and made the webkit plugin use them appropriately.
Added methods to LLViewerMedia to read/write the cookie file and add/remove individual cookies.
Added hooks to read/write the cookie file (plugin_cookies.txt) in the same places as the location history (idle_startup() in llstartup.cpp and LLAppViewer::cleanup(), respectively).
Reviewed by Richard at http://codereview.lindenlab.com/1006003
|