Closed Bug 46867 Opened 20 years ago Closed 19 years ago

nsIClipboardCommands (or a generic command dispatch API) needs to be implemented.

Categories

(Core Graveyard :: Embedding: APIs, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8

People

(Reporter: jud, Assigned: mikepinkerton)

References

Details

(Keywords: embed)

Attachments

(1 file)

You get it by doing a GetInterface on the web browser object. 
nsIContentViewerEdit is not needed. 
nsIClipboard is a lower-level interface that we might want to expose as well for
     X selection. 
SelectNone() semantics need to be specified - where is the insertion point
     (collapsed selection) 
CanPasteSelection() should be renamed to CanPaste() 
PasteSelection() should be renamed to Paste()
*** Bug 45601 has been marked as a duplicate of this bug. ***
Keywords: embed
Keywords: nsbeta3
-> potts
Assignee: valeski → rpotts
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
The nsIClipboardCommands & nsIContentViewerEdit interfaces are practically 
identical. I think they should be consolidated into a single interface.

BTW the current implementation of nsIClipboardCommands on the nsWebshell 
doesn't do anything at all.
Priority: P3 → P1
per email with Jud, changing nsbeta3+ to nsbeta3- on all "embed" keyword bugs
since embedding changes will not be made in the mn6 branch. If you feel this bug
fix needs to go into mn6 branch, please list the reasons/user impact/risk and
nominate for rtm. Thanks.
Whiteboard: [nsbeta3+] → [nsbeta3-]
over to casa de pink
Assignee: rpotts → pinkerton
Target Milestone: M18 → ---
M0.9
Target Milestone: --- → mozilla0.9
Pink: please add swag to status whiteboard
We need text fields (form as well as composer content areas) in content areas to
be able to support cut/copy/paste when embedded. HTML content areas (static)
need to support "copy."

It would be helpful to have an understanding of how much of this relies on XUL
(and in what areas) and how much doesn't.
none of the clipboard stuff relies on XUL. I'm not sure what you need from me
here. What needs to be written apart from what is already written?
on the trivial end, method renaming suggested above.

pavlov, you had a lot of input on this topic in the api review meeting that
generated this bug. More specifically, how do we differentiate between selection
level copy on linux, vs. ctrl-c copies. Does the current iface accommodate?
i said that people should use nsIClipboard and avoid nsIClipboardCommands all
together.
i guess the goal of nsIClipboardCommands is that to handle a paste from the app,
the embedding app shouldn't have to know how to get the HTML text field and how
to put the data into it.

All i plan on doing is to make these calls use the commandDispatcher to dispatch
the appropriate command to the currently focussed widget, then we won't have to
write a bunch of special-case code.
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [nsbeta3-] → [nsbeta3-] SWAG: 3 days
notes to self:

implement (from globalOverlay.js), |goDoCommand()| and |goUpdateCommand()| in
C++ to send the relevant command string to the focussed object.
Status: NEW → ASSIGNED
so you're saying that it's up to us to handle an internal cut/copy->paste (works
for me), but what if I (an embedding app) want to copy a URL from the content
area (us) and paste it into my URL bar?

Should this bug depend on this cmdDispatcher bug?
http://bugzilla.mozilla.org/show_bug.cgi?id=54203

Consider what functionality an embedding app is going to want/need. They're
going to want to cut/copy/paste, just like we do.
jud, the embedding app needs to know when something in our embedded area is
focussed in order to call our API, or to handle it itself. Once that is covered,
what you mentioned should be a no-brainer.
Depends on: 54203
after talking to hyatt, we decided that instead of having specific command
dispatch APIs for different functionality, we should just come up with a single
generic one. It will certainly be needed for things other than just clipboard,
and then we can obsolete nsIClipboardCommands.

cc'ing hyatt and adam lock.
Summary: nsIClipboardCommands needs to be implemented. → nsIClipboardCommands (or a generic command dispatch API) needs to be implemented.
We already have a generic command handler interface in nsICommandHandler. 

See:

http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsICommandH
andler.idl

Ignore the nsICommandHandlerInit interface - that's just some implementation 
specific glue for nsCommandHandler.cpp.

The nsICommandHandler interface is pretty simple with just exec and query 
methods that any object in C++ or Javascript can implement.

You could delete nsIClipboardCommands and do the same thing through 
nsICommandHandler e.g.

Before:

nsCOMPtr<nsIClipboardCommands> clip = do_QueryInterface(someObject);
PRBool canCut;
clip->CanCutSelection(&canCut);
if (canCut)
{
    clip->CutSelection();
}

After:

nsCOMPtr<nsICommandHandler> cmd = do_QueryInterface(someObject);
nsXPIDLCString canCut;
nsCString yes; yes.AssignWithConversion("yes");
cmd->Query("canCutCutSelection", nsnull, getter_Copies(canCut));
if (yes.EqualsWithConversion(canCut))
{
    cmd->Exec("cutSelection", nsnull, nsnull);
}

Obviously the verbs, arguments and result strings are all part of the contract 
between caller and callee so they should be defined somewhere and not hardcoded 
as above.

if what adam says is the case, then I will cvs remove nsIClipboardCommands and
mark this bug invalid. arguments?
Don't mark it invalid. This is tracking the embedding need for clipboard
support. It sounds like this may not have been adequately defined and documented
for embedders, perhaps that is all that remains.
Wait up. I recall, in one API review meeting I was at, that people said that we 
should provide functionality-specific command handling interfaces for embedders. 
I.e. that we *do* provide things like nsIClipboardCommands, instead of generic 
"do named command" type interfaces. Judson, Doug -- comments?
Why would we need to complicate things with additional interfaces though?
who was asking for these additional interfaces? Can someone answer hyatt's 
question? I need to know if there is work to be done, or not.
the api changes fell out of a mozilla porkjockeys meeting a few months ago. We
glossed over this one w/ out going into too much detail because it seemed hard.
I'm going to forward this bug to porkjockeys so we can open this up for
discussion again.
i have the code written (figured i might as well, it was easy). How do i go 
about testing any of it?
can someone r= the attached patch to nsWebShell? I've noticed that none of the
test harnesses use it, so I can't really test it.
Webshell is an evil thing and I'm not sure I like the idea of it growing again. 
Should this stuff be moved into docshell or would that bad too?

Also, if we're covering a generic interface (nsIController) with a custom 
interface (nsIClipboardCommands), then perhaps webshell (or docshell) should 
also implement nsIController so people can inject the string commands directly.
whatever. i just filled in the stubbed out interface. if you guys want the code
elsewhere, let me know.
ok, conrad added some stuff to the mac embedding harness and the new clipboard
commands do actually work! Note, in the diff above, I had to prefix the commands
with "cmd_" to get it to work.
Keywords: nsbeta3
Whiteboard: [nsbeta3-] SWAG: 3 days
r=sfraser/a=hyatt. fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
so am I able to get the nsIClipboardCommands interface from the webbrowser object?
re-opening as the methods haven't been renamed (as outlined in the first comment
of the bug). the concept of "selection" isn't valid in the iface anymore (it's
implicit).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9 → mozilla0.8
i've made the changes. the semantics of SelectNone() are that the insertion
point is at the beginning of the previous selection. If you disagree, speak up.
It's easy to change.
checked in
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Updating QA Contact
QA Contact: jrgm → mdunn
Test with WinEmbed.exe
Status: RESOLVED → VERIFIED
Blocks: 64995
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.