text:
Internet Explorer supports additional clipboard events,
oncut oncopy onpaste onbeforecut onbeforecopy onbeforepaste
These events are very useful in that you can know when cut/copy/paste has
happened in an entry field, and modify the data if necessary (for example
prevent the pasting of text in a numeric entryfield.
In addition, you can even not allow the paste if the data is not appropriate for
the entry field.
There is a bug for onpaste, bug 280683.
what's the use case for oncopy and oncut?
(In reply to comment #2)
> what's the use case for oncopy and oncut?
That's a really good question. The middleware team asked for all three but only
gave the use case for onpaste.
I'll check on that.
Jesse has an interest in clipboard issues.
I can't think of any security issues with onpaste. But for Mozilla's
implementation to be compatible with Internet Explorer's, Mozilla would have to
add support for window.clipboardData.getData(). Web pages would only be allowed
to call this function during legitimate onpaste events. (See example on
I'm a little worried about oncut/oncopy: a web page might convince you to copy
something from the page and paste it back into the same page, but use oncopy to
cancel the copy command, causing the paste command to reveal what was in your
clipboard before. There might be other ways for web pages to prevent cut/copy
commands from succeeding, but I'd prefer to avoid legitimizing this security
hole by turning it into a feature.
Onbeforepaste (etc) sound like they give scripts a new way to detect or slow
down the display of context menus. Should onbeforepaste be disabled when the
user unchecks "allow scripts to... disable or replace context menus"?
Here's the use case, although when I read it, it still seems to only be about
onpaste to me:
Here's an example of where we trap it and use it.
Form designer sets up an <input type="text"> field. Tells us he wants it to be
a number of the format (Java number format) $ #,###,###0.00;($ #,###,##0.00).
Sets some limitations (e.g., value must be provided, must be between -10,000 and
1,500,000), and they ask for full keyboard assist while the field is active
(i.e., has focus).
We attach a huge blob of Javascript to the field which currently traps the
following events: onFocus, onBlur, onKeyDown, onKeyUp, onKeyPress, onClick, and
in IE, onPaste, onCut, and onCopy.
Now lets say the field's initial value is 789. While the field doesn't have
focus, we'll display:
$ 789.00
When the field gets focus, we'll display:
$ ****789.00
And initially position the cursor after the 9 (before the decimal point). The
use types a 1, this will result in the following being displayed:
$ ***7,891.00
And the cursor will stay just before the decimal point.
User now selects "7,89". Then they do a Copy (either CTRL+C or menu command).
They position the cursor in front of the first asterick and do a paste.
In IE we trap the paste, get the content of the clipboad and strip it down to
pure digits, then do the insert (and return false in the event handler so IE
doesn't do the paste) which will result in:
$ 7,897,891.00
In Mozilla, we can't trap the event other than an "onchange" occurred. We don't
know what the user did, but we do know the current value of the field is ($
789***7,891.00 and that this is invalid so we discard what happened and revert
to the previous value.
The net is, when we're doing keystroke-by-keystoke assist on input, in IE you
can do cut/copy/paste. In Mozilla, we don't allow it.
Incidentally, the oncut/oncopy/paste events aren't necessarily just about
touching clipboard data - you want to know when the event happens so you can
manipulate the entryfield data.
Seems like type="number" would be a better way of doing the use case described
above. I'm still not really convinced this is a good thing.
for their use case, can't they just strip out the *'s (and ,'s) and then put
them back?
i really am not compelled by their case.
Here's the cut case:
We currently only modify the data in the onCopy/onCut in one case (though we'll
probably extend this).
Consider a "date" field with the value:
February 8, 2004
When you copy it, we convert it to 02-02-2004 00:00:00 (and put this on the
clipboard). In other words, date (date/time) are always copied to the clipboard
in a "neutral" format rather than as a raw string.
Then when you do a paste (at least into another "date" field), we can use the
date in this canonical form and not have to worry about trying to parse out
something like "February" (which might be a different word if the field used a
different locale than where we're doing the paste).
One problem with the MS implementation of the clipboard is that it doesn't allow
you to set multiple versions of the data in the clipboard object (e.g., we
really should be able to set the data as a "datetime" object and as a string so
that on a paste we can choose the 'best" data format given the target of the paste.
i've very scared of oncopy/oncut (we already have problems stemming from
anonymous/hidden content). protected by security requirements, i suppose this
could be ok.
i think that the web app should probably just deal with bad input, after all,
what happens when i copy "February 8, 2004" from notepad? And I certainly don't
expect to have "February 8, 2004" pasted into notepad as 02-02-2004 00:00:00.
The date use case would be better handled by a native type="date" control, as
proposed in Web Forms 2:
I understand there are better ways to do it, but none of those exist today.
There is an API in IE that we could emulate today for apps that use it.
(In reply to comment #13)
> I understand there are better ways to do it, but none of those exist today.
Support in Gecko does not exist today either.
For reference
Note that this is already possible using other methods. Catching the CTRL+C
event and put the text in a (hidden) textarea and when someone does CTRL+V you
put the (modified) text back. (Although that is only possible on one page,
No, they could be using the cut/copy/paste menuitems as well.
Apple has a write-up on Safari's support for "Pasteboard operations" (onbeforecut, oncut, onbeforecopy, oncopy, onbeforepaste, onpaste).
Absent from these implementations is "onundo".
(In reply to my own comment #5)
> I'm a little worried about oncut/oncopy: a web page might convince you to copy
> something from the page and paste it back into the same page, but use oncopy to
> cancel the copy command, causing the paste command to reveal what was in your
> clipboard before. There might be other ways for web pages to prevent cut/copy
> commands from succeeding, but I'd prefer to avoid legitimizing this security
> hole by turning it into a feature.
I filed bug 363132 on this issue.
Created attachment 271833 [details] [diff] [review]
proposed patch
The attached proposed patch adds support for oncopy, oncut, onpaste, onbeforecopy, onbeforecut, and onbeforepaste events.
onbefore[cut,copy,paste] events are fired when the selection is changed, and are intended to inform the browser whether the operation is permitted. If the event handler returns false, that prevents the default calculation that takes place to determine whether the operation is permitted. For example, if you create a <div onbeforepaste="return false;">, and select text within the div, you'll find that the Edit > Paste menu option is enabled. The implementation of these event handlers is consistent with IE, but IE fires the events whenever the menu or context menu is opened, where this patch fires the events only when the selection is changed.
on[copy,cut,paste] occurs before the operation. They can abort the operation if the event handler returns false. The implementation of these event handlers is consistent with IE and Safari.
I will attach a test file that can be used to test the behaviour.
Created attachment 271834 [details]
clipboard event handler playground
Attaching "playground" file with a few different tests of the event handlers.
I should add a note that this patch does not modify or permit additional clipboard access in any way. I didn't want to trod on that security concern until some consensus could be reached as to what additional access, if any, these events should provide.
At first glance, this patch doesn't guard against malicious script (e.g. script calling window.close() in the oncopy handler will null out mPresShell, causing the browser to crash).
Also, the event name detection code in nsDOMClassInfo.cpp probably needs changign too.
You probably want to ask email@example.com for review...
Boris, thank-you for the feedback. Along the same line, I've put together a number of potential problems with the patch. I'll submit an updated one with a fixes to your concerns and more tomorrow. Thanks.
Comment on attachment 271833 [details] [diff] [review]
proposed patch
>RCS file: /cvsroot/mozilla/layout/base/nsDocumentViewer.cpp,v
> NS_IMETHODIMP DocumentViewerImpl::CopySelection()
>+ if (!NS_FAILED(rv))
use NS_SUCCEEDED not, !NS_FAILED, use NS_FAILED, not !NS_SUCCEEDED
>+nsresult DocumentViewerImpl::GetClipboardEventTarget(nsIDOMNode** eventTarget)
>+ NS_ENSURE_ARG_POINTER(eventTarget);
>+ if (!mPresShell) {
>+ return NS_ERROR_NOT_INITIALIZED;
>+ }
you're using two different bracing styles (above/below), that's not generally correct.
>+ if (NS_FAILED(rv))
>+ return rv;
>+ if (!sel)
>+ return NS_ERROR_FAILURE;
>+ // should skip default behaviour here if event handler returns false, but
please spell behavior the American way. (yes there are a handful of behaviours in our code, but there are more than 1000 for the American way and being relatively consistent is a win.)
Created attachment 272018 [details] [diff] [review]
proposed patch v2
Attaching updated patch.
This patch addresses bzbarsky's concerns about crashing if window.close() is called by a malicious event handler, and updating event name detection code in nsDOMClassInfo.cpp.
This patch also addresses the comments by timeless. Thanks.
Additionally, this patch also adds support for the events on nsPlaintextEditor (<input>, <textarea>, and by inheritance Midas rich-text editors).
Created attachment 272019 [details]
updated clipboard event handler playground
Comment on attachment 272018 [details] [diff] [review]
proposed patch v2
Smaug, can you review this? Once you're done, I can sr...
I have to say this: I don't see a compelling reason to bring this code into our tree. Several times, use cases have been requested, and not much has come back. I believe this whole concept is a bit risky, at best a corner case.
This is certainly something I've heard requested *very* many times, and I would not be opposed to see this code in our tree. Whether it's 1.9 material or not is another question (probably safer not to take it given how close to beta we are and the possible security implications of a change like this).
I'm interested in the addition of these events to facilitate smart rich-text editing with the new contentEditable areas (bug 237964). Specifically, the addition of these events allows complete monitoring of when a contentEditable area has changed. Previously, using iframes (w/ designMode=on), it was possible to monitor for changes using DOM mutation events. Those events are fired at the document level though, which makes it quite difficult (and a big performance killer) to use on contentEditable areas.
I would definitely like to see this patch in 1.9, as I believe that content editable (237964), also targeted for 1.9, brings an increased need for it. I don't believe that there are security concerns regarding clipboard contents, as the patch implementation makes no clipboard contents readable or modifiable.
The current patch does allow a page to disable copy/cut/paste without any possibility of a user override, and I could see this being used in an annoying fashion (although it's a limited annoyance). If it would eliminate a barrier to getting this patch into 1.9, I'd be glad to remove that functionality, as personally I just need event notification.
Nominating for blocking1.9 based on that feedback. Thanks.
Jesse, any more feedback on this issue wrt privacy/security?
Comment on attachment 272018 [details] [diff] [review]
proposed patch v2
>+ static nsresult GetClipboardEventTarget(nsISelection *aSel, nsIDOMNode **target);
Add comment about what the method does here.
Not |target| but aTarget.
>+nsresult nsCopySupport::GetClipboardEventTarget(nsISelection *aSel, nsIDOMNode **eventTarget)
>+ NS_ENSURE_ARG(aSel);
>+ NS_ENSURE_ARG_POINTER(eventTarget);
Not eventTarget (or should it be target as in header) but aEventTarget.
Initialize the out parameter to nsnull, *aEventTarget = nsnull;
>+ nsCOMPtr<nsIDOMRange> range;
>+ nsresult rv = aSel->GetRangeAt(0, getter_AddRefs(range));
>+ if (!NS_FAILED(rv))
>+ rv = range->GetStartContainer(eventTarget);
NS_ENSURE_SUCCESS(rv, rv);
rv = range->GetStartContainer(eventTarget);
Is it possible that GetRangeAt returns null range but NS_OK?
Then you should check also that range is not null.
> NS_IMETHODIMP nsPlaintextEditor::Paste(PRInt32 aSelectionType)
> {
>+ if (!mPresShellWeak)
>+ return NS_ERROR_NOT_INITIALIZED;
Do you need this null check? Isn't do_QueryReferent null-safe.
Same thing also elsewhere.
>+ if (NS_SUCCEEDED(res))
>+ {
I'd prefer having { in the same line as |if|, though the file doesn't seem
to have consistent coding style conventions.
>+ if ((evt.flags & NS_EVENT_FLAG_NO_DEFAULT) == NS_EVENT_FLAG_NO_DEFAULT)
>+ return NS_OK;
>+ }
Check (status == nsEventStatus_eConsumeNoDefault) and then return.
Status will have that value if PreventDefault was called.
Same thing also elsewhere.
(I know, we should get rid of nsEventStatus eventually.)
> NS_IMETHODIMP nsPlaintextEditor::CanPaste(PRInt32 aSelectionType, PRBool *aCanPaste)
>+ // Fire the onbeforepaste event. If the event handler requests to prevent
>+ // default behavior, set *aCanPaste = true. (IE-style behavior)
This sounds odd. I would have thought that if preventDefault is called, then
aCanPaste would be false. But I don't have IE here to test.
>+ nsCOMPtr<nsIDOMNode> eventTarget;
>+ nsresult res = GetClipboardEventTarget(getter_AddRefs(eventTarget));
>+ // On failure to get event target, just forget about it and don't fire.
>+ if (NS_SUCCEEDED(res))
>+ {
>+ nsEventStatus status = nsEventStatus_eIgnore;
>+ nsEvent evt(PR_TRUE, NS_BEFOREPASTE);
>+ nsEventDispatcher::Dispatch(eventTarget, ps->GetPresContext(), &evt, nsnull, &status);
>+ // if event handler return'd false (PreventDefault)
>+ if ((evt.flags & NS_EVENT_FLAG_NO_DEFAULT) == NS_EVENT_FLAG_NO_DEFAULT)
>+ {
>+ *aCanPaste = PR_TRUE;
>+ return NS_OK;
>+ }
>+ }
> // can't paste if readonly
> if (!IsModifiable())
> return NS_OK;
Should the event dispatching happen after this check? What does IE do with readonly controls? And Safari?
> NS_IMETHODIMP nsPlaintextEditor::CanCut(PRBool *aCanCut)
> {
>+ *aCanCut = !isCollapsed && IsModifiable();
Should IsModifiable() check happen before event dispatch? Make sure this is consistent with what IE does
with readonly controls.
> NS_IMETHODIMP nsPlaintextEditor::CanCopy(PRBool *aCanCopy)
> {
> if (!aCanCopy)
> return NS_ERROR_NULL_POINTER;
>+ if (!mPresShellWeak)
>+ return NS_ERROR_NOT_INITIALIZED;
>+ nsCOMPtr<nsIPresShell> ps = do_QueryReferent(mPresShellWeak);
>+ if (!ps)
>+ return NS_ERROR_NOT_INITIALIZED;
> *aCanCopy = PR_FALSE;
In all CanXXX methods keep *aCanCopy = PR_FALSE; statement right after
if (!aCanCopy)
return NS_ERROR_NULL_POINTER;
> NS_IMETHODIMP DocumentViewerImpl::CutSelection()
>+ if (NS_SUCCEEDED(rv))
>+ {
if (...) {
Also elsewhere in this file.
>+ nsEventStatus status = nsEventStatus_eIgnore;
>+ nsEvent evt(PR_TRUE, NS_CUT);
>+ nsEventDispatcher::Dispatch(eventTarget, mPresContext, &evt, nsnull, &status);
>+ // should skip default behavior here if event handler returns false, but
>+ // there is no default behavior to worry about.
In that case status parameter isn't needed at all, 3 first parameters to Dispatch should be enough.
Also elsewhere.
Created attachment 272188 [details] [diff] [review]
proposed patch v3
New patch v3 addresses all style comments from Smaug, out parameter initialization, remove redundant null checks for mPresShellWeak, and so on.
(In reply to comment #33)
> This sounds odd. I would have thought that if preventDefault is called, then
> aCanPaste would be false. But I don't have IE here to test.
IE & Safari's behavior is definitely that aCanPaste would be true. I believe the reasoning is that this is the only way you could enable the "Paste" menu option for areas where pasting is normally not permitted (for example, a plain 'ole <div>). The default behavior being prevented by a "return false" is the correct calculation of aCanPaste.
> Should the event dispatching happen after this check? What does IE do with
> readonly controls? And Safari?
The event dispatching can replace the IsModifiable check, to permit pasting in readonly controls (or even in places where it doesn't normally make sense). I've tested against readonly textareas in IE and Safari, and both will permit pasting if onbeforepaste="return false". (However, Safari will prevent Ctrl-V from working or firing onpaste, but since it is internally inconsistent [the menu option works, but the key combo doesn't], I'm pretty sure it's a Safari bug.)
> Should IsModifiable() check happen before event dispatch? Make sure this is
> consistent with what IE does
> with readonly controls.
IE and Safari appear to fire the event before all other checks, giving it absolute priority.
> In all CanXXX methods keep *aCanCopy = PR_FALSE; statement right after
> if (!aCanCopy)
> return NS_ERROR_NULL_POINTER;
I'd prefer we didn't null-check XPCOM out params at all (since in JS you can't screw it up, and in C++ people really shouldn't), but if we do it, please use NS_ENSURE_ARG_POINTER(aCanCopy)....
Updated patch v3 uses NS_ENSURE_ARG_POINTER for null-checking out params.
You may have to ignore the "res" gripes; the local file uses res already.
Created attachment 272227 [details] [diff] [review]
proposed patch v4
Alex, thanks for the pointer to jst-review. I've corrected the details it has pointed it in a new attached patch. The only problems not corrected were long line lengths in a mapping of event handler atoms to event handler codes in nsContentUtils.cpp, which matches the style of surrounding code.
v4 of this patch fixes a crash that was possible when an onpaste event handler on an input element caused the element to be removed from the document. The check for 'if (mDidPreDestroy)' in nsPlaintextEditor::Paste addresses this crash.
v4 also fixes a problem where onpaste and onbeforepaste weren't fired for content editable areas due to nsHTMLEditor overriding the ::Paste and ::CanPaste methods.
Created attachment 272228 [details]
clipboard event handler playground v3
Attaching updated testing file.
Created attachment 272405 [details] [diff] [review]
mochitest tests
Attaching mochitest unit tests for oncopy / oncut / onpaste event handlers.
Comment on attachment 272227 [details] [diff] [review]
proposed patch v4
>+ { &nsGkAtoms::oncopy, { NS_COPY, EventNameType_HTMLXUL }},
>+ { &nsGkAtoms::oncut, { NS_CUT, EventNameType_HTMLXUL }},
>+ { &nsGkAtoms::onpaste, { NS_PASTE, EventNameType_HTMLXUL }},
>+ { &nsGkAtoms::onbeforecopy, { NS_BEFORECOPY, EventNameType_HTMLXUL }},
>+ { &nsGkAtoms::onbeforecut, { NS_BEFORECUT, EventNameType_HTMLXUL }},
>+ { &nsGkAtoms::onbeforepaste, { NS_BEFOREPASTE, EventNameType_HTMLXUL }},
Does Safari (or Opera?) support these attributes also in SVG? If it does, we should also.
>+ // Given the current selection, find the target that
>+ // onbefore[copy,cut,paste] and on[copy,cut,paste] events will fire on.
Nit, the event names are (before){0,1}(copy|cut|paste). Attribute and JS property names
start with 'on'. Same also elsewhere.
Maybe a folloup bug to reduce code duplication in nsXXXEditor::CanPaste and nsXXXEditor::Paste etc methods.
It would be great if you could add the tests for possible crashes also to mochitest.
All cases when during event dispatch window is closed or element removed from dom.
Does IE also dispatch beforecut,beforecopy,beforepaste and again beforecut
when clicking for example 'Content here is editable!'?
(In reply to comment #41)
> Does Safari (or Opera?) support these attributes also in SVG? If it does, we
> should also.
A quick test shows that neither Safari nor Opera support these events in SVG.
> [snip -- nit, will fix; add crash tests, will do; file bug to reduce
> code duplication, will do]
> Does IE also dispatch beforecut,beforecopy,beforepaste and again beforecut
> when clicking for example 'Content here is editable!'?
IE dispatches the before(cut|copy|paste) events only when the "Edit" menu or the right-click context menu is opened. That seems to be when it determines whether the menu options are enabled or disabled. This patch fires the before(cut|copy|paste) events whenever the selection is changed, as that appears to be when the menu option status is updated. This does result in the events likely firing more often than IE, depending on the what the user is doing.
beforecut appears to be fired twice because the delete command calculates whether the delete menu is enabled by calling CanCut. It's probably not the right behavior to potentially enable/disable the Delete menu option based upon the return value of the beforecut event, so I will change this to use it's own code path (unless anyone has another suggestion?)
Created attachment 272428 [details] [diff] [review]
proposed patch v5
Attached proposed patch v5. Changed comments to reference events by the proper name (thanks Smaug). Fixed bug in nsCopySupport::GetClipboardEventTarget where NS_ENSURE_SUCCESS was logging errors whenever the selection was collapsed (I misunderstood the purpose of this macro).
Created attachment 272429 [details] [diff] [review]
mochitest tests (v2)
Attached updated unit tests (v2). Includes tests for crashes caused by closing the window on event handlers, or removing the HTML element being affected by the event.
I wasn't sure where to put these tests, by the way, so I put them into dom/tests/mochitest/bugs/test_bug280959.html.
This patch also includes a modification to widget/src/windows/nsWindow.cpp. SendKeyEvent was crashing when the window was closed in the new unit tests. A patch to nsWindow::DispatchEvent checks whether the window has been destroyed during the event handler. I wasn't sure if this should be filed as a separate bug with a separate patch... but since without this patch, the unit tests crash, I thought it was pretty important it be included here.
Comment on attachment 272429 [details] [diff] [review]
mochitest tests (v2)
Is this really the right version of the test?
Where are the open/remove element tests?
>+// Randomize the order of the tests. They should operate in any order.
>+// The possibility of randomly occuring test failures is quite dreadful,
>+// so only use this code when working on this file to ensure that object
>+// states are restored properly between tests.
>+// testFunctions.sort(function() { Math.round(Math.round()) - 0.5; });
I think you were going to write Math.round(Math.random()).
But randomizing tests this way makes debugging difficult if tests start to fail in some cases.
>Index: widget/src/windows/nsWindow.cpp
My guess is that this might not be the right fix.
I'd try to change nsIWidget* widget to nsCOMPtr<nsIWidget> widget
in nsDOMWindowUtils::SendKeyEvent. See also Bug 381993.
Created attachment 272490 [details] [diff] [review]
mochitest tests (v3)
Attaching updated mochitest unit tests.
This version has the new crash tests. I was working on the unit tests yesterday in my OBJDIR so I could just keep reloading the tests as I worked on them (Windows, no symlinks). Then I forgot to copy them up into the right location before creating the patch. And then I ran a build and overwrote the new tests. The good thing about writing the same code twice in 12 hours is that it comes out cleaner the second time.
Also, I tried changing the fix for the SendKeyEvent crash, as you suggested. It worked perfectly, so I have included that fix in this patch, rather than my previous attempt.
Created attachment 272491 [details] [diff] [review]
mochitest tests (v4)
Oops, forgot to comment out the random sorting of the tests. :-) This was intended to be commented out in the submitted patch to make debugging a failed test easier (but enabled when writing the tests, to make sure no state changes leak between tests).
Comment on attachment 272428 [details] [diff] [review]
proposed patch v5
>+ if (!(*aEventTarget))
>+ return NS_ERROR_FAILURE;
>+ return NS_OK;
return (*aEventTarget) ? NS_OK : NS_ERROR_FAILURE;
>\ No newline at end of file
Nit ^^^
>@@ -1292,16 +1293,28 @@ const char* nsDOMEvent::GetEventName(PRU
To keep nsDOMEvent::GetEventName in sync with nsDOMEvent::SetEventType, please
update also the latter one.
The few "extra" beforeXXX events are probably ok, and anyway needed by ControllerCommands.
Did you test that events are dispatched to right targets when bidi-text is used?
With comments addressed, r=me, but if bidi needs for some reason more changes, I could re-review.
Comment on attachment 272491 [details] [diff] [review]
mochitest tests (v4)
>- nsIWidget* widget = GetWidget();
>+ nsCOMPtr<nsIWidget> widget = GetWidget();
You could put this to your "main patch".
>+// Randomize the order of the tests. They should operate in any order.
>+// The possibility of randomly occuring test failures is quite dreadful,
>+// so only use this code when working on this file to ensure that object
>+// states are restored properly between tests.
>+// testFunctions.sort(function() { Math.round(Math.random() - 0.5); });
Please do not leave this here.
Could you use 2 space indentation and |for (expr; expr; expr) {|
and |if (expr) {| and |function name(params) {| coding style.
>+// Run delayed tests.
>+var num = delayedTests.length;
>+var delay = 1000; // 1 sec
>+for (let i = 0; i < num; i++)
>+ setTimeout(delayedTests[i], i * delay);
>+setTimeout(SimpleTest.finish, num * delay)
Couldn't you change this so that when the previous test has run, the next one
starts immediately. Should take less time that way to run the tests.
Created attachment 272789 [details] [diff] [review]
proposed patch v6
Revised patch based upon Smaug's comments: added code for SetEventType, changed an if-return-return into a return (x ? y : z), added newline at the end of nsCopySupport.cpp, and included the testing bug fix in nsDOMWindowUtils.cpp.
Tested patch w/ dir="rtl". Appears to be no issues, events fire as expected and clipboard contains expected text.
Requesting superreview.
Created attachment 272790 [details] [diff] [review]
mochitest tests (v5)
Attaching new mochitest file. Fixes JS formatting as requested, removes offending random test ordering code, and runs tests without delay (and, not too surprisingly, much quicker).
I certainly remember trying to have the tests run one-after-another rather than using a 1 second delay, and running into problems getting that to work. However, a fresh look at the problem came up with a solution very quickly.
Comment on attachment 272790 [details] [diff] [review]
mochitest tests (v5)
>+ var handlers = ['oncopy', 'oncut', 'onpaste'];
>+ var handlers = ['oncopy', 'oncut', 'onpaste'];
Test also onbeforeXXX
Created attachment 272800 [details] [diff] [review]
mochitest tests (v6)
Added crash tests for before events as requested.
Jonas, bz, Jesse, Damon and I got together and talked about whether we want to take this for 1.9 or not and the outcome of that was that we do want this for 1.9, so marking this as a blocker. That means it needs to go in before the code freeze next Wednesday (7/25). I'll be sr'ing this, and Jonas will help audit the new places in the code where we will now end up dispatching events where we didn't already do so, just to make sure we don't introduce event dispatching at unexpected and potentially unsafe times.
Thank you Mathieu for the patch and tests!
Comment on attachment 272789 [details] [diff] [review]
proposed patch v6
- In nsPlaintextEditor::Cut():
+ // Fire the copy event.
sr=jst, but I'm not marking this as such yet as Jonas will have a look at this one as well before we'll land it. Thanks for the patch!
So the functions called from isCommandEnabled scares me a bit. These are GetCopyable, GetCutable, GetPasteable. The other callsites look ok, though it might be good to see if we can whack at the events a bit.
(In reply to comment #56)
> So the functions called from isCommandEnabled scares me a bit. These are
> GetCopyable, GetCutable, GetPasteable. The other callsites look ok, though it
> might be good to see if we can whack at the events a bit.
The before[cut|copy|paste] events respond to indicate whether the commands are enabled. Given that purpose, it's a logical map to fire them from isCommandEnabled. Do you think this will cause problems? Or is it just that it's unusual? I can't think of any other event that fires to enable/disable commands, so it probably is unusual.
I certainly don't like the before* event names, since I think they don't describe the events well. But they're implemented to match IE & Safari.
Comment on attachment 272789 [details] [diff] [review]
proposed patch v6
So I *think* that the current callsites are safe enough as far as crashing goes. I would feel better if we fired the onbefore* stuff somewhere else though.
I'd say lets land with these events, but lets try to hammer on them some extra and do stuff like set document.location or remove document.documentElement from within an onbefore* event.
What i'm worried about is page javascript intentionally doing something evil when those events are fired, such as navigate to a new page, or make sure that the document is being destroyed. It is possible that the calling code will not be able to deal with this and crash in exploitable ways.
I agree it is the logical place to fire the events. I'm just worried that executing untrusted code at that point is unsafe.
> do stuff like set document.location or remove document.documentElement
Or remove window.frameElement from the parent document's DOM. That should tear down the docshell and editor nicely when using contenteditable, and might be interesting to test.
Also worth settng window.frameElement to display:none and flushing out layout on the parent. That'll destroy the frame tree bit not the docshell, which might also be an interesting condition to be in.
Most importantly, we want automated tests doing that in case someone changes some codepaths around.
Should this be marked as FIXED?
Apparently mochitest wasn't checked in
The patch was apparently checked in at 2007-07-25 21:14.
What a mess. Yes, this landed (the patch, not the tests yet), and it landed with a checkin comment (by me) that didn't include the bug number, and the comment I wrote in this bug about that never made it into the bug. But yes, this is fixed, but I don't think we should mark it as such before the tests are checked in (I'm planning on doing that as soon as I'm permitted to).
jst, want to file a bug to get that comment cvs adminned to include the bug#?
Bug 390375 filed to add the bug reference to the checkin comment.
Is it permissible for the tests to be checked in now, under the new trunk rules?
Yes, go ahead.
checkin-needed for mochitest patch.
Tests checked in. Marking bug FIXED. Thanks Mathieu Fenniak for all your work here!
The tests didn't stick, turned the tree orange (due to test failure). Please provide updated tests and I can land them...
Created attachment 275550 [details] [diff] [review]
mochitest tests (v7), but still don't work in batch test run
The tests that are failing are the copy/cut/paste event handlers being placed on DOM elements (as opposed to editors). The tests run successfully & reliably when the single test is run (just test_280959.html), but fail when run from the batch test page.
I narrowed the problem down to synthesizeKey in test_dom_* -- it appears that sometimes the window didn't have focus, and so the key events to copy/cut/paste weren't being received by the window. I've addressed this by starting the script off with a "window.focus()" and running the tests in "window.onfocus".
Now the tests run successfully, consistently, when run from /tests/dom/tests/mochitest/bugs/... but not from one level up (/tests/dom/tests/mochitest/). I'm not sure what the problem is. Is it possible that other tests can be interfering with these tests? I will continue to investigate tomorrow.
(attaching current improved tests that still don't work in a large batch test run, in case anyone has input)
This is probably unrelated to the test failure, but I see this error in the error console while carrying out the test: Error: synthesizeKey is not defined
With one test, you have:
<body onload="var sel = window.getSelection(); sel.removeAllRanges(); sel.selectAllChildren(document.body); synthesizeKey('v', {accelKey: 1});" onunload="window.opener.runNextTest();" onbeforepaste="window.close();">
It seems to me that as soon selectAllChildren is called, the code in onbeforepaste is called, so that's why the synthesizeKey error, I guess.
+ ok(true, handler + " did not cause crash by closing window.");
I´m not sure what this is testing, it seems to me that handler can never be false here.
After long searching, I think I found out that running the test_Prototype.html test beforehand is causing this bug's test to fail.
So it seems like some test in the test_Prototype.html tests is causing it to fail.
I have come to the same answer, after testing each DOM ajax test suite. Removing test_Prototype.html causes these tests to always run successfully. I am glad to hear that I am not crazy for thinking this, since it was a satisfying conclusion that my code isn't completely faulty.
I would guess that test_Prototype.html is somehow polluting the test environment, but I haven't the faintest idea what could cause only a couple of these tests to fail. I'm planning on hacking off parts of test_Prototype.html until the cause of failure is left standing, and we'll see what that is.
The test error only occurs when:
1. The Minefield window has focus for the test. If "Run Tests" is hit, and another program activated (eg. the debugger), the tests succeed.
2. And testFormElementMethodsChaining in dom\tests\mochitest\ajax\prototype\test\unit\form.html is run before test_bug280959.html. More specifically, when testFormElementMethodsChaining calls the Prototype .activate() method on any form element on the page, which then calls the .focus() method on the element.
When these components of the test failure are in place, the following occurs:
3. Error messages on the console:
WARNING: NS_ENSURE_TRUE(docShell) failed: file p:/moz-hg/mozilla/dom/src/base/nsGlobalWindowCommands.cpp, line 493
WARNING: NS_ENSURE_TRUE(contentEdit) failed: file p:/moz-hg/mozilla/dom/src/base/nsGlobalWindowCommands.cpp, line 446
4. The command context that the clipboard command receives is null, and this appears to be the result of the focus controller's mCurrentWindow being mis-set. mCurrentWindow has mDocument == nsnull.
I am still not sure how these elements all tie together. Given that point 2 is required for the failure to occur, it suggests to me that the focus controller has bad state leftover in it somehow. Does anyone reading this think, "oh, that's got to be...."?
Thanks for finding this out, Mathieu!
I was trying to making a testcase out of this, but I failed.
However, I tripped on bug 385478 again, while doing that. I'm wondering if it's related to this issue.
Maybe the patch from bug 261074 (which was backed out) would fix this test failure?
Needless to say a minimized testcase would help a lot here of what is going on.
(In reply to comment #77)
> Maybe the patch from bug 261074 (which was backed out) would fix this test
> failure?
No, the patch from bug 261074 doesn't fix it.
(In reply to comment #71)
> The tests didn't stick, turned the tree orange (due to test failure). Please
> provide updated tests and I can land them...
Which tinderboxes turned orange? All of them? Or only Windows?
Not blocking on getting the tests in. But please see if you can get them working because not having tests at all makes the whole feature much more likely to regress.
A simple test of the onbeforeXxx events (http://people.mozilla.com/~dholbert/tests/394818/onbeforecopy.html) show that they do not mimic IE behavior at all.
Uh.... we're firing these events when the document gets focus? That seems _very_ weird. Very very weird.
Weird enough that it seems like it would break pages actually using these events. Can we get a bug filed on sorting that out? That bug should block, imo.
It seems to me that is what bug 390238 was about.
Except the testcase cited in comment 81 doesn't have a text control. In fact, it has absolutely no way to cut anything. And more importantly, the command state is not actually changing (nothing is selected; we just focused the window), and yet we're still firing the event...
(In reply to comment #82)
> Uh.... we're firing these events when the document gets focus? That seems
> _very_ weird. Very very weird.
If Bug 144000 is backed out, those events don't fire.
Uh.. but a collapsed selection is not copyable. Clearly the event-firing code is overeager. Would it fire on every caret move during editing or caret browsing?
(In reply to comment #87)
> Uh.. but a collapsed selection is not copyable.
But perhaps still pasteable
> Would it fire on every caret move during editing or caret browsing?
Doesn't seem so
Why would it break pages to ask "should the Copy command be enabled now?" more often than IE?
Firing on every caret move sounds perfectly reasonable for onbeforepaste: a page might want you to be able to paste in some places but not in others.
(In reply to comment #89)
> Firing on every caret move sounds perfectly reasonable for onbeforepaste: a
> page might want you to be able to paste in some places but not in others.
That's not what onbeforepaste is for.
onbeforepaste Event
Fires on the target object before the selection is pasted from the system clipboard to the document.
This is supposed to be called when the user actually selected paste. It happens before paste and based on the return from the call, the paste happens or doesn't happen.
It's supposed to be designed so that on paste you can modify the data about to be pasted.
The MSDN documentation is misleading. It is fired "before the selection is pasted", but not immediately before, and not always.
The before[...] events in IE are fired when a user right-clicks to view a context menu, or opens the "Edit" menu. These firings are to check whether the relevant menu items should enabled / visible.
If I remember correctly from my testing, before[...] isn't fired *at all* during the actual operation, if you use keyboard shortcuts. And even if disabled by beforepaste, you can still use Ctrl-V to paste.
Mozilla's implementation fires before[...] events at different times (very different times), but to the same effect as IE. The events being fired on document focus is new, as Smaug points out.
Hmm. When I loaded the testcase from comment 81, I got about 20-30 alerts that I had to dismiss. Two came up every time I moused over the window. That's what comment 82 was based on.
Sadly, I haven't been able to reproduce that since... I just get the two alerts now.
(In reply to comment #91)
> The MSDN documentation is misleading. It is fired "before the selection is
> pasted", but not immediately before, and not always.
> The before[...] events in IE are fired when a user right-clicks to view a
> context menu, or opens the "Edit" menu. These firings are to check whether the
> relevant menu items should enabled / visible.
True. Testing on IE7 confirms this.
> If I remember correctly from my testing, before[...] isn't fired *at all*
> during the actual operation, if you use keyboard shortcuts. And even if
> disabled by beforepaste, you can still use Ctrl-V to paste.
False. The event fire when using keyboard shortcuts too.
> Mozilla's implementation fires before[...] events at different times (very
> different times), but to the same effect as IE. The events being fired on
> document focus is new, as Smaug points out.
Mozilla events fire way too soon for my taste. Firing on selection of text is too soon and too often. Not firing on keyboard shortcut or menu use is not right either. We will also hurt performance on websites that use these events.
The events have to fire on selection change when the cut/copy/paste toolbar buttons are visible, at least.
(In reply to comment #94)
> The events have to fire on selection change when the cut/copy/paste toolbar
> buttons are visible, at least.
You would think - [onbeforeXxxx events can cancel behavior so we should disable buttons] - but after putting the cut/copy/paste buttons on the IE7 toolbar, I get no onbeforeXxx alerts when selecting text.
We don't have to match IE bug for bug :)
So the question is, is onbefore* in its _current_ form similar enough to the IE behavior that it sites will JustWork? If not, we have two options:
1. Fix the implementation so that sites will JustWork
2. Remove support for the onbefore* events in gecko 1.9
At this point, I'd say we should only do 1 if it's relatively easy. The onbefore* events are pretty scary as is actually.
(In reply to comment #96)
> We don't have to match IE bug for bug :)
Didn't microsoft invent these messages? So there is no spec for them other than microsoft? So if we want them to work as people expect them to work, we should match IE bug for bug. Because that's how the messages work...
(In reply to comment #98)
> (In reply to comment #96)
> > We don't have to match IE bug for bug :)
> Didn't microsoft invent these messages? So there is no spec for them other than
> microsoft? So if we want them to work as people expect them to work, we should
> match IE bug for bug. Because that's how the messages work...
I believe that Jesse was referring to the fact that the cut/copy/paste status isn't updated properly when the buttons are on the toolbar. That definitely sounds like an IE bug, since you won't be able to disable the buttons based upon the selection context.
(In reply to comment #97)
> So the question is, is onbefore* in its _current_ form similar enough to the IE
> behavior that it sites will JustWork?
Yes, I believe so.
The before events are intended to determine whether the action is available to the user. They are badly named. For evidence to support this statement, I point out that the events are fired whenever a user opens the "Edit" menu or right-clicks, regardless of whether they intend to perform an action related to these events.
Developers currently using these events in IE should have noticed that, in IE:
* They have to be fast, because they occur when opening a dropdown menu. You don't want to delay the "Edit" menu for the user.
* They will be called even when the following event doesn't occur. (ie. beforepaste will be fired even if a paste never occurs).
The same rules apply to the Mozilla implementation. The event handler has to be fast, and it will be called even when the following event doesn't occur. It just happens to be called at a different arbitrary time.
I would be surprised to find a page that works nicely in IE using these events, but does not work in Mozilla. I think it would require using these events for some purpose beyond my imagination.
(In reply to comment #97)
> So the question is, is onbefore* in its _current_ form similar enough to the IE
> behavior that it sites will JustWork?
I'd lean towards "no". (though I don't really know how current sites use onbefore*, so I'm not 100% sure how the FF3 onbefore* quirks would affect them.)
See https://bugzilla.mozilla.org/show_bug.cgi?id=410858#c1 for a list of various onbefore* experiments & their results in FF3 and IE7. (the experiments all refer to the first testcase posted on that bug, attachment 295447 [details]).
Those experiments show that FF3 treats onbefore* pretty differently from IE7... In particular, for experiments A-G, IE7 does absolutely nothing whereas FF3 fires one or more sets of events. And in the final two experiments (H and I), both IE7 and FF3 do something, but they still do somewhat different things.
(In reply to comment #100)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=410858#c1 for a list of
> various onbefore* experiments & their results in FF3 and IE7. (the experiments
> all refer to the first testcase posted on that bug, attachment 295447 [details]).
> Those experiments show that FF3 treats onbefore* pretty differently from IE7...
See also https://bugzilla.mozilla.org/show_bug.cgi?id=410858#c4 for two more experiments...
e.g. experiment I -- I don't see why FF3 would needs to fire 6 onbeforeCut, 3 onbeforePaste, and 3 onbeforeCopy events when the user just single-clicks inside a textbox, especially given that IE7 fires no onbeforeXXX events at all in that situation
(In reply to comment #98)
> (In reply to comment #96)
> > We don't have to match IE bug for bug :)
> Didn't microsoft invent these messages? So there is no spec for them other than
> microsoft? So if we want them to work as people expect them to work, we should
> match IE bug for bug. Because that's how the messages work...
AFAICT, this isn't just a case of trying to match them on edge cases where they're buggy. In playing with the testcases I posted on bug 410858, I've had a hard time finding *any* situations in which we fire the exact same set of onbeforeXXX events as IE7. (though maybe the differences are irrelevant in real-world situations?)
So what is the usecase for onbefore*? I.e. what are people using it for currently? It's been mentioned the ability to disable cut/copy/paste from context menus. It's also been mentioned the ability to change what is actually cut/copy/pasted. Is there anything else? I'm a little surprised by the second example, I thought that that was what oncut/oncopy/onpaste was for, not the 'before' events.
Can people provide example snippets of code that they are currently using? This way we can determine if that will work in mozillas implementation too.
Btw, we need to make a decision pretty soon on this. We probably want to have this all taken care of by beta 3 which means that if someone needs to come up with a patch to fix onbefore*, that needs to happen really soon.
Without a patch we're likely to back out onbefore*, but still keep
I don't see what's wrong with leaving it as-is. It's more correct (because it allows for giving toolbar buttons the correct state) but puts the same requirements on web pages (onbefore* must be fast and should not change anything). It also avoids giving web pages a way to screw with all context menus, which IE's implementation allows.
(In reply to comment #104)
> I don't see what's wrong with leaving it as-is
I'm just a little skeptical about the correctness of the current implementation because we fire so many onBeforeXXX events in quick succession, many of which seem to be duplicates. As demonstrated in the experiments on bug 410858, very simple operations on very simple testcases can trigger 3 successive sets of {onBefCut, onBefCopy, onBefPaste}, when 0 or 1 set of those events would be sufficient.
Having said that...
1) Maybe there's a good reason for each of those seemingly duplicate events to be fired; I'm just not sure what it is.
2) Maybe the duplicates don't matter in real-world uses of onBeforeXXX
I'd really like for someone that is actually planning on using this to speak up.
Kaply; do you have any js code you could share?
(In reply to comment #105)
I must agree with Daniel Holbert.
To Mathieu Fenniak:
Your implementation uses "selection change" to trigger onbeforecopy and onbeforecut, which results in triggering these events at inappropriate times: that is, when selection changes (see attachment 295447 [details]).
Instead, these events should be related to the moment when the user manifests the intention of performing a clipboard operation, either by using the keyboard or the contextual menu or the application menu: CTRL+X and CTRL+C. This is why they are called "onBeforePaste" and not "onAfterSelectionChange".
They are not badly named as you claimed in comment #99.
In the IE implementation (Safari too): the onbefore events are NOT intended to determine whether the action is available to the user or not (as you said it), but instead, all these onBeforeXXX and onXXX events should give developers a chance to CANCEL the default action associated with the corresponding clipboard operation and implement a custom clipboard behavior. Check http://msdn2.microsoft.com/en-us/library/ms537658(VS.85).aspx or http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/CopyAndPaste.html for details.
Your actual code could be the starting point for a so much needed onselectionchange event, though.
Opening a context menu does not "manifest the intention of performing a clipboard operation". You haven't explained what Mozilla's behavior breaks, while it's clear what IE's behavior breaks.
Fwiw, this is an IE invention, so it would seem best to me to be compatible with IE.
(In reply to comment #106)
> I'd really like for someone that is actually planning on using this to speak
> up.
> Kaply; do you have any js code you could share?
Unfortunately not. But I have to agree with the other sentiments here. These features should be about IE compatibility. Not inventing our own way to do this.
(In reply to comment #110)
> These features should be about IE compatibility.
"IE compatibility" is a matter of debate. Yes, the events are fired at different times. But a reasonable implementation of the event handlers will result in the same end-user experience.
(In reply to comment #107)
> ... these onBeforeXXX and onXXX events should give developers
> a chance to CANCEL the default action associated with the corresponding
> clipboard operation and implement a custom clipboard behavior.
This may be what the documentation indicates, but it does not make logical sense when compared with the actual implementation. How is the event supposed to change the default action? The only function it can perform is to disable the menu option, which is the same functionality that Mozilla's implementation has.
(In reply to comment #107)
> They are not badly named as you claimed in comment #99.
"beforecut" is fired (even in IE, Safari) when the user has made no attempt to cut text. Doesn't that seem like the event name is wrong?
(In reply to comment #102)
> ... It's also been mentioned the ability to change what is actually
> cut/copy/pasted. Is there anything else? I'm a little surprised by the second
> example, I thought that that was what oncut/oncopy/onpaste was for, not the
> 'before' events.
This is not something that the before* events can do, even in IE.
As long as cut/copy/paste events remain, I don't care if the before events are removed. I think they're pretty much pointless, but also pretty much harmless.
(In reply to comment #111)
> As long as cut/copy/paste events remain, I don't care if the before events are
> removed. I think they're pretty much pointless, but also pretty much harmless.
Bug 394818 is actually a crash that's partly dependent on "onbeforecopy" firing (and causing frame destruction) after a focus change in the middle of frame destruction.
That's partly symptomatic of a deeper focus-related bug, but if onbeforecopy were removed (or were made to behave like IE and fired less), that bug would be fixed.
(In reply to comment #109)
> Fwiw, this is an IE invention, so it would seem best to me to be compatible
> with IE.
I think we all agree with that. The question is what it means to be "compatible with IE". It doesn't necessarily mean that we're firing the events at exactly the same time. It does mean that code written for IE will work in Firefox.
I filed now bug 415938 for the test failure, as this bug gets a little big.
I filed bug 420985 for the tests, this code landed, and keeping this bug open for the tests is just confusing.
(Note that support for the onbefore* events was backed out in bug 418457.)
These are now documented.
Is there an actual security issue with implementing the beforeXXX events, or is it just confusion over the intent of these events?
Some of the assessment above is incorrect (admittedly the documentation is mostly misleading or incorrect as well). The beforeXXX events are mainly intended to update the enabled/disabled state of the UI. The IE documentation for onbeforecut/onbeforecopy/onbeforepaste states this and all of the examples use the events this way (and only in that way) See, for example, http://msdn.microsoft.com/en-us/library/ms536902%28VS.85%29.aspx
The problems found by Daniel's testing done in bug 410858 isn't as noticable in current builds, possibly due to focus handling improvements. The tests are somewhat bogus since they display alerts; this can cause focus changes which can affect what happens (moreso on Linux).
> Is there an actual security issue with implementing the beforeXXX events
Depends on when they're fired and whether they give the page the ability to fully control what ends up in the clipboard.
> The beforeXXX events are mainly intended to update the enabled/disabled state
> of the UI.
This is mentioned above, yes. As well as the fact that IE is inconsistent in firing them, that they don't work well for keyboard copy/paste, etc, right?
(In reply to comment #117)
> Is there an actual security issue with implementing the beforeXXX events
Yes. My initial investigation here was due to bug 394818, a double-free that depended on onbeforecopy.
See in particular bug 394818 comment 7 -- basically, the issue there was that a style-change can cause frame destruction, which can implicitly change our focus (in the middle of the destruction), which can cause "onbeforecopy" to fire, which can trigger more frame destruction (while we're already in the middle of frame destruction).
If we can guarantee that won't happen anymore, then I'm less concerned about this.
(In reply to comment #118)
> > Is there an actual security issue with implementing the beforeXXX events
> Depends on when they're fired and whether they give the page the ability to
> fully control what ends up in the clipboard.
I wouldn't think we'd provide clipboard access during those events.
> This is mentioned above, yes. As well as the fact that IE is inconsistent in
> firing them, that they don't work well for keyboard copy/paste, etc, right?
Not sure what comment you're referring to above, but IE (and Safari and Chrome) always fire the beforeXXX event before the cut/copy/paste event when using the keyboard shortcut.
> If we can guarantee that won't happen anymore, then I'm less concerned about
> this.
Command updating that occurs from selection or focus changes are now run using AddScriptRunner.


text:
Results 1 to 1 of 1
Thread: Ireland Rose
- Join Date
- May 2013
- Posts
- 33,702
- Downloads
- 0
- Uploads
- 0
Ireland Rose
Download Kindle Book Now:Ireland Rose
Author: by Patricia Strefling
Current Price: Free
Click here to Download Book Now
:note: BEFORE Clicking the Purchase button, make sure that the price is STILL $0.00! While this post is free right now, it can change at any time!
This post was provided first by Budget101.com
Don't have a kindle? No problem, read ebooks for free with this Free Kindle Application for PC

subset: commoncrawl


text:
Well, I think I've definitely tested everyone's patience, but I think
I've finally got the pictures where everyone can view them. You just
have to wade around now to find them. There are three closeups
attached to one e-mail, and a whole plant shot attached to another.
Thanks to you all, but especially to Linda, for caring enough to ask
and to Mike for clearing up my confusion.
As for Catherine's question about increase. Already the plant has
quite a few side fans. I'd guess 7 or 8. Just take a look at the
whole plant picture. I hope they will bloom next year. Iris tectorum
has a bad habit of blooming every other year for me. I don't think
it's very happy where I have it.
Thanks again for your interest, Tom
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Stock for $4
and no minimums.
FREE Money 2002.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


text:
PRSA is now accepting presentation submissions for its annual International ConferenceNEW YORK, January 28, 2016 – The race to the PRSA 2016 International Conference in Indianapolis is underway. The Public Relations Society of America (PRSA) has opened its call for presentations and invites communication industry experts to share their research, strategies, best practices and results at the annual Conference Oct. 23 – 25, 2016. Applicants may submit presentation proposals to PRSA via the International Conference website.
The PRSA International Conference is the world's largest gathering of public relations professionals, where participants gain industry knowledge through insightful professional development sessions, inspiring keynote presentations and a variety of networking opportunities with colleagues and business leaders from around the world. Through our call for presentations, we invite the best of the communications industry to share their knowledge and insight with the more than 3,000 participants attending the Conference.
The deadline to submit your proposal is Tuesday, Feb. 16 at 11:59 p.m. EST. PRSA is requesting presentations for the following programming tracks:
- Integration
- Tools and Techniques
- Specialization
- Strategic Planning and Implementation
- Leadership and Management
In addition to the official events held at the JW Marriott Indianapolis, Conference hotel, PRSA invites you to explore the "Crossroads of America." While visiting the capital city of Indiana, be sure to visit Indianapolis's famous Monument Circle, the Indianapolis Museum of Art and the world's largest children's museum in the world, The Children's Museum of Indianapolis. Of course, no visit would be complete without visiting the Indianapolis Motor Speedway, host of the Indianapolis 500, the world's largest single-day sporting event.
About the Public Relations Society of America
PRSA is the largest professional organization serving the U.S. public relations community. With a mission to "advance the profession and the professional," PRSA provides news and information, thought leadership, continuing education and networking opportunities; sets standards of professional excellence and ethical conduct; and advocates for the business value of public relations and greater diversity among public relations professionals. Based in New York, PRSA comprises 112 local Chapters; 14 Professional Interest Sections that focus on specific industries and practice areas; and the Public Relations Student Society of America (PRSSA), which is active at more than 340 colleges and universities.


text:
Glance at the public postures of the US and Cuba, and you would assume otherwise. Havana may be on its economic knees; but last October, and despite the hostility of every other UN member except Israel and Romania, the US gratuitously stiffened its 30-year-old trade embargo against the Fidel Castro regime. The Miami-based Radio Marti, ostensibly controlled by the federal government but in practice dominated by Cuban exiles, still noisily broadcasts freedom's gospel to the island. For months, the two countries have been waging arcane war over proposals to improve telephone services between Cuba and the mainland.
To one like myself, who from a ringside seat in Moscow watched the resolution of the real Cold War, the language emanating from Mr Castro and his henchmen is wearily familiar. The exhortations 'to perfect socialism' are a straight lift from the Mikhail Gorbachev lexicon of political wishful thinking. The reforms they have in mind, including a limited dose of private enterprise, a fresh experiment with farmers' markets, and now legalisation of the US dollar, no less, may be heralded as 'changes in order to survive'.
They are in fact the sort of changes which hastened the collapse of the Soviet Union. But behind facades polished by three decades of enmity, glaciers may be melting. They are not so much the glaciers holding a bankrupt regime in a timewarp, as Havana this week went through the motions of celebrating the 40th anniversary of a revolution dated from the failed attack by Mr Castro and his followers on a barracks in Santiago de Cuba on 26 July 1953 - but those which really matter, here in the United States.
One tangible sign was this month's visit by a semi-official American delegation to open an informal line of communication between the Cuban and US military establishments. Another is the pressure in Congress to halve the dollars 16m ( pounds 10.7m) annual funding of Radio Marti and end all support for its sister TV station (which in any case has been comprehensively jammed by the Cubans ever since it went on the air three years ago). Most telling of all, however, is the growing split within the exile community in Miami and in the ranks of the potent Cuban-American lobby, whose hardline views held hostage a succession of Republican presidents. No longer. Not only is a Democrat in the White House. An increasingly vocal lobby, led by an organisation called Cambio Cubano, or Cuban Change, believes that such is the island's plight, common humanity, if nothing else, dictates a new start.
The next move is up to the administration. During the campaign, candidate Clinton went along with a tighter embargo; given his foreign policy inexperience, and the electoral importance of Florida, he was in no position to do otherwise. But today such considerations look threadbare. Mr Clinton became President despite losing Florida. And once it lost its dollars 4bn of annual aid from Moscow, a penniless Cuba was economically doomed, with or without an embargo by the US. Just like sanctions on Haiti, the restrictions have been punishing not so much a repressive regime as the ordinary people condemned to endure it.
Thus far, preoccupied with its domestic economic plans and events in Russia and the ex-Yugoslavia, the White House has given little visible thought to the looming foreign crisis on its southern doorstep. But it had better do so, fast. The story could lead tomorrow's newscasts, it may be months away yet; but sooner or later the Castro era will be over, and the last thing Washington needs is violent upheaval 90 miles away from the Florida Keys. The case for kindness, for whatever ensures a peaceful transition, is surely overwhelming.
Nationalism has played at least as strong a part as ideology in Cuba's fraught relationship with the superpower to the north. By permitting his own citizens to own and spend dollars sent back by relatives in the US, Mr Castro will effectively have hauled up one white flag. There are other reciprocal gestures Mr Clinton could make - for instance, closure of the strategically valueless and politically provocative US base at Guantanamo Bay. But to lift the embargo would strip Mr Castro of his strongest argument, that his country's woes are Yanqui-made.
Bill Clinton is constantly under fire for going back on campaign promises. But Cuba is a case where a reversal would be beneficial to all concerned. America's economic and ideological war with its southern neighbour has long since been won. In victory, generosity is foresight - or as a French politician once immortally remarked of a beaten rival, 'On ne tire pas sur une ambulance' ('You don't fire at an ambulance'). In this case, the patient is already in the hospital life-support unit. For the US to keep up the fire is both dangerous and demeaning.
- More about:
- American Dollar
- Cuba
- Democrats (US)
- Havanna
- London Ambulance Service


text:
Tropical Fish Keeping - Aquarium fish care and resources (http://www.tropicalfishkeeping.com/forum.php)
- Freshwater Journals (http://www.tropicalfishkeeping.com/freshwater-journals/)
- - 4 new pic's of my tank (http://www.tropicalfishkeeping.com/freshwater-journals/4-new-pics-my-tank-125273/)
4 new pic's of my tank
4 Attachment(s)
Got a new cannon T3i for Christmas and trying to play with different feature's on it. It's got more bells and whistles than I know what to do with. So here's a few shot's I took. I'm liking the 3rdl shot the best.
Nice Pics, Nice Tank! and obviously... Nice Camera!!
Thanks for sharing.
Great job with the tank and the pics!!!
Wow, it looks lovely!
simply.....i love it :-D
Looks great. I really like your tank.
In no uncertain terms, your tank is bad a$$!
And great pics too!
One query, what the background? Doesn't seem the best fit IMO to an otherwise great tank.
The background is why I aquascaped the way I did.
|All times are GMT -5. The time now is 04:15 PM.
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
vBulletin Security provided by vBSecurity v2.2.2 (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.


text:
SB cabin with two bunks. WC on port. V-cabin in front
Aft cabin with double berth on stb. Single on port
Saloon with two sofas. SB L-sofa with rounded corner
Seldén hydr. Furlinmast and jib, 44 CEST main sheet-/outhaul
Cutter stay incl. halyard, sheets, runners, extra cars
Red night light in hardtop
Hardtop with laid teak on roof
Varnished washboards and outer chart tables
Galley working surface: white
Cover over sink in galley, 2 parts
Extra directors chair 2
Bimini, stainless frames, closable window (Furlinmast)
Stainless rubbing strake, mooring and spring cleats
Teak push pit seats
Drink table on wheel steering
Teak step behind steering wheel
High gloss varnished teak on wheel pedestal
Outboard bracket on push pit
Sprayhood extension hardtop
Ocean Air sky screen in aft cabin
Ocean Air sky screen in cabin
Life lines in webbing on deck
With wichard fittings
Fitting for lifebelt in the cockpit 2
Complete propane installation
Autopilot Raymarine ST7001G+ with Whitlock drive
Radar pole without legs, incl. radar mounting
On port side: Removable arm on radar pole
Lamp on radar pole
Raymarine ST 60 Multi (repeater), position: 2
Chart table + wheel steering
Raymarine E120 multifunction display, + mounting, ex. ant.
Digital Sounder module for Raymarine E-series, incl. HUB
Raymarine 4KW Radar radom- & GPS- antenna, excl mounting
NMEA/RS232C Interface box, PC-connection at navstation, RS232
Country to use the VHF in Spain
Stereo/CD Pioneer (MV/LV/FM), with 2 speakers
Stereo loudspeakers in cockpit, Sea and Symphony
Raymarine loudspeaker for VHF in the cockpit
DSC-Pacific antenna (DSC/GSM/VHF/TV/SSB/AM/FM-radio)
TV outlet + 230V in port locker
VHF-antenna with cable to navigation table
Spare in radar pole
VHF Raymarine240E DSC class D,2control units,E42002 & E45002
Extra 230 V outlets 3 units
Aft Lazaretto, Both heads
Emergency switch for engine start
Extra 24V outlet
In cockpit: extra 12 V outlet
Shore power with circ. breaker, isolator, Marinco inlet
Additional 12 V e. System, Flat Plate 12V 225A 12 ud.
Additional Batteries, Flate Plate, 24V 225Ah
24 V/110 A Alternator in lieu of std (Volvo)
Battery charger 12V/25A-230V, Mastervolt IVO Compact
Battery charger Mastervolt MASS 24V/75A-230V, MICC remote
Inverter Mass Sine 24/2500-230V
Mastervolt Whisper 6 Ultra Dieselgenerator, 230V/50Hz 1500rpm
230V insulation transformer Ivet-D16 3,5 kvA, in 110/230V
Shower at bathing platform
High water alarm
General service pump, sea- or freshwater, 50 l./min.
Deep freezer in separate box
Switch for frigo
Aircondition Marineair VCP10/VCP16 220V/50/60
Electrical toilet, 24V. 2 units.
Bow thruster, 10 hp, No buttons in floor
Touch controller on wheel steering, Lewmar 589001
Gori propeller, three bladed, fixed as a spare
Double fuel filters with switch
Fixed anchor winch remote control at steering stand, 24V
Lewmar 64 CEST genoa sheet winches in lieu of standard
Force 10 el. stove in lieu of standard
With locker for Butane
Micro wave oven Electrolux EMM 1260, 230V
Washing machine Candy, 230V/50Hz
Hydraulic backstay tensioner and vang with Navtec panel
Burglar alarm at hatches entrance door and IR-sensor
Dishwasher Electrolux ESF 235, 230V
Remote anchor winch control and chain counter (Lofrans)
No buttons for windlass on deck
Colour of curtains: Beige
Upholstery: Ting 52 light blue.
Upholstery de luxe, Tric/Ton/Ting/Elo/Barleycorn
Carpet: Blue 1
Furling main, EMS 5V, Trioptimal, DC-cloth
Working jib, Furlex
E-foam for std working jib
Cover cockpit table/wheel/compass
Folding step in mast, 2 units.
15" LCD display with keyboard for Raymarine E-series
One 230V fluorescent light in engine room
Fire alarm in engine room
UV-protection, Working jib, grey
Ocean Air sky screen in saloon
Second jib halyard
Tricolour Lopolight LED toplight
Anchor light Lopolight LED
Grounding plate MK3, 2 units. For future SSB
Insulated backstay with cable close to grounding plates
Extra 230 V outlet
Close to existing outlet in locker pory
Furling cruising spinnaker incl. equip. and remov. Bowsprit. Colour: White/Blue 75 % white/25 % Blue
Weather fax/Navtex filter for RR-antenna
Furuno Navtex NX-300/D
Auxiliary tender
Life raft, 8 seats
Davits, bow auxiliary support, etc ...
Like new
A single owner.
Spanish flag.
Initial retail price: Total EUR 950000 (ex VAT)!
Ap. correos no. 78
Cami dels Horts s/n
Torroella de Montgri (Girona)


text:
Manchester United manager Louis van Gaal will reportedly keep his job until the end of the campaign owing to the fact that José Mourinho is reluctant to take over mid-season.
The Dutchman is under intense scrutiny at Old Trafford with his side six points adrift of the Premier League top four, dumped out of the Champions League and Capital One Cup and behind in their two-legged Europa League round-of-32 tie with Midtjylland.
According to the Daily Mirror, former Chelsea manager Mourinho is hesitant to replace Van Gaal before the end of the season with United struggling so dramatically on the pitch.
Taking over in June would allow the Portuguese to avoid early criticism if things do not work out straight away and also allow him to renovate the playing squad.
Ed Woodward, the executive vice-chairman, is believed to prefer keeping the former Barcelona and Bayern Munich boss until at least May as he protects the club's reputation in the wake of their decision to sack David Moyes half-way into his first full season.
Victory at Shrewsbury Town in the FA Cup fifth round did little to appease United supporters but Van Gaal, at least, sees it as a potential turning point in their traumatic season. A famous treble of Premier League, Europa League and FA Cup triumphs, the 64-year-old believes, is still possible.
"Everybody shall say it is against Shrewsbury Town and Manchester United has to win but we have seen very difficult results in the FA Cup, not always the top team is winning," he said.
"So I think we have done it fantastically. I have congratulated my players, I was very pleased but now we have to beat Midtjylland because it is also possible to beat them. But it is not easy because Midtjylland are very well organised, we have seen that in the away game.
Midtjylland 2 Manchester United 1 player ratings
Midtjylland 2 Manchester United 1 player ratings
1/11 Sergio Romero - 7 out of 10
Saved his side's blushes on several occasions, not least when he brilliantly got a hand to Paul Onuachu's header.
2/11 Donald Love - 4 out of 10
A difficult evening for the youngster, who particularly struggled in the first half. Thankfully for Love, Louis van Gaal does not seem to make snap decisions on young players if they have a game to forget.
2016 Manchester United FC
3/11 Chris Smalling - 6 out of 10
Rarely made individual errors but should have shown more authority playing alongside two juniors. Blame for the backline's disorganisation lies at his door.
2016 Manchester United FC
4/11 Paddy McNair - 5 out of 10
Ran ragged by the opposition too often. The question of whether he will make the grade at Old Trafford should, by now, have been answered.
5/11 Daley Blind - 6 out of 10
The soundest of a shaky defence and probed down the left on occasion too.
2016 Manchester United FC
6/11 Ander Herrera - 5 out of 10
Once again, far too awkward and error-prone when playing at the base of midfield. A player still without a defined role in this team. Replaced by Morgan Schneiderlin.
2016 Manchester United FC
7/11 Michael Carrick - 5 out of 10
A lethargic performance. His error led to Midtjylland's equaliser.
2016 Manchester United FC
8/11 Jesse Lingard - 8 out of 10
The brightest spark in a rather dull display. All good things flowed through the winger, who hit the bar in the second half.
2016 Manchester United FC
9/11 Juan Mata - 4 out of 10
Operating behind the striker was supposed to bring out the best in the Spaniard but he seems as inconsistent 'in the hole' as he does out wide. Gutless in the build-up to the home side's second.
2016 Getty Images
10/11 Memphis Depay - 6 out of 10
He may still have copped a lot of flak on social media but it was one of the winger's better evenings. Perhaps that's not saying much but something to build on, at least.
2016 Manchester United FC
11/11 Anthony Martial - 5 out of 10
A quiet display, the kind he has often got away with this season. As United's main goal threat, should have made more of an impact tonight.
2016 Manchester United FC
"But still everything is possible. We're still in three competitions, so we have to fight for a lot of chances I think."
- More about:
- Manchester United


text:
The other day I was out for a ride with my bicycle mentor Pat. He hadn't spent much time on the Cultural Trail, and after he showed me the sights on the Monon, I was eager to return the favor. I'd been riding the cultural trail exclusively for the past couple of weeks. And every trip I make around downtown reveals something new.
Pat and I met up on the East end of Mass Ave. He followed me as I twisted my way through the trail, winding through the inner city. The Cultural Trail can be tricky to follow in some spots if you aren't familiar, and the last time Pat saw me ride I was a bit of a mess. So, I was eager this time to show him my new found cycling confidence. My posture and control of movement were at least a little less awkward.
But something about the ride felt weird. Unlike myself, a self-described joy-rider, Pat rides for speed. While I roam randomly on trails hoping to discover a new part of the city, he races up and down the Monon focused on time, distance and aerobic expansion. Simply put, Pat is in much better shape than me, and I couldn't help but feel like I was holding him back.
"How far has your furthest ride been?" he queried as we paused at a cross walk.
"Last Sunday, I took the trail that follows the White River up to the canal. Took the canal behind the IMA and Butler into Broad Ripple. And followed the Monon home. It took me about two hours."
"Wow," He exclaimed. "That's probably like 20 miles."
Had I really just impressed Pat? I gleamed at the thought, but chided myself thinking he's only being kind.
"Huh, that's funny. I never count mileage, just how long I am on the bike seat," I replied, countering: "What's the longest ride you've ever done?"
"I like to head up to Westfield on longer rides," Pat tactfully did not mention a number. "I generally take the Monon up to Westfield and back again. There's a grocery store right at 146th Street, where I'll stop to fill up my water bottles and maybe get an energy drink. Then I do some riding around Westfield and stop again at the store before I head back."
I just couldn't shake the thought that I was holding him back. I'm sure he enjoyed the trail, but we certainly did not reach the his preferred level of exercise. Just as I was starting to think that Pat and I might not be the most compatible biking team I heard:
"Would you be interested in doing a half-century with me?"
"What's a half-century?"
"50 miles," he replied. "I don't mean like tomorrow."
"Sure," I replied and I know I glowed when he asked me. He followed my route, and now I would follow his. I guess that's how the best partnerships work.
Thus begins my Summer training for a half-century ride. Every week this blog has me asking, "What have I signed up for?"
I guess all I can do is hope that when the time comes, Pat doesn't regret the offer. Well, that and to ride my bottom off until the big day . By the way, has anyone got any tips for how to start training?


text:
Bobby Frankel will saddle another morning line favorite Saturday for Juddmonte Farm at Churchill Downs when homebred Heat Haze, unbeaten in two U.S. races, takes on a full field in the $100,000-added CITGO Distaff Turf Mile (gr. IIIT) for fillies and mares.
The Frankel and Juddmonte team also has the horse to beat in the Kentucky Derby (gr. I) in Empire Maker, the Humana Distaff (gr. I), where Sightseek is favored. Frankel also trains the Churchill Downs Handicap (gr. III) favortie, Aldebaran.
Heat Haze, the half-sister to 2001 Breeders' Cup Filly & Mare Turf (gr. I) winner Banks Hill, won the Las Cienegas (gr. III) at Santa Anita in her most recent start. She is the 3-1 morning-line choice under jockey Jose Valdivia.
Other contenders among the 15 entrees include stakes veterans Quick Tip and Maliziosa and Ghislaine Head's French import Dedication, a narrow loser in her only U.S. start for trainer Christophe Clement. The Thoroughbred Corp's Stylish, the 2002 winner of the race, is on the list of also-eligibles. Citgo Distaff Turf Mile Stakes (gr. IIIT), fillies & mares 3 & up, 1 mile on turf
PP. Horse, Jockey, Weight, ML Odds
1. Presumed Innocent (KY), Alex O. Solis, 121, 15/1
2. Bag of Stars (KY), Shane J. Sellers, 117, 30/1
3. Pina Colada (GB), Edgar S. Prado, 121, 12/1
4. Heat Haze (GB), Jose Valdivia, Jr., 123, 3/1
5. Dedication (FR), Jerry D. Bailey, 121, 7/2
6. Love Talkin (KY), Jon Kenton Court, 115, 15/1
7. Maliziosa (FL), Patrick A. Valenzuela, 121, 5/1
8. Sentimental Value (KY), Kent J. Desormeaux. 121, 10/1
9. Salty Farma (KY), Lonnie Meche, 117, 20/1
10. Mimi's Tizzy (CA), Calvin H. Borel, 115, 30/1
11. Quick Tip (KY), Robby Albarado, 123, 5/1
12. Strait From Texas (KY), Pat Day, 123, 8/1
Also Eligible
13. Madame Cerito (KY), Jose A. Santos, 115, 8/1
14. Red n'Gold (KY), Shane J. Sellers, 115, 20/1
15. Stylish (KY), Cornelio H. Velasquez, 121, 10/1
Heat Haze Faces Full Field in CITGO Distaff
Most Popular Stories
- Broken Pelvis Cause of Charismatic's Death
- Louis Quatorze Dies of Heart Attack
- Uncontested to Skip Rebel Stakes
- Mo Town, Guest Suite Set for Risen Star Showdown
- Horse of the Year Charismatic Dies
- El Areeb Confirmed to Start in Gotham Stakes
- Arrogate 'His Usual Self' in Five-Furlong Move
- International Star Could Add to Fair Grounds Success
- Mind Your Biscuits Set for Gulfstream Park Sprint
- Grade 1 Haskell Headlines Monmouth Stakes Schedule


text:
The temperature will rise when devices such as CPUs and Hard Disks do more than idle.
I have a Sony Pcg-Grt170 and I jsut recently started monitoring the temperature (only the HDD because I couldn't read the sensors for the CPU). It's runnning at around 51 degrees normally, but when doing a big task, the computer went up to 59 degrees, then sank back to 51 after a while. IS this normal? thanks


text: array(2) { ["companyfolder"]=> string(7) "ubisoft" ["page"]=> string(2) "11" } Ubisoft - Company Profile Home | News | Downloads | Videos | Cheats | Casual Games | Feedback PC Wii Wii-U PS3 PS4 X-360 X-One NDS iPhone Android News Downloads Screenshots Cheats and FAQs Companies Press Releases Reviews Streaming Videos Downloads Torrents Demos Videos & Trailers Full Games MMOG Clients Patches, Fixes Trainers, Savegames Maps, Levels Modifications Genres Casual Games Action - FPS Strategy - RTS Adventure - RPG Sport - Racing Sim. - Tycoon Kid Games MMOG Home > Companies > Ubisoft Homepage: Ubisoft Homepage A leading creator, publisher and distributor of video games, Ubisoft has grown considerably over the past two decades as a result of our strategy centered on the creation of strong brands, in-house development, and a vast global distribution network. This has allowed us to not only produce innovative, high-quality titles but also acquire an in-depth knowledge of our consumers and their expectations.STRONG BRANDSStrong brands play a pivotal role in Ubisoftâs strategy, ensuring the group's recurrent revenue and long-term financial health. Ubisoft is fortunate enough to have a portfolio of 13 multimillion unit-selling brands that today represent approximately two-thirds of its annual turnover. The company furthermore plans to create three new brands every two years, expanding its catalogue to new market segments. Hollywood movie and TV licenses have reinforced our strategy of brand creation. Our licensing agreements with major actors in the entertainment industry result in interactive games based on popular franchises and blockbuster movies. Thanks to resounding successes, such as Peter Jackson's King Kong: The Official Game of the Movie, Ubisoft has pushed back the genre's limits in terms of quality and innovation so that we are now one of tinsel town's choice partners.IN HOUSE DEVELOPMENTFrom the start, Ubisoft decided to bet on internal development. In 20 years, this strategic decision has paid off, and is proving crucial in the new transition period towards next-gen consoles. While numerous competitors prefer to externalize their game development to face this challenge, we remain convinced that our incredible creative teams and 17 studios will be key to a successful transition. Over 3,330 creative talents in our studios â united in their desire to innovate â form the second biggest internal development force in the world. In order to build and develop the skills of these teams, Ubisoft promotes continuous professional training and international mobility thereby giving teams the necessary tools to excel in their fields. The Ubisoft Campus, set up both for future industry talents and available for existing teams, is one of the pillars of this strategy.A VAST DISTRIBUTION NETWORKUbisoftâs strategy is also based on its worldwide distribution network, a structure made up of experienced multi-cultural teams motivated by promoting and selling high quality games. With subsidiaries based in 23 countries, game distribution in more than 50 countries and localization in more than 20 languages, Ubisoft has a powerful, wide-reaching business network rare among publishers on any continent. Its market and consumer knowledge allows it to anticipate trends and reach players in the best possible way. Thanks to this networkâs strength and the reputation of its teams, Ubisoft has established valued commercial relationships with many major editors. Our resources allow us to launch must-have titles simultaneously in Europe and the US in record time once the games have been released in their home market. That is how weâve managed to become a key partner for many Japanese editors in the West. Press Releases 08 Sep 2011: From Dust PlayStation Network® Release Date Revealed (675 views) 07 Sep 2011: Assassin's Creed® Revelations Multiplayer Beta Opens to PSN Members (644 views) 07 Sep 2011: Ubisoft® Announces Free Driver® San Francisco Multiplayer Content & Driver Club (605 views) 03 Sep 2011: Assassin's Creed® Revelations Multiplayer Beta Available for Download, Launches Saturday (652 views) 03 Sep 2011: New Season of Might and Magic Heroes Kingdoms Brings Expanded Content (713 views) 02 Sep 2011: Dance to Legendary Hits With Ubisoft's® Abba You Can Dance Video Game (571 views) 27 Aug 2011: Ubisoft® To Release Just Dance® Kids 2 in North America in October (771 views) 25 Aug 2011: Ubisoft® Brings Largest Lineup Ever to PAX Prime (410 views) 20 Aug 2011: Ubisoft® Announces Driver® San Francisco Multiplayer Demo (670 views) 20 Aug 2011: Might and Magic® Clash of Heroes® Announced for PC (389 views) 19 Aug 2011: Just Dance 3®: Ubisoft® Unveils More Songs from the Tracklist (464 views) 12 Aug 2011: Ubisoft® Announces DRIVER® San Francisco Demo (376 views) 12 Aug 2011: TrackMania 2 Canyon Races to the Finish Line (281 views) 12 Aug 2011: Ubisoft® & Sony Computer Entertainment Debut Game Details for PlayStation®3 Version of Critically Acclaimed Child of Eden (375 views) 11 Aug 2011: Assassin's Creed® Revelations Multiplayer Beta Launches as a Timed Exclusive to PlayStation®Network (368 views) 04 Aug 2011: Ubisoft® To Showcase Extensive Lineup of Video Games at Gamescom (666 views) 19 Jul 2011: Ubisoft Announces Call of Juarez: The Cartel Is Now Available Nationwide (658 views) 14 Jul 2011: Ubisoft® Reveals Lineup for Comic-Con (561 views) 12 Jul 2011: Ubisoft® Acquires Owlient and Howrse Brand, Strengthening Its Free-To-Play Expertise and Portfolio (671 views) 24 Jun 2011: Ubisoft® Announces Just Dance® 2 - Extra Songs (961 views) 10 Jun 2011: Ubisoft® Reveals Product Details for the Adventures of Tintin: The Game (444 views) 10 Jun 2011: Ubisoft® Announces The End of the World Is Near: Killer Freaks from Outer Space Invade Nintendo Wii U! (358 views) 09 Jun 2011: Ubisoft® Unveils Just Dance® 3 at Electronic Entertainment Expo (364 views) 07 Jun 2011: Ubisoft® Reveals Brothers in Arms Furious 4 (445 views) 07 Jun 2011: Ubisoft® Reveals Far Cry 3® at E3 (411 views) 27 May 2011: Ubisoft Unveils Diverse E3 Lineup and Kicks Off 25th Anniversary Celebration (338 views) 24 May 2011: Ubisoft Announces Development of Tom Clancy's Ghost Recon Online (882 views) 18 May 2011: Prepare to Boogie with The Smurfs®! In Ubisoft's® New Video Game, The Smurfs Dance Party (725 views) 13 May 2011: Ubisoft® Strikes a New Distribution Deal with Black Bean Games (700 views) 10 May 2011: Pre-Order Ubisoft's Rocksmith Video Game at Gamestop and Receive $25 Toward a Guitar at Guitar Center (810 views) 05 May 2011: Ubisoft® Unsheathes Assassin Creed® Revelations (834 views) 04 May 2011: Ubisoft® Presents the Exclusive Track List of 'Let's Dance With Mel B' (432 views) 29 Apr 2011: Ubisoft® Entertainment Partners with NFL Star Ndamukong Suh to Take on Gumball 3000 in Driver® San Francisco Themed Car (789 views) 27 Apr 2011: Ubisoft Speeds Ahead on Development of MediaPlanet and TrackMania2 Canyon (779 views) 21 Apr 2011: Ubisoft® Announces a New Cooperative Mode for Settlers 7: Paths to a Kingdom as well as a New DLC Pack (927 views) 20 Apr 2011: Raving Rabbids® Invade Just Dance® 2 with a New DLC Track (861 views) 20 Apr 2011: Ubisoft® Leverages Gamebryo 3D Engine for Rocksmith (759 views) 15 Apr 2011: Ubisoft Announces Michael Jackson the Experience Video Game Now Available for Kinect for Xbox 360 and PlayStation® Move (530 views) 14 Apr 2011: Ubisoft® Announces PowerUp Heroes Exclusively for Microsoft Kinect (329 views) 08 Apr 2011: Ubisoft and Gatorade Partner on Custom Workout Plans for Your Shape: Fitness Evolved Video Game (447 views) 04 Apr 2011: Ubisoft® Sails into the Future with Anno 2070 (538 views) 23 Mar 2011: Ubisoft Ships Four Games for the U.S. Launch of the Nintendo 3DS System (289 views) 16 Mar 2011: Ubisoft Unveils Rocksmith, A Revolutionary New Music Video Game (535 views) 16 Mar 2011: Ubisoft Announces Cubic Ninja for the Nintendo 3DS System (416 views) 10 Mar 2011: Assassin's Creed® Brotherhood The Da Vinci Disappearance Add-On Now Available (810 views) 09 Mar 2011: Ubisoft® Reveals PAX East Lineup (747 views) 05 Mar 2011: Ubisoft and Nivea Strengthen Your Shape: Fitness Evolved with Release of Free Downloadable Workout (992 views) 03 Mar 2011: Ubisoft Announces the Availability of Beyond Good & Evil HD on Xbox LIVE Arcade (803 views) 03 Mar 2011: Ubisoft® Reveals Product Details for Modern Day Western Shooter, Call of Juarez®: The Cartel (357 views) 23 Feb 2011: Ubisoft® Announces Ship Date and Specs for Assassin's Creed® Brotherhood on PC (1254 views) ‹‹‹789101112131415››› Games Far Cry 2. (7 / Action) Chessmaster 7000 28. (0 / Puzzle) Ghost Recon Jungle Storm 35. (1441 / Action) The Settlers 7: Paths to a Kingdom 61. (326 / Strategy) Shadowbane Throne of Oblivion 143. (9138 / MMOG) Resident Evil 4 181. (104 / Action) Heroes of Might and Magic V 185. (111 / Strategy) Open Season 188. (7762 / Action) Tom Clancy's Ghost Recon: Future Soldier 238. (82 / Action) Call of Juarez: Bound in Blood 254. (824 / Action) Splinter Cell 282. (577 / Action) Ghost Recon Advanced Warfighter 2 295. (496 / Action) Top Games: Euro Truck Simulator 2: Scandinavia Ex.. | Far Cry | Euro Truck Simulator 2 | Battlefield 2 | Monster Hunter | Shift 2 Unleashed | GTR 2 | Project X | Call of Duty 2 | Bus Simulator 2008 | Schein | Warhammer: Mark of Chaos | Shin Megami Tensei: Imagine Online | Age of Empires 2 Top Cheats: Amnesia: The Dark Descent: Walkthrough | Mortal Kombat: Shaolin Monks PS2 Fatalities List | New Super Mario Bros. Wii: Star Coin Guide | CSI: Crime Scene Investigation: Fatal Conspirac.. | NBA 2K11: My Player Mode Guide | Plants vs. Zombies: Gold Farming Guide | FEAR Walkthrough Quick Links: PC Games | MAC Games | Playstation 4 | XBox One | Casual Games | Android Games | DS | Iphone Games Copyright © 1999-2014 GamersHell.com. All rights reserved. | Contact Page | E.U.L.A. | Advertise | Privacy Statement | Search (Top 100) | Link Us


text:
Digital Puppet
- Status Completed
- Budget $250 - $750 CAD
- Total Bids 7
Project Description
I want to build a real time controlled digital puppet. The puppet will be controlled by a game controller. The opening and closing of the mouth should be digitally proportional to the joystick movement. Mouth movement does not necessarily have to be realistic. Can be like a puppet (muppet). One joystick controls mouth movement. The other joystick controls puppet body movement.
Body movement can be limited in the initial development. Moving left and right, on and off screen. Possibly into background and back to a home position which is like a traditional puppet (waist up with a close view of the head). Puppet should have some idle motion while stationary (eyes blinking and some small head and body movement) Puppet does not have to talk while moving and does not have to interact with other puppets. Controller buttons control simple facial expressions (ie no expression (normal), happy, sad, angry)
I would prefer the character to be an animal but humanoid (ie walks upright). Stock characters are acceptable for initial development.
Background can be a simple scene that suits the character in context. (dog in a back yard with doghouse; beaver in a wooded are near a stream etc)
Puppet voice is supplied by the person controlling the puppet. No lip syncing required in initial development.
I really want to keep the project simple and low cost to prove the concept so I am willing to sacrifice some features if necessary.
Here are some examples of what I am thinking about:
[url removed, login to view]
[url removed, login to view]
[url removed, login to view]
The outcome is to have a live person interacting with the puppet in real time with an audience.Get free quotes for a project like this
Completed by:
Skills Required
Looking to make some money?
- Set your budget and the timeframe
- Outline your proposal
- Get paid for your work
Hire Freelancers who also bid on this project
Looking for work?
Work on projects like this and make money from home!Sign Up Now
- Forbes
- The New York Times
- Time
- Wall Street Journal
- Times Online


text:
Didn't mean to send that duplicate. Hit the wrong button - stupid, clumsy
Wanted to ask this august group if anyone knows of a commercial source or
cultivated form of Rhus copallina or Dwarf Sumac. I have seen it growing on
Constitution Island - the only place in this area I have ever seen it. By the
river is a much milder climate than we have just a few miles away. I have seen
it growing in Maryland - Bombay Hook, and it is much larger than the one on C.
Hortus III says it grows to 20 feet, but the one on the island was only about
4 feet tall and as much wide - a most attractive shrub which had stunning
fall color. I have been looking in nursery catalogs, and don't see anything even
closely approximating it. So wondered if anyone here knows. Gene? Marge?
Support hort.net -- join the hort.net fund drive!


text:
December 23, 2015
As you may have noticed, there are some changes on my blog: New design, new header…It's all prep work. In a few months (all going as planned) the first volume of Corwin's Chronicle will hit the shelves. Corwin, a boy from 12th century Northumberland, is orphaned by war and saved from the destruction of his … More Changes


text:
Fond du Lac has a population of 42,203 and is located in Fond du Lac county.
The average in-state tuition for full time undergraduate students in web development schools in Fond du Lac during the 2009 - 2010 school year was $11,790.00. The average tuition was $19,365.00 for non-residents studying in Wisconsin.
The average cost of books and supplies for web development schools in Fond du Lac is $982.00. Students who live on campus while attending a web development school in Fond du Lac, can expect to pay an average of $5,640.00 for room and board. Students who live at home can expect average costs to be $4,523.00. There is one web development college in Fond du Lac for students to choose from. In the 2008 - 2009 school year, reportedly 4 students completed web development programs in Fond du Lac.
|Average Salary
|Number Employed in City
|Computer and Information Systems Managers
|Computer Programmers
|Computer Software Engineers, Applications
|Not available
|Computer Support Specialists


text:
Created by Tracy
Hi Guys! Running is beautiful. The Sunshine Coast is beautiful. So get out there and do some exercise! Spread it!
good yoga site
New to group, any ocean ski paddlers here? I'm looking for someone to join me in down wind runs Caloundra to La Balsa (or the other way).
I have been really licking (putting spit on)the electrode/pickup area of the chest strap and this has made a difference
For the first 25 minutes the Heart rate is totally wrong by 50- 60 beats and seems to be getting worse, any body got any way of fixing this or is anybody experiencing a similar problem.
I stopped using the Heart Rate on my Ambit 2 Sapphire because it is so inaccurate... showed ridiculously high heart rates. A shame as it's the only issue I have with an otherwise great unit.
Which watch?
Movescount.com - sports community where every Move counts.